Community discussions

MikroTik App
 
wwj
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 55
Joined: Mon May 05, 2014 6:37 am

Encountered an ARP table exhaustion attack

Thu Jun 01, 2023 9:37 am

my ccr1072 conn to switch ,and created 100 vlanif ,ip-address like 192.168.0.1/24,192.168.1.1/24,192.168.2.1/24,192.168.3.1/24………………192.168.100.1/24
so ,it have 256*100=25600IPs , Actually, there aren't so many hosts, vlans are just dividing for management purposes

A few days ago, I was attacked by a host in a local area network,This host scans the local area network segment 192.168.0.0/16, and CCR1072 needs to forward the data packet to the local area network where its vlanif is located. However, it needs to initiate an ARP request to obtain the MAC address of the host in the local area network. At this time, the ARP table looks like this:

8144 DC 124.93.29.83 B0:2C:71:E5:00:80 vlan1008
8145 DC 192.168.70.132 B4:05:5D:0A:ED:AA vlan0699
8146 D 192.168.80.252 vlan0807
8147 D 192.168.70.225 vlan0699
8148 DC 192.168.80.55 00:50:56:93:AD:02 vlan0801
8149 D 192.168.66.170 vlan1066
8150 D 192.168.11.51 vlan0903
8151 D 192.168.82.147 vlan0904
8152 D 172.23.64.178 vlan3544
8153 D 192.168.78.18 vlan2002
8154 D 192.168.87.7 vlan0844
8155 D 192.168.68.161 vlan1068
8156 D 192.168.67.150 vlan1067
8157 DC 172.24.2.67 00:50:56:9B:13:F9 vlan0036
8158 D 192.168.9.100 vlan1090
8159 D 192.168.95.29 vlan0862
8160 D 192.168.9.106 vlan1090
8161 D 192.168.90.204 vlan0853
8162 D 192.168.64.180 vlan1064
8163 D 192.168.9.252 vlan1090
8164 D 192.168.83.124 vlan0827
8165 D 192.168.93.103 vlan0858
8166 D 192.168.88.161 vlan0849
8167 D 192.168.82.252 vlan0904
8168 DC 192.168.89.235 00:50:56:93:19:6B vlan0851
8169 D 192.168.9.59 vlan1090
8170 D 192.168.84.142 vlan0834
8171 D 192.168.85.253 vlan0839
8172 D 192.168.88.188 vlan0849
8173 D 192.168.67.186 vlan1067
8174 D 192.168.66.38 vlan1066
8175 D 192.168.87.139 vlan0846
8176 D 172.18.6.94 ether1
8177 D 192.168.88.124 vlan0848
8178 D 192.168.80.221 vlan0806
8179 DC 192.168.70.16 B4:05:5D:0C:77:93 vlan0699
8180 D 192.168.66.8 vlan1066
8181 D 192.168.9.251 vlan1090
8182 D 192.168.86.23 vlan0840
8183 D 192.168.87.242 vlan0847
8184 D 192.168.64.179 vlan1064

It was filled up !with a total of 8184 ARP tables,At that point, the router cannot obtain the actual ARP of the host in a timely manner, resulting in delays and packet loss
In the end, this multi IP large-scale scanning behavior was discovered and the source address was blocked in the firewall, restoring the network to normal

I know,we have PSD to find the ports-scaner , but in this case , How should we protect ourselves? and Can the ARP table be expanded?
 
wiseroute
Member
Member
Posts: 352
Joined: Sun Feb 05, 2023 11:06 am

Re: Encountered an ARP table exhaustion attack

Thu Jun 01, 2023 10:31 am

hello

[*]
i know,we have PSD to find the ports-scaner , but in this case , How should we protect ourselves? and Can the ARP table be expanded?
[*]

my sympathy for your network.

well, i don't know anything about your network layout - whether those disasters came in wired or wireless one?

maybe, that is maybe - its difficult to eliminate those kind of accident totally - but rather minimize it per local vlan being inter-vlan or at bras/bng point firewalls as your tools. (especially for wireless ap).

2. i don't know whether MT routeros has some kind of layer 2 port security features - but some switches do - so it will help to eliminate bogus mac playing around the network. but MT do have nice l2 l3 l7 firewall system as well.

3. if you were a network operator - start doing mac address registration for the whole network.

4. common switches has only that 8k mac table at max, so start doing some restructuring work.

hope this helps and good luck 👍🏻
 
User avatar
rextended
Forum Guru
Forum Guru
Posts: 11967
Joined: Tue Feb 25, 2014 12:49 pm
Location: Italy
Contact:

Re: Encountered an ARP table exhaustion attack

Thu Jun 01, 2023 12:47 pm

What I'm wondering is why do you make 100 VLANs if you then allow each segment to contact the others...

The CCR1072-1G-8S+ has 16GB of memory, so not problem with
/ip settings max-neighbor-entries=65536
that can containing all 192.168.0.0/16 and use only 2GB of memory.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10183
Joined: Mon Jun 08, 2015 12:09 pm

Re: Encountered an ARP table exhaustion attack

Thu Jun 01, 2023 4:16 pm

A few days ago, I was attacked by a host in a local area network,This host scans the local area network segment 192.168.0.0/16,
Probably not really an attack. Some applications think it is a good idea to locate other users of the application, or sometimes certain resources (like a printer) by scanning the entire local address range.

For that reason, it is actually not a good idea to allocate large subnets and use only a small part of it.
The same problem occurs in IPv6 when you do not have an incoming firewall and people on internet start scanning your range.
 
wiseroute
Member
Member
Posts: 352
Joined: Sun Feb 05, 2023 11:06 am

Re: Encountered an ARP table exhaustion attack

Thu Jun 01, 2023 4:34 pm

[*]
Probably not really an attack.
[*]

yes. maybe you are right. 👍🏻

because there are some computer virus that did ruin layer 2. i have forgot its name.

but, how we could localized the infections could bring easier disaster management.
 
User avatar
rextended
Forum Guru
Forum Guru
Posts: 11967
Joined: Tue Feb 25, 2014 12:49 pm
Location: Italy
Contact:

Re: Encountered an ARP table exhaustion attack

Thu Jun 01, 2023 4:37 pm

because there are some computer virus that did ruin layer 2. i have forgot its name.
Some are called anti-virus, see other topic about not required LAN scan&attack for test vulnerabilities..........
 
User avatar
Paternot
Forum Veteran
Forum Veteran
Posts: 953
Joined: Thu Jun 02, 2016 4:01 am
Location: Niterói / Brazil

Re: Encountered an ARP table exhaustion attack

Thu Jun 01, 2023 4:46 pm

But even if not an attack, this mode of failure is far from optimal. Wouldn't be better if upon space exhaustion the least used ARP entries got deleted? Would help to solve the exhaustion problem.
 
wiseroute
Member
Member
Posts: 352
Joined: Sun Feb 05, 2023 11:06 am

Re: Encountered an ARP table exhaustion attack

Thu Jun 01, 2023 4:57 pm

@ rextended

[*]
Some are called anti-virus,
[*]

well... we can't rely that on end-users/subscribers, can we?

maybe some just doing some tests - ie. networking students etc. but not to be underestimate the impact for the network.

@paternot
[*]
Wouldn't be better if upon space exhaustion the least used ARP entries got deleted
[*]

how long will an arp exist on the table depends on how chatty its broadcaster.

so, stop its broadcaster. the closer to the source the better.
 
User avatar
Paternot
Forum Veteran
Forum Veteran
Posts: 953
Joined: Thu Jun 02, 2016 4:01 am
Location: Niterói / Brazil

Re: Encountered an ARP table exhaustion attack

Thu Jun 01, 2023 9:03 pm

@paternot
[*]
Wouldn't be better if upon space exhaustion the least used ARP entries got deleted
[*]

how long will an arp exist on the table depends on how chatty its broadcaster.

so, stop its broadcaster. the closer to the source the better.
Well, yes. Stopping the broadcaster is the ideal solution - but we do not live in an ideal world. The current algorithm doesn't cope well with a huge influx of entries, hence the DOS attack. When someone says "make the ARP table bigger so we can face the attack" they are really saying "this implementation cannot face a huge influx of ARP entries without dying".

Yes, performance would suffer, as it would ask more frequently for legitimate ARP entries. But at least the system wouldn't go tits up, as it goes now.
 
wiseroute
Member
Member
Posts: 352
Joined: Sun Feb 05, 2023 11:06 am

Re: Encountered an ARP table exhaustion attack

Thu Jun 01, 2023 10:01 pm

@ paternot

couldn't disagree with what you have said.

ok. let us say :

ok. the mac table is full. traffic dropped.
let's clear up some old inactive entries.

do clear ip arp.

this could lead to 2 things:
1. if that chatty broadcaster stopped, then the forwarding media is good to go. - again that is if.

2. clearing macaddr table could mean the forwarding media needs to build its forwarding database/fib - which again network will suffers. that is if - again - if the chatty broadcaster stops .

yes. there are bigger database for some switches (clustered systems), but I don't think that will help if the underlying chatty broadcaster are still playing around the media.

the obvious impact is if that bogus arp claiming it self as the subnet gateway.
 
User avatar
Paternot
Forum Veteran
Forum Veteran
Posts: 953
Joined: Thu Jun 02, 2016 4:01 am
Location: Niterói / Brazil

Re: Encountered an ARP table exhaustion attack

Sat Jun 03, 2023 5:02 pm

yes. there are bigger database for some switches (clustered systems), but I don't think that will help if the underlying chatty broadcaster are still playing around the media.

the obvious impact is if that bogus arp claiming it self as the subnet gateway.
If we are facing a purposeful attack, no doubt. But if we got this far, there are bigger fish to fry. One possible solution would be to just turn of the offending ethernet port. This brings a host of new problems, and this isn't the place to discuss them.

Yes, this is a possible scenario. But You have to remember that the real gateway would still answer to MAC requests. It would even be in a better place to do so, with its ARP table still sort of working.

But, no. This isn't to say "just do this and everything will be fine". This is a suggestion to improve the resilience of the device.
 
wiseroute
Member
Member
Posts: 352
Joined: Sun Feb 05, 2023 11:06 am

Re: Encountered an ARP table exhaustion attack

Sat Jun 03, 2023 5:56 pm

@ paternot
This brings a host of new problems, and this isn't the place to discuss them.
...
This isn't to say "just do this and everything will be fine".
could not disagree.
But You have to remember that the real gateway would still answer to MAC requests.
absolutely. as i said in my previous post :
layer 2 port mac security do help in minimizing the breakout chance. while the vlan gateway firewall being the second layer of protection.

nice discussion. thank you 👍🏻
 
pe1chl
Forum Guru
Forum Guru
Posts: 10183
Joined: Mon Jun 08, 2015 12:09 pm

Re: Encountered an ARP table exhaustion attack

Sat Jun 03, 2023 6:39 pm

ok. the mac table is full. traffic dropped.
let's clear up some old inactive entries.
The problem is that the entries that make your table overflow are neither old nor inactive.
They probably are waiting for the targeted machine to answer to the ARP query, and when that answer comes in to send the packet.
So you want to delete unresolved ARP entries? But which ones? The latest unresolved one may be a good candidate, but still if the
rate of the "scan" is high enough it may cause a DoS.
1. if that chatty broadcaster stopped, then the forwarding media is good to go. - again that is if.
It is not a broadcaster. If it were, there would be no issue.

The solution is to have less IP space in directly connected networks than you have space in your ARP table.
(and of course the same applies to MAC table in the bridge/switch)

For that, you may be able to set some limits, but at least you could decrease your subnet sizes.
 
wwj
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 55
Joined: Mon May 05, 2014 6:37 am

Re: Encountered an ARP table exhaustion attack

Tue Jun 06, 2023 6:27 am

1. Thank you for your wonderful discussion and help

2. /ip settings max highbor entries=65536, which is very useful as I was not aware of this parameter before

3. This behavior of scanning IP addresses on a large scale may not be an attack, but rather the working mechanism of certain software, such as some LAN communication software that discovers online people by scanning the network on a large scale. However, this poses a serious threat to the stability of the network, whether the gateway uses routers, other routers, or layer three switches, all face this problem.

4. Of course, regarding 3, the carrying capacity of the network topology needs to be designed well

5. Or if ROS provides a function similar to PSD, it would be perfect. For example, it can monitor the traffic entering a certain interface within 3 seconds. If the number of dst-ips for a certain src IP reaches the set value, it can be added to the address list, so that we can better identify potential attackers
 
wiseroute
Member
Member
Posts: 352
Joined: Sun Feb 05, 2023 11:06 am

Re: Encountered an ARP table exhaustion attack

Tue Jun 06, 2023 8:17 am

@ wwj

5. Or if ROS provides a function similar to PSD, it would be perfect. For example, it can monitor the traffic entering a certain interface within 3 seconds. If the number of dst-ips for a certain src IP reaches the set value, it can be added to the address list, so that we can better identify potential attackers
of course, MT has that rate-limit feature in conjunction with its ids/ips feature. but its implementation requires your number 4 answer: network design, which the ideal one could be very expensive to afford.

the simplest way to localized such overflow - already described by @ pe1chl : which is to make layer 2/3 smaller in size ---> vlans with smaller ip subnet in it.

and is the whole reason to implement vlans --> which is to avoid break down on the whole network. see below 👇

as this :
3. This behavior of scanning IP addresses on a large scale may not be an attack, but rather the working mechanism of certain software, such as some LAN communication software that discovers online people by scanning the network on a large scale. However, this poses a serious threat to the stability of the network, whether the gateway uses routers, other routers, or layer three switches, all face this problem.
yes. sure. there are many legitimate app in that nature - you name it: ip arp, snmp, lldp etc.

so the important thing is to create boundaries of those chatty protocols came from internal infrastructure side and those chatters from end-users side (that includes computers viruses, wrong cpe config, some maybe doing tests etc).

anyway, just sharing some thoughts 🤔
 
rime
just joined
Posts: 18
Joined: Wed Jul 12, 2017 8:57 pm

Re: Encountered an ARP table exhaustion attack

Thu Dec 21, 2023 11:39 am

my ccr1072 conn to switch ,and created 100 vlanif ,ip-address like 192.168.0.1/24,192.168.1.1/24,192.168.2.1/24,192.168.3.1/24………………192.168.100.1/24
so ,it have 256*100=25600IPs , Actually, there aren't so many hosts, vlans are just dividing for management purposes

A few days ago, I was attacked by a host in a local area network,This host scans the local area network segment 192.168.0.0/16, and CCR1072 needs to forward the data packet to the local area network where its vlanif is located. However, it needs to initiate an ARP request to obtain the MAC address of the host in the local area network. At this time, the ARP table looks like this:

8144 DC 124.93.29.83 B0:2C:71:E5:00:80 vlan1008
8145 DC 192.168.70.132 B4:05:5D:0A:ED:AA vlan0699
8146 D 192.168.80.252 vlan0807
8147 D 192.168.70.225 vlan0699
8148 DC 192.168.80.55 00:50:56:93:AD:02 vlan0801
8149 D 192.168.66.170 vlan1066
8150 D 192.168.11.51 vlan0903
8151 D 192.168.82.147 vlan0904
8152 D 172.23.64.178 vlan3544
8153 D 192.168.78.18 vlan2002
8154 D 192.168.87.7 vlan0844
8155 D 192.168.68.161 vlan1068
8156 D 192.168.67.150 vlan1067
8157 DC 172.24.2.67 00:50:56:9B:13:F9 vlan0036
8158 D 192.168.9.100 vlan1090
8159 D 192.168.95.29 vlan0862
8160 D 192.168.9.106 vlan1090
8161 D 192.168.90.204 vlan0853
8162 D 192.168.64.180 vlan1064
8163 D 192.168.9.252 vlan1090
8164 D 192.168.83.124 vlan0827
8165 D 192.168.93.103 vlan0858
8166 D 192.168.88.161 vlan0849
8167 D 192.168.82.252 vlan0904
8168 DC 192.168.89.235 00:50:56:93:19:6B vlan0851
8169 D 192.168.9.59 vlan1090
8170 D 192.168.84.142 vlan0834
8171 D 192.168.85.253 vlan0839
8172 D 192.168.88.188 vlan0849
8173 D 192.168.67.186 vlan1067
8174 D 192.168.66.38 vlan1066
8175 D 192.168.87.139 vlan0846
8176 D 172.18.6.94 ether1
8177 D 192.168.88.124 vlan0848
8178 D 192.168.80.221 vlan0806
8179 DC 192.168.70.16 B4:05:5D:0C:77:93 vlan0699
8180 D 192.168.66.8 vlan1066
8181 D 192.168.9.251 vlan1090
8182 D 192.168.86.23 vlan0840
8183 D 192.168.87.242 vlan0847
8184 D 192.168.64.179 vlan1064

It was filled up !with a total of 8184 ARP tables,At that point, the router cannot obtain the actual ARP of the host in a timely manner, resulting in delays and packet loss
In the end, this multi IP large-scale scanning behavior was discovered and the source address was blocked in the firewall, restoring the network to normal

I know,we have PSD to find the ports-scaner , but in this case , How should we protect ourselves? and Can the ARP table be expanded?
Hi, we have same problem as you on same router. How did you manage to find source ip address? Using packet sniffer for just arp mac protocol?

Who is online

Users browsing this forum: coreshock, Railander, sted and 74 guests