Forum running slow again?
-
Interestingly, it's working fine IPv6.
-
Its must be a misconfigured appliance somewhere :D
read: Supermule is DDoSing us again. We banned him after this admission (no one other than whoever launched the attack could have any knowledge that's what was occurring), and as soon as he saw that, it came back. The attack that started immediately after he saw he was banned is still going on, now the longest of any attack that's been launched at us.
Interestingly, it's working fine IPv6.
Only getting DoSed on IPv4 so only null routed the v4 IP. Only reachable on IPv6 at the moment, until either the attack stops, or we finish architecting around the issue.
-
@cmb:
read: Supermule is DDoSing us again. We banned him after this admission (no one other than whoever launched the attack could have any knowledge that's what was occurring), and as soon as he saw that, it came back.
-
So is it a proper DDoS or is it something tickling the asserted problem in pfSense SYN handling?
-
So supermule botnet doesn't have ipv6 capabilities ;) hehehehe
-
supermule (who's name is really Brian) is unlikely to have a botnet. He has a bit of code, written by someone else, that he loves to inflict on innocent parties. That code doesn't do anything with IPv6.
This whole thing is Charlie Foxtrot.
-
We banned him after this admission…....
So why we can see him even here in the forum if he is banned?
-
@BlueKobold:
We banned him after this admission…....
So why we can see him even here in the forum if he is banned?
"Banned" typically means "login disabled". It would take a bit more effort to scrub the database of posts.
-
So is it a proper DDoS or is it something tickling the asserted problem in pfSense SYN handling?
100K new connections/sec sustained of passed traffic is more than a C2758 will handle. Every DDoS that's been targeted at us has been a "proper DDoS", e.g. more new connections/sec than a C2758 can handle. More than most commercial firewalls can reasonably handle for that matter.
No super-top-secret recipe, just blast 100K/sec of spoofed source SYNs.
-
@BlueKobold:
We banned him after this admission…....
So why we can see him even here in the forum if he is banned?
He was only banned, didn't delete his account.
-
@cmb:
@BlueKobold:
We banned him after this admission…....
So why we can see him even here in the forum if he is banned?
He was only banned, didn't delete his account.
Ahh, my thinking fault, thanks for the enlightenment!
-
It's kinda funny that one guy with a simple script can bring down your any for that matter any pfsense protected network ::)
Makes you think… -
It's kinda funny that one guy with a simple script can bring down your any for that matter any pfsense protected network ::)
Makes you think…No, any stateful firewall protected network where you're passing any traffic from untrusted networks. How big of an attack you can take in that case depends on how big of a box you have. To handle the number of new connections/sec that was thrown at us with a Cisco ASA, you'd need one of the two biggest 5585-X models. Starting at about $100K USD. And you wouldn't be too far from their stated new connections limit. Hence the "fundamental misapplication of technology" re: using a stateful firewall to process a DDoS (or DDoS-like traffic, just spoofed source often).
-
cmb/jwt/johnpoz/et al: thanks for getting the problems squared away; yesterday felt like a junkie trying to get a fix. :o
It's always about resources. You can get hardware to handle the raw packet load, but then you spend all your time throwing the bad packets away and not doing any useful work. 5 gallon bucket with a 1 gal/minute drain getting filled at 2 gallons/minute, something has to give. Getting a bigger bucket delays the inevitable. Getting a 3 gal/minute drain works until you start filling at 5 gal/minute.
-
spoofed-DDOS (sDDOS, a new acronym?) really should be stopped at each ISP before it gets onto the internet backbone:
a) Customers with public IPS:
Each ISP has customers connected and knows what public IPs it has allocated to those customers. If it receives any packets from a customer with a source IP that is not one of the customer's proper allocated public IPs then drop the packet.b) Customers who are not given public IPs but are in a CGN or similar managed by the ISP and who end up on shared public IPs:
The ISP can filter internally to make sure individual customer packets have source IPs that match the internal IP given to the customer.
In any case the ISP will NAT this stuff out to the public internet so dodgy source IPs will (should) be NATed out to be the ISP public IP. Thus the "spoofed" and "distributed" are not effective. It becomes like an ordinary "DOS".c) In regions/countries where there are small ISPs that are [not willing|can't be trusted|do not have the technical skill] to do this filtering of traffic from their customers, then the next level up part of the backbone (to which these ISPs connect) should filter traffic, making sure that the source IP of all traffic received from "small and dodgy ISP X" is actually one of the public IPs that is allocated and routed to that ISP.
If that was put in place, then end-customers could not mount spoofed DDOS attacks just from a single place.
They could still do ordinary DOS from 1 or a few of their own source IPs. But that is easier to mitigate because the firewall can have pass rules that limit the number of new connections per second from each source IP and quickly start dropping the incoming SYN packets without creating state… - which should be much less processor intensive and not fill the state table.
And of course if someone has a bot that that they have managed to get installed in 1 million hosts via some malware then they can mount a real DDOS, rather than sDDOS.
