MikroTik

Posted: **Sun Nov 11, 2018 11:41 am**

A few times now I see the Evil Google DNS trying to connect endless to my DNS port which is blocked to by a RAW rule. In this way I can fill my log files very fast by only that log entry repeating and repeating endlessly.

Nov/11/2018 08:29:06 firewall,info Drop RAW - Probe prerouting: in:pppoe-out1 out:(unknown 0), src-mac 54:1e:56:3c:68:62, proto UDP, 8.8.8.8:53->wan.wan.wan.wan:5678, len 80
Nov/11/2018 08:29:07 firewall,info Drop RAW - Probe prerouting: in:pppoe-out1 out:(unknown 0), src-mac 54:1e:56:3c:68:62, proto UDP, 8.8.8.8:53->wan.wan.wan.wan:5678, len 80
Nov/11/2018 08:29:08 firewall,info Drop RAW - Probe prerouting: in:pppoe-out1 out:(unknown 0), src-mac 54:1e:56:3c:68:62, proto UDP, 8.8.8.8:53->wan.wan.wan.wan:5678, len 80
Nov/11/2018 08:29:09 firewall,info Drop RAW - Probe prerouting: in:pppoe-out1 out:(unknown 0), src-mac 54:1e:56:3c:68:62, proto UDP, 8.8.8.8:53->wan.wan.wan.wan:5678, len 80
.
.
Nov/11/2018 09:36:17 firewall,info Drop RAW - Probe prerouting: in:pppoe-out1 out:(unknown 0), src-mac 54:1e:56:3c:68:62, proto UDP, 8.8.8.8:53->wan.wan.wan.wan:5678, len 80
Nov/11/2018 09:36:18 firewall,info Drop RAW - Probe prerouting: in:pppoe-out1 out:(unknown 0), src-mac 54:1e:56:3c:68:62, proto UDP, 8.8.8.8:53->wan.wan.wan.wan:5678, len 80
Nov/11/2018 09:36:19 firewall,info Drop RAW - Probe prerouting: in:pppoe-out1 out:(unknown 0), src-mac 54:1e:56:3c:68:62, proto UDP, 8.8.8.8:53->wan.wan.wan.wan:5678, len 80
Nov/11/2018 09:36:20 firewall,info Drop RAW - Probe prerouting: in:pppoe-out1 out:(unknown 0), src-mac 54:1e:56:3c:68:62, proto UDP, 8.8.8.8:53->wan.wan.wan.wan:5678, len 80
Nov/11/2018 09:36:21 firewall,info Drop RAW - Probe prerouting: in:pppoe-out1 out:(unknown 0), src-mac 54:1e:56:3c:68:62, proto UDP, 8.8.8.8:53->wan.wan.wan.wan:5678, len 80

These is the start of log.0.txt and log.4.txt and so in total 4000 lines of the same and I lost so the part of the log I ought to have.

cloud.jpg

An other strange thing is that displayed log looks different in the sequence of the events;

Nov/11/2018 09:56:22 firewall,info icmp - related input: in:master-bridge out:(unknown 0), src-mac 40:8d:5c:b2:fa:ed, proto ICMP (type 3, code 3), 192.168.xxx.xxx->192.168.xxx.xxx, len 139
Nov/11/2018 09:56:22 firewall,info Drop RAW - Probe prerouting: in:pppoe-out1 out:(unknown 0), proto UDP, 8.8.8.8:53->wan.wan.wan.wan:5678, len 80
Nov/11/2018 09:58:22 firewall,info icmp - related input: in:master-bridge out:(unknown 0), src-mac 40:8d:5c:b2:fa:ed, proto ICMP (type 3, code 3), 192.168.xxx.xxx->192.168.xxx.xxx, len 139
Nov/11/2018 09:58:22 firewall,info Drop RAW - Probe prerouting: in:pppoe-out1 out:(unknown 0), proto UDP, 8.8.8.8:53->wan.wan.wan.wan:5678, len 80
Nov/11/2018 10:00:22 firewall,info icmp - related input: in:master-bridge out:(unknown 0), src-mac 40:8d:5c:b2:fa:ed, proto ICMP (type 3, code 3), 192.168.xxx.xxx->192.168.xxx.xxx, len 139
Nov/11/2018 10:00:22 firewall,info Drop RAW - Probe prerouting: in:pppoe-out1 out:(unknown 0), proto UDP, 8.8.8.8:53->wan.wan.wan.wan:5678, len 80
Nov/11/2018 10:02:22 firewall,info icmp - related input: in:master-bridge out:(unknown 0), src-mac 40:8d:5c:b2:fa:ed, proto ICMP (type 3, code 3), 192.168.xxx.xxx->192.168.xxx.xxx, len 139
Nov/11/2018 10:02:22 firewall,info Drop RAW - Probe prerouting: in:pppoe-out1 out:(unknown 0), proto UDP, 8.8.8.8:53->wan.wan.wan.wan:5678, len 80
Nov/11/2018 10:04:22 firewall,info icmp - related input: in:master-bridge out:(unknown 0), src-mac 40:8d:5c:b2:fa:ed, proto ICMP (type 3, code 3), 192.168.xxx.xxx->192.168.xxx.xxx, len 139
Nov/11/2018 10:04:22 firewall,info Drop RAW - Probe prerouting: in:pppoe-out1 out:(unknown 0), proto UDP, 8.8.8.8:53->wan.wan.wan.wan:5678, len 80

LOG2.JPG

I see the show log a misplaced 09:34:05 timestamp between 10:02:22 and 10:04:22 of two minutes DNS request for the Cloud I don't use.

In the logfile itself it is correctly sequenced:

Nov/11/2018 09:30:03 firewall,info Drop RAW - Probe prerouting: in:pppoe-out1 out:(unknown 0), src-mac 54:1e:56:3c:68:62, proto UDP, 8.8.8.8:53->wan.wan.wan.wan:5678, len 80
Nov/11/2018 09:30:04 firewall,info Drop RAW - Probe prerouting: in:pppoe-out1 out:(unknown 0), src-mac 54:1e:56:3c:68:62, proto UDP, 8.8.8.8:53->wan.wan.wan.wan:5678, len 80
Nov/11/2018 09:30:05 firewall,info Drop RAW - Probe prerouting: in:pppoe-out1 out:(unknown 0), proto UDP, 8.8.8.8:53->wan.wan.wan.wan:5678, len 80
Nov/11/2018 09:32:05 firewall,info Drop RAW - Probe prerouting: in:pppoe-out1 out:(unknown 0), proto UDP, 8.8.8.8:53->wan.wan.wan.wan:5678, len 80
Nov/11/2018 09:34:05 firewall,info Drop RAW - Probe prerouting: in:pppoe-out1 out:(unknown 0), proto UDP, 8.8.8.8:53->wan.wan.wan.wan:5678, len 80
Nov/11/2018 09:36:05 firewall,info Drop RAW - Probe prerouting: in:pppoe-out1 out:(unknown 0), src-mac 54:1e:56:3c:68:62, proto UDP, 8.8.8.8:53->wan.wan.wan.wan:5678, len 80

Posted: **Sun Nov 11, 2018 11:54 am**

I bet that the UDP connect packets have spoofed source IP address and somebody is trying to engage your router into DDOS attack against google's DNS services. As UDP port 5678 is used for Neighbour Discovery it is likely that unprotected device would respond with answer sent to google.
The thing is that even DNS server, when connecting to another DNS server (for e.g. recursive resolution of its client's request), doesn't usually use port 53 for outgoing connection, but rather usses a random high port just like usual applications. So whenever you see incoming connection originating from "service" port, it's likely an ongoing scam.

Or it's not DDOS attack against google but rather attempt to get your IP to spam list thus denying some services to you.

It's fine if you're logging all evil attempts ... but then if you already dealt with them, what's the point in logging them? Sometimes curiosity kills the cat.

Posted: **Sun Nov 11, 2018 12:10 pm**

Thanks mkx. That is now clear to me and the first spoof, triggered the rule that places it on a addreslists to be "dropped" for a long period. I have now changed the RAW for accepting DNS returns so that the next time it would not even reach the spoof check, so it will not be promoted to addresslists for dropping and then not flooding my logfile a next time.
If it finds an other way then it will still trigger the probe and be placed again on the addresslist to be dropped.

Leaves open how to stop the router to contact 8.8.8.8 every two minutes to resolve the DNS of the cloud while and the out-of-sequence displayed line in logging.

Posted: **Sun Nov 11, 2018 12:17 pm**

turn off internet detection

Posted: **Sun Nov 11, 2018 12:25 pm**

turn off internet detection

Darn...I switched that on two days ago to see what that did...I was not wiser and wanted to look at it again coming week. It is now switched off and I will not ever touch it again.

MikroTik

Killing the Mikrotik Cloud?

Killing the Mikrotik Cloud?

Re: Killing the Mikrotik Cloud?

Re: Killing the Mikrotik Cloud?

Re: Killing the Mikrotik Cloud?

Re: Killing the Mikrotik Cloud?