DDoS pfSense dies on XSYN and OVH scripts.
-
After re-reading the code this morning and looking at the packet dump, it seems "tot_len" is being set and used as the IP+TCP header size.
iph->tot_len = sizeof(struct iphdr) + sizeof(struct tcphdr);
No fragmented data wielding SYN packets here.
-
I've stopped a ddos on my network setting advanced rules options to limit connections per second and total states per ip.
Then I've reduced rule blocked time.My link dropped from 100% to 30% during attack.
-
In this case, total states per IP won't help because they're spoofed.
I don't see what's so special about these packets. They're all the standard 60 length IP+TCP, and 40 length IP. Both IP and TCP checksums are valid, IP has no flags, TCP's only flag is SYN, random source ports, random Seq numbers. I must be missing something, but it looks like a normal SYN flood, but it isn't.
-
Send me a PM with your ext. IP and pfsense behind looking at port80.
Then I will flood it for 180 secs and then you will see how it responds.
It just goes offline instantly…
-
I don't know, sounds like a sure-fire way to get packet-loss on my quality graph. Almost up to a week of 0 packets lost and a 1.2ms avg ping. Maybe in a few days, once I take a picture :-)
I don't mean 0.0% packet-loss, I mean 0 packets in actual numbers. I already have 0.0%, but there's some red on that quality graph.
-
Chris would get back to us with testing IP but not heard anything yet.
-
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.
