Community discussions

MikroTik App
 
ICServico
just joined
Topic Author
Posts: 3
Joined: Thu May 13, 2021 12:08 am

RB trying to be hacked by a mac to an internal IP of internal network

Thu May 13, 2021 1:10 am

Need help. My RB is not connected to the LAN, my network is at another ISP, it was working normally, and stopped accessing, the attempt to change the channel did not work, stopped all internet access, as if it were a DNS problem, a " twist in PPPOE "this information appears:" input: in: WAN - 1 out: (unknown 0), src-mac 74: 27: ea: 74: 82: 53, proto UDP, 192.168.0.103:137->192.168. 0.255: 137, len 78 "<there is no connection to the internal network or any IP, my access is remote. following that input
input: in: Vivas PPPOE out: (unknown 0), proto TCP (SYN), 38.146.84.247:20059->177.126.:8080, len 44
input: in: Vivas PPPOE out: (unknown 0), proto TCP (SYN), 45.95.169.108:47534->177.126.2 len 44
input: in: Vivas PPPOE out: (unknown 0), proto TCP (SYN), 170.106.36.247:46139->177.126.2:3389, len 44
input: in: Vivas PPPOE out: (unknown 0), proto TCP (SYN), 192.241.215.100YS7869->177.126.:3389, len 44
input: in: Vivas PPPOE out: (unknown 0), proto TCP (SYN), 74.120.14.28:2380->177.126:53901, len 44
input: in: WAN - 1 out: (unknown 0), src-mac 74: 4d: 28: 6a: 50: 07, proto UDP, 0.0.0.0:53678->255.255.255.255/1667, len 143

I do not know what to do?
Last edited by ICServico on Mon May 17, 2021 2:52 am, edited 1 time in total.
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: RB trying to be hacked by a mac to an internal IP of internal network

Thu May 13, 2021 11:19 pm

If you have a decent firewall, there's nothing to actually worry about regarding these messages.

The ones with in: WAN - 1 out: (unknown 0) log packets that have been sent to broadcast MAC addresses, hence the machine receives them and the firewall logs them. The first one is sent by some device (74:27:ea:74:82:53) in the WAN segment has 192.168.0.103 on itself and is trying to discover all devices in that subnet on the netbios protocol, so it is not a targeted attack towards your device. Your machine ignores this packet unless it has one of its own address in 192.168.0.0/24.

The last one looks like some proprietary protocol similar to Mikrotik's mac-telnet, but again, since it is not a Mikrotik one, your device ignores it (and even if it was a Mikrotik one, the allowed-interface-list configured under /tool mac-server should not contain the WAN interface so you should be safe too).

Those coming in via Vivas PPPOE out are generic bots trying to connect to commonly used server ports: 8080 (alt-http), 23 (telnet), 3389 (RDP), so again, these attacks are not selectively targeting your device, they just keep trying on all public IPs.

The only problem is if you post your firewall configuration now, and if there is a hole in it, it would be easy to exploit as you have probably posted your real public IP in the log rows.

But I did not understand the description of the actual problem you have, nor of your network topology. Is the device only connected to the internet via PPPoE, and you have a VPN to manage it remotely?
 
ICServico
just joined
Topic Author
Posts: 3
Joined: Thu May 13, 2021 12:08 am

Re: RB trying to be hacked by a mac to an internal IP of internal network

Fri May 14, 2021 6:52 pm

Thanks for your reply!!

Your Ask:
"But I did not understand the description of the actual problem you have, nor of your network topology. Is the device only connected to the internet via PPPoE, and you have a VPN to manage it remotely?"

No, I created an access via winbox and gave preference to my ip which is fixed. My company is running with another ISP, I created this RB with two WANS, for redundancy. however, access to pages stopped, that is, even with two ISP's, they did not access web pages, as if it were the lack of DNS, although RB announced the DNS. so I decided to leave my internal network directly in MODEM, until resolving what is happening with this RB.
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: RB trying to be hacked by a mac to an internal IP of internal network

Fri May 14, 2021 7:44 pm

I'm afraid I need a drawing to understand what you explain, but I'll try without it first: if I get it right, when it didn't work, the LAN side of the Mikrotik in question actually was not completely disconnected as I understood from your Original Post, except that only the PC from which you manage it using winbox was connected to the LAN interface of the Tik, correct? And the WANs were connected to two different ISPs.

Next, what exactly do you mean by of "internal IP"?

For me, "internal IP" is on the LAN side of a router, even if it is a public one; similarly, a private IP (i.e. an IP in one of the RFC1918 ranges) may still be an "external" one when it is at the WAN side of a router.
 
ICServico
just joined
Topic Author
Posts: 3
Joined: Thu May 13, 2021 12:08 am

Re: RB trying to be hacked by a mac to an internal IP of internal network

Sat May 15, 2021 12:19 am

Thanks for reply!

My drawing to the current RB is this attached, I don't know where this MAC comes from, since my network is not connected to the RB, and this mac tries to access this ip that would be on my internal network. the Fact is that if you connect via LAN (internal network) there is no way to view pages as I described earlier, the services that require ports work normally.





Ivan Santos
You do not have the required permissions to view the files attached to this post.
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: RB trying to be hacked by a mac to an internal IP of internal network

Sat May 15, 2021 12:40 pm

OK. I am pretty sure these "hack attempts" are unrelated to your issue, and that they have been there also before the problems with viewing pages started. But before these problems started, you had no reason to take a close watch, so now you've made a conclusion that the two things (impossibility to access web pages by their domain names and those incoming packets) are related.

So I assume you access, using Winbox, the public IP of your RB assigned by Vivas on the Vivas PPPOE interface, and that either your firewall on the RB restricts Winbox access to a few public source addresses or that you use a VPN tunnel. So it should be safe to post the export of your configuration even though you have leaked the Vivas public IP unintentionally. So if you need more help, please do that, following the hint in my automatic signature here below. Some sniffing may be required later on if the issue is not in the configuration.


Coming back to the log rows you've shown in the OP: the rows that show source MAC addresses correspond to IP packets that came as a direct payload of Ethernet frames. The thing is that the IP stack of the RB's kernel sends to chain input of the IP firewall also received packets whose destination IP address is 255.255.255.255 or a broadcast one of any subnet that is up on any interface of the router, no matter to which physical interface such packets have arrived.

And 192.168.0.0/24 and 192.168.1.0/24 are probably the most used private subnets in the world, so it is nothing unusual that you have "randomly chosen" it for your RB's LAN, whereas some Windows device in the same L2 segment like your WAN 1 Ethernet interface has "randomly chosen" it too. So it is either an issue at the Vivas side that they allow Ethernet frames to leak from one client to another, or an issue at the Vivas side that they connect their own Windows devices into the same L2 network they use for PPPoE connections to their clients.

As your RB is (most likely) not bridging traffic between WAN and LAN, RB will not leak these netbios packets arriving via WAN 1 to 192.168.0.255 to the LAN.

Regarding the last row in the OP, could it be that you were copying the log manually to the post? Because if the source port and destination port were actually both 5678, this row would be showing a MNDP (Mikrotik Network Discovery Protocol) packet, which seems very likely to me as the source MAC address is a Mikrotik one. So again, it may be an own Mikrotik device of Vivas, or a Mikrotik device of some other Vivas client which is connected to the uplink and neighbor discovery is not disabled on the interface to which the PPPoE client is attached.

All the rows not showing source MAC addresses represent packets that came via the PPPoE tunnel, I've given you the details in my previous post.

Who is online

Users browsing this forum: Bing [Bot], Husky, rplant and 68 guests