Hi, I´m looking for a solution to limit a PPPoE connection request attack (PADI). I have some users that sometimes sends a lot of PADI frames requests at same time and overload our radius server (even using a very fast machine and increasing a lot radius parameters).
I searched about this on Internet and discovered that professional PPPoE concentrators limits it natively with a max connection request per minute/second option for each MAC address (this is a very common attack for PPPoE). Well MKT PPPoE doesn´t have this kind of protection so I looking for a solution to stop this kind of attack.
The first thing I tried to do was to analyze radius log per minute and search for a MAC address which is sending too much connection requests and try to block it. The problem is that I cannot find a way to block a MAC address to not send more PADI frames to Mikrotik. I can only create rules in MK to block a PPPoE traffic in bridge mode but I cannot use bridge mode when acting as a PPPoE Server (at least not in the same interface).
I already asked to MK support team and they confirmed that it´s not possible to be done on the same MK machine (I need a second MK machine acting as bridge before PPPoE server just to do it, what is not a viable solution).
Some time ago I read something in this forum that someone did some trick to solve it but I lost this message.
If someone here have some idea to do that please I´m accepting suggestions.
interesting , today i was thinking in such post in forum and make a feature request. you did it first.
i think it is a MUST for each PPPoE concentrator . now i have more than 20 users which eat a lot of my resources.
about the bridge solution , i done it but if your pppoe users come from vlans this solution does not works and you just can block that mac address not just block the padi packets or limit them. i said the problem of the bridge to support and they said it will be solved in next version.
This is a VERY interesting post to me, I am planning to phase out a FreeBSD PPPoE server and this is the single problem that is worrying me the most.
It’s curious when you say you can’t run a PPPoE server in a bridge because I do exactly that. I create a bridge with just one interface so I can place filters to pass only PPPoE Discovery and PPPoE Session protocols. Then I run the PPPoE server in that bridge.
My question is: assuming we can run the server in a bridge, how can we take advantage of that to limit the PADI packets? Has someone already implemented this? How the rules should look?
I don´t think it. You can´t solve this problem with a single rule.
You can create a rule to limit PADI frames in brigde firewall table but you can´t do it per MAC address. If you create such kind of rule all PADI frames will be limit not only the attacker frames. MK bridge rules are based on ebtables which doesn´t have this option (like iptables hash-limit per user IP address).
So what I was trying to do is create an external script to logging into MK (by telnet for example since MK doesn´t have snmp write suppport) and insert individual rules for each MAC address generating an attack. Of course this is not a wonderfull solution but was the only way a found to reduce my problem.
I thought to do exactly this, create a bridge with a single interface and create PPPoE on that bridge, but I thought this was a weird solution that could cause some problem or performance issue.
I saw we are on the same country so we could exchange some ideas about it.
…apparently there is no performance issue. It’s pretty comfortable to filter every other protocols, saves a lot of headaches.
Looking closer, you are right about the rule being too broad and include non-attackers. I am shure we are not the first ones with this problem but I couldn’t find any answer yet.
i think this such bridge solutions are just for temporary deleting the question and it is not the answer.
mikrotik should implement a way like maximum pppoe requests per mac per minute and with one mikrotik not with another bridge.
Looking from another angle, limiting global PADI packets per second protects your Radius server and only penalizes new connections, not the established ones.
i think this such bridge solutions are just for temporary deleting the question and it is not the answer.
mikrotik should implement a way like maximum pppoe requests per mac per minute and with one mikrotik not with another bridge.
Such a feature would be neat.
However, you can’t have per minute mac-queues. Consider a flood of 100.000 requests with random src-mac-addresses?
Instead you would need a global queue that only responds to $X number of unique PPPoE-Discovery requests per second.
Something along the lines of:
Make a queue that is $C long.
Have a receiver thread that puts all incoming requests in a queue, if src-mac-address is not already in queue.
If queue is full, drop request.
Have a responder thread;
Copy the queue to temporary buffer (pointer shuffle?)
Traverse the queue entry by entry and respond to $X requests.
Delay $W millisecond between each $X requests (wait between bursts as a trade off to scheduler efficiency).
Free/swap buffer and start over.
HOWEVER:
Neither a discovery throttling solution, nor encryption (MPPE), would negate the enormous weaknesses of PPPoE-session traffic.
And let’s not forget the enormous weaknesses of the carrying L2 network that connects the PPPoE server with the PPPoE client.
If a user has L2 access to the core of the network then you are probably already at their mercy.
You could possibly use rate-limiting and bridge filter rules at customer edge to keep the needle eye small, but to remove it completely requires a different strategy all together.
So even though a discovery throttling solution would help the server stay running, when a normal pppoe-client is on the fritz, the core of the problem must be solved elsewhere (closer to the customer edge).
now i have more than 50 ADSL users (which their credit is finished ) connect through pppoe and they have configured their modem to auto connect . each user have 3 pppoe connection per second . i think for an advanced concentrator there must be a feature to prevent this kind of problems.
think these users grow to 500 !!!
please dont say me to disable their ports etc . i know them but they are just for temporary solutions.
Allow the users to connect to the concentrator but give them address from a private address range (for example 192.168.0.x/24). Then add a few rules to the firewall to drop everything from the user except www (port 80) traffic. NAT your www traffic to a web server which have a simple web page which tells the users that their credit is finished and call your support to buy new credits.
Most of the Hungarian service provider do this. We had the same trouble and got a lot of call from the users about something wrong with their connection. Now the user see a web page and know what to do. And there is no connection requests.
Advanced concentrators have exactly the feature I mention on this topic. At really I discovered this reading comercial PPPoE concentrators documentation. All them have this because it´s a very basic protection.
We limit all PPPoE users to one session only. We have run into issue where end user puts PPPoE in both there PC and there router. Its weird, you would think the router would block the out going PPPoE request from the PC but not all router models do. A result is you constantly see one or other trying to log in and filling up log file.
What would be nice is a firewall rule that if it sees more then 5 failures in 60 seconds the MAC is banned(banned from log too) for 60 seconds and if it keeps trying its stays banned untill it stops trying for at least 60 seconds.
Kind of like the IPTABLES rules we use to block SSH brute force attacks on our linux servers:
I have to agree with both “josefranco” and “omidkosari”
Basic discovery throttling should be available. Anything else could easily lead to unintentional DoS and pretty severe performance problems.
I mean, what if the discovery requests are sent with a spoofed src-mac-address at a very high rate and then you have PPPoE servers responding at that very high rate. We know what happens when the dst-mac-address does not exist on the L2 network, the packet gets flooded on all switch/bridge ports throughout that entire L2 network (some switch firmwares even flood it to all ports regardless of vlan). So not only is a high rate of broadcast generated from the client (which are to be sent to all on same L2) but also all the pppoe-discovery replies sent to everyone as well. That’s a recipe for disaster. And the worst part is, it doesn’t even have to be malicious intent behind it, just a pppoe client gone haywire.
