Community discussions

MikroTik App
  4. RouterOS
  5. General

Killing the Mikrotik Cloud?

Post Reply
 
msatter
Forum Guru
Forum Guru
Topic Author
Posts: 2912
Joined: Tue Feb 18, 2014 12:56 am
Location: Netherlands / Nīderlande

Killing the Mikrotik Cloud?

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
You do not have the required permissions to view the files attached to this post.
Last edited by msatter on Sun Nov 11, 2018 11:54 am, edited 1 time in total.
Top
 
User avatar
mkx
Forum Guru
Forum Guru
Posts: 11627
Joined: Thu Mar 03, 2016 10:23 pm

Re: Killing the Mikrotik Cloud?

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.
Top
 
msatter
Forum Guru
Forum Guru
Topic Author
Posts: 2912
Joined: Tue Feb 18, 2014 12:56 am
Location: Netherlands / Nīderlande

Re: Killing the Mikrotik Cloud?

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.
Last edited by msatter on Sun Nov 11, 2018 12:20 pm, edited 2 times in total.
Top
 
whitbread
Member Candidate
Member Candidate
Posts: 119
Joined: Fri Nov 08, 2013 9:55 pm

Re: Killing the Mikrotik Cloud?

Sun Nov 11, 2018 12:17 pm

turn off internet detection
Top
 
msatter
Forum Guru
Forum Guru
Topic Author
Posts: 2912
Joined: Tue Feb 18, 2014 12:56 am
Location: Netherlands / Nīderlande

Re: Killing the Mikrotik Cloud?

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.
Top
Post Reply

Who is online

Users browsing this forum: GoogleOther [Bot], Yahoo [Bot] and 198 guests
  4. RouterOS
  5. General