DDoS pfSense dies on XSYN and OVH scripts.
-
Look at the ping to the LAN side of pfSense…
http://youtu.be/HoGQ_2sg0J0
LAN goes offline and tries to keep going. On the test server I see maybe 25mbit of traffic and nothing that renderes it useless at all.
Pf just dies completely. With this I can take down any site running pfSense if I want to.
If you run Windows FW on the server with no pfSense infront, no issues.
-
FYI, your public IP is shown on your interfaces widget.
Another FYI, I get a nice stable ping to your gateway. Nice upstream :-)
Ping statistics for 80.x.x.x:
Packets: Sent = 149, Received = 149, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 138ms, Maximum = 141ms, Average = 139ms4 15 ms 15 ms 16 ms tengigabitethernet4-4.ar7.chi1.gblx.net [67.17.213.117]
5 108 ms 107 ms 108 ms 4.68.110.157
6 103 ms 103 ms 103 ms ae-116-3502.edge3.London1.Level3.net [4.69.166.134]
7 103 ms 103 ms 103 ms ae-116-3502.edge3.London1.Level3.net [4.69.166.134]
8 138 ms 138 ms 138 ms tdcdenmark-level3-xe.london1.Level3.net [4.68.63.90]
9 139 ms 140 ms 140 ms ae1-0.taanqe10.dk.ip.tdc.net [83.88.22.247]
10 140 ms 140 ms 141 ms cpe.ae11-388.taanqe10.dk.customer.tdc.net [62.243.131.198]
11 139 ms 139 ms 140 ms 80.x.x.x -
:D Its my home network so I dont care about that.
Just removed Squid to see if it handles traffic better…
Edit: It didnt.... :(
-
And the forum goes down at once as well.
Its the engine of PfSense thats the issue here. There is core functionality hit here and nothing done in the gui or elsewhere can prevent it.
-
So what's up here? Anyone tested this on FreeBSD?
-
Spoofed packet attacks may be used to overload the kernel route cache. A
spoofed packet attack uses random source IPs to cause the kernel to generate
a temporary cached route in the route table, Route cache is an extraneous
caching layer mapping interfaces to routes to IPs and saves a lookup to the
Forward Information Base (FIB); a routing table within the network stack. The
IPv4 routing cache was intended to eliminate a FIB lookup and increase
performance. While a good idea in principle, unfortunately it provided a very
small performance boost in less than 10% of connections and opens up the
possibility of a DoS vector. Setting rtexpire and rtminexpire to two(2)
seconds should be sufficient to protect the route table from attack.
http://www.es.freebsd.org/doc/handbook/securing-freebsd.html
net.inet.ip.rtexpire=2 # (default 3600)
net.inet.ip.rtminexpire=2 # (default 10 )
#net.inet.ip.rtmaxcache=128 # (default 128 )Anybody has any comments on this because it seems to be deep within the routing stack that this occurs.
-
Just out of curiosity, why would you want to store individual IP addresses in a routing table? Isn't that the whole point subnet masks and routing tables?
-
I dont know… its nowhere to be found in pfSense so I added it manually to get rid of it...
-
So, is there progress being made in coming up with a set of safe defaults that mitigate this attack in 2.2.1?
-
So the change helped?
It sounds like the best thing might be to completely disable. Since that probably can't happen, I wonder if there are values smaller than 2 seconds that may be better. I could see low end boxes being much more sensitive to this issue. A lot of packets can come in a 2 second window with more and more people getting 100Mb+ connections.
-
It didnt help. It takes this forum and store.netgate.com down as well easily.
Throughput needs only to be about 20mbit before it dies and cant handle the traffic.
Its no issue if you use windows firewall as the frontend and the webserver itself can easily handle the traffic both regarding backlog and overall traffic and packets.
Its pfSense related and take it down instantly.
-
-
I havent tested it on FreeBSD.
So I cant relate to that. You are more than welcome to provide me with a FreeBSD target on PM, so we can test.
Its pfSense related and take it down instantly.
So it does NOT happen on FreeBSD?
-
Its pfSense related and take it down instantly.
So it does NOT happen on FreeBSD?
I tried it on a clean freeBSD 10.1
- it was much better than pfsense, not saying that is was 100% up, it had some packetloss as well, but no more then pfsense which instantly or mostly get 90-100% packetloss.
It was without any tuning as well on freebsd 10.1
- it was much better than pfsense, not saying that is was 100% up, it had some packetloss as well, but no more then pfsense which instantly or mostly get 90-100% packetloss.
-
"but no more then pfsense which instantly or mostly get 90-100% packetloss"
So was it less or more. Same? how much less or more?
-
"but no more then pfsense which instantly or mostly get 90-100% packetloss"
So was it less or more. Same? how much less or more?
It really depend on the attack method. SYN-ACK or SYN-FIN, packet size etc.
But after over 100 test i would still say pfsense could have done it better. It is not handling SYN request correctly. I don't have the skills to fix it or go deeper into it.
Result:
FreeBSD 10.1 = every 7-8th ping = packetloss (avg packetloss 10-20%)
PFsense = every 1-2nd ping packetloss (avg packetloss 80-90%)So there is a notable difference clearly. PFsense was running stateful. Stateless helped a little bit.
-
Anybody with serious freeBSD skills wanting to help us test this??
Money could be involved :D
-
I wonder if getting someone from the FreeBSD forums may be useful at this point.
-
We have had ZERO response from the pfSense guys. This is quite disturbing since we can take down any site protected by pfSense as it is.
Right now its better to run without pf at all and rely on windows Firewall on VM's and let pf handle the routing. Only way to survive the attacks as it is.
Thinking og getting my old ISA2006 online again to test and see how it behaves.
-
A little more…
http://youtu.be/boa7bbeKRG0
Now we can limit the states that is created but basic routing is not working....still.