Help with stateless firewall
Hello NetFilter,
Iam working with a stateless firewall to help keep up with DoS and a state flood. I have a few doubts about my setup:
a.) When allowing web traffic, is it neecessary to allow port range 1000:65535 ? i saw that due to this rule sending packets to those ports directly respond with a REJECT instead of a DROP which is preffered. Any work arround and still have a stateless setup?
b.) What is needed to safely have a default OUTPUT DROP, apparently as soon as i change it to that iam unable to access it via ssh, even if I add a rule like this: /sbin/iptables -A OUTPUT -p tcp --dport 22 -j ACCEPT
Thanks for your help.
Alex
#!/bin/bash
/sbin/iptables -F/sbin/iptables -X
/sbin/iptables -P INPUT DROP/sbin/iptables -P FORWARD DROP/sbin/iptables -P OUTPUT ACCEPT
#ICMP IN/sbin/iptables -A INPUT -p icmp -s 178.174.50.29/24 -j ACCEPT
#ICMP IN (TRACEROUTE)/sbin/iptables -A INPUT -p icmp --icmp-type 0 -j ACCEPT /sbin/iptables -A INPUT -p icmp --icmp-type 11 -j ACCEPT
#ICMP OUT/sbin/iptables -A OUTPUT -p icmp --icmp-type 8 -j ACCEPT
#DNS RESOLVERS/sbin/iptables -A INPUT -s 63.15.64.91 -j ACCEPT/sbin/iptables -A INPUT -s 63.15.64.92 -j ACCEPT
#SSH/sbin/iptables -A INPUT -p tcp --dport 22 -j ACCEPT
#WEB/sbin/iptables -A INPUT -p tcp --dport 1000:65535 -j ACCEPT /sbin/iptables -A INPUT -p tcp --dport 80 -j ACCEPT
Quoted 2 lines · Alex Flex
Iam working with a stateless firewall to help keep up with DoS and a state flood. I have a few doubts about my setup:
What is a "state flood"? Why do you think a stateless firewall is superior, or even desirable?
Quoted 2 lines
a.) When allowing web traffic, is it neecessary to allow port range 1000:65535 ?
Regardless of the inbound port or protocol, for most, you *must* accept return traffic, or the connection cannot be made.
Quoted 5 lines
i saw that due to this rule sending packets to those ports directly respond with a REJECT instead of a DROP which is preffered. Any work arround and still have a stateless setup?
b.) What is needed to safely have a default OUTPUT DROP,
rob0 Rule of Thumb: If you need help to make it work, you do not need OUTPUT filtering. Just say No to DROP. :)
Why do you want OUTPUT DROP? What are you defending against? Generally a stronger and more effective defense against hostile system users would be something like SELinux. Another good idea:
don't give untrusted people shell access.
Quoted 3 lines
apparently as soon as i change it to that iam unable to access it via ssh, even if I add a rule like this:
/sbin/iptables-A OUTPUT -p tcp --dport 22 -j ACCEPT
See --sport in the manual. It seems that you have confused what you might have as source or destination port.
Quoted 4 lines
Thanks for your help.
Alex#!/bin/bash
[snip]
Scripting like this is the wrong way to go about loading a ruleset. Dump your ruleset using iptables-save(8) and load it at boot time using iptables-restore(8). These might help:
http://inai.de/links/iptables/
http://inai.de/documents/Perfect_Ruleset.pdf
Signature · 2 lines
http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Hello Rob,
Quoted 5 lines · On 08/12/2013 03:41 PM, /dev/rob0 wrote:
Quoted 2 lines · Alex Flex
Iam working with a stateless firewall to help keep up with DoS and a state flood. I have a few doubts about my setup:
What is a "state flood"? Why do you think a stateless firewall is superior, or even desirable?
With a state flood, i meant a syn flood for example. My experience has taught that small bandwith attacks (those that my uplink stands) are done based on my state table reaching its limits.
Knowing this, do you think I should have taken another approach?
Is there anyway I can assign conntrack resources per chain, this would greatly help at isolating damage.
The OUTPUT deny is a paranoid method to have a more complete understanding of that traffic and future applications cannot misbehave so easily. It is not meant to guard from ssh users.
I agree with Rob0 , but the problem here is that you do not specify WHAT you are doing from your machine . From your rules , it's obvious you are running a SSH and WEB deamon on this machine .
Quoted 1 line
a.) When allowing web traffic, is it neecessary to allow port range 1000:65535 ?
However you do not need to open port 1000-65535 for this or any other reason , except MAYBE return traffic from your machine . Since your mail does not specify any traffic originating from this machine , it should not be needed !
IF however you use this machine for "client" access , you should rather add source ports (--sport) for each client ports you need on INPUT .
Typical you need port 53 UDP and TCP for name resolution , and you should consider opening up for ICMP TYPE 3 for error messages . Adding your DNS servers IP and allowing all traffic from them is possible , but I think this is bad solution . ( not best practice )
Quoted 3 lines
b.) What is needed to safely have a default OUTPUT DROP, apparently as soon as i change it to that iam unable to access it via ssh, even if I add a rule like this:
/sbin/iptables-A OUTPUT -p tcp --dport 22 -j ACCEPT
DROP OUTPUT fails because you don't have any source ports allowed ,
/sbin/iptables -A OUTPUT -p tcp --sport 22 -j ACCEPT /sbin/iptables -A OUTPUT -p tcp --sport 80 -j ACCEPT
And you will also need to ADD rules for DNS traffic going out
/sbin/iptables -A OUTPUT -p udp --dport 53 -j ACCEPT /sbin/iptables -A OUTPUT -p tcp --dport 53 -j ACCEPT
ATLEAST !!
Quoted 1 line
i saw that due to this rule sending packets to those ports directly respond with a REJECT instead of a DROP which is preffered.
This is because you have made a rule ACCEPTing port 1000-65535 INPUT , and also made a default rule ACCEPTing tcp nack OUTPUT
Quoted 1 line
Any workaround and still have a stateless setup?
Well yes , remove/replace the port 1000 - 65535 opening INPUT ! ( or DROP tcp nack OUTPUT , which would just be silly )
I cannot tell you anymore since there is not any more info on what you are doing , But adding a LOG statement in INPUT and OUTPUT before the DROP should help you spot any trouble .
Kind Regards André