Syn flood question
-
i am working on that, but if they can't sort it out on their end i want to be able to filter it on my end. bandwidth is not a problem. i just want to filter out the attacks.
-
Spoofed source SYN floods where you're permitting the traffic are going to elicit SYN ACKs in response going back to the spoofed source IP. A lot of people are too dumb to realize a random SYN ACK isn't "port scanning", it's just backscatter from a spoofed SYN flood. An unfortunate reality of being on the Internet. Our datacenter with ~300 public IPs gets a slew of it, customer systems with hundreds or thousands of public IPs, the same.
The only way to prevent SYN ACK responses to spoofed SYN floods is to block all traffic to the impacted service. Sometimes, rarely, you can differentiate SYN flood traffic from legit SYNs, examining a packet capture of the traffic will tell you whether that's the case.
-
there's no way to differentiate between spoofed and not spoofed ip's in pfsense?
the thing is i tried to enable the synproxy state for the wan ip - incoming http traffic port 80 but when i do that, the http dies completely. i tried resetting the states after doing that but it completely killed the http server.
i am posting my custom added rules below, maybe it helps for a suggestion.
the thing that baffles me is that the blocking out tcp syn fin rst etc rule, did not take effect today when the server was under attack. traffic still went out.
anchor "userrules/*"
block in quick on $WAN reply-to ( em0 gateway_ip ) inet proto tcp from pfsense_ip to any label "USER_RULE: block out FIN SYN RST PSH ACK URG"
block in quick on $WAN reply-to ( em0 gateway_ip ) inet proto tcp from pfsense_ip to any port 1234 label "USER_RULE: block so i don't get replies for the syn shit"
block in quick on $WAN reply-to ( em0 gateway_ip ) inet from abuser_ip to pfsense_ip label "USER_RULE: abuser"
block in quick on $WAN reply-to ( em0 gateway_ip ) inet from abuser_ip to pfsense_ip label "USER_RULE: abuser"
pass in quick on $WAN reply-to ( em0 gateway_ip ) inet proto tcp from any to pfsense_ip port 80 flags S/SA keep state label "USER_RULE"
pass in quick on $WAN reply-to ( em0 gateway_ip ) inet proto tcp from any to pfsense_ip port 443 flags S/SA keep state label "USER_RULE: pass ssl traffic"
pass in quick on $WAN reply-to ( em0 gateway_ip ) inet from my_ip to pfsense_ip keep state label "USER_RULE: Easy Rule: Passed from Firewall Log View"
pass in quick on $WAN reply-to ( em0 gateway_ip ) inet from my_ip to pfsense_ip keep state label "USER_RULE: Easy Rule: Passed from Firewall Log View"
pass in quick on $WAN reply-to ( em0 gateway_ip ) inet from random_server_of_mine to pfsense_ip keep state label "USER_RULE: Easy Rule: Passed from Firewall Log View"
pass in quick on $WAN reply-to ( em0 gateway_ip ) inet from random_server_of_mine to pfsense_ip keep state label "USER_RULE: Easy Rule: Passed from Firewall Log View"
pass in quick on $LAN from 192.168.100.0/28 to any keep state label "USER_RULE: Default allow LAN to any rule" -
there's no way to differentiate between spoofed and not spoofed ip's in pfsense?
There's no way to do that with any firewall, router, or any other device.
synproxy is almost never a good idea.
You're allowing the SYN, the SYN ACK in response gets permitted by the state table. That's how every firewall works. If you don't want the SYN ACK going out, don't allow the SYN.
-
You might also want to check a related discussion at openbsd-misc which I re-posted some time ago http://forum.pfsense.org/index.php/topic,46897.0.html - iirc the DDoS victim was given more advice off-list.
-
@cmb:
You're allowing the SYN, the SYN ACK in response gets permitted by the state table. That's how every firewall works. If you don't want the SYN ACK going out, don't allow the SYN.
i am wondering why does the ack still go out since i have a firewall rule that blocks it:
anchor "userrules/*"
block in quick on $WAN reply-to ( em0 gateway_ip ) inet proto tcp from pfsense_ip to any label "USER_RULE: block out FIN SYN RST PSH ACK URG"as posted in the first screenshot, i have modified that to match outgoing packets with syn ack flags. doesn't seem to work.
-
@cmb:
You're allowing the SYN, the SYN ACK in response gets permitted by the state table. That's how every firewall works. If you don't want the SYN ACK going out, don't allow the SYN.
i am wondering why does the ack still go out since i have a firewall rule that blocks it:
You quoted the answer to that. Rules are never evaluated for already-permitted connections with any firewall.
-
i made the following modification to the http allow as shown in the picture. will this work with not allowing syn, and blocking outgoing acks? also i notice no service impact. do you reckon if this could backfire?
nevermind that it backfired already. all traffic died once i blocked the syn :) i am retarded.
what if i add the 2 rules for blocking outgoing syn/fin and block outgoing port 1234 (the backscatter from the ddos) to floating rules? as far as i understand, those take priority before the default rules. am i anywhere close?
-
shameless bump :)
-
@cmb:
@cmb:
You're allowing the SYN, the SYN ACK in response gets permitted by the state table. That's how every firewall works. If you don't want the SYN ACK going out, don't allow the SYN.
i am wondering why does the ack still go out since i have a firewall rule that blocks it:
You quoted the answer to that. Rules are never evaluated for already-permitted connections with any firewall.
not sure how many times I have to repeat the same thing, I'll just quote it.
Again - you cannot prevent the SYN ACKs from going out (with any stateful firewall), you have to block the SYN if you don't want a SYN ACK. Even if you could, you would break all TCP connections to the impacted service since that can't differentiate legit SYNs from flooded SYNs.
-
ok it's in my head now. so i need to look at an appliance dedicated to syn ddos filtering since with pfsense i can't mitigate this right?