Help with stateless firewall

Help with stateless firewall

[Alex Flex]

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

Re: Help with stateless firewall

[/dev/rob0]

On Mon, Aug 12, 2013 at 01:28:59PM -0600, Alex Flex wrote:
> 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?

> 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.

> 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.

> 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.

> 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
-- 
  http://rob0.nodns4.us/ -- system administration and consulting
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

Re: Help with stateless firewall

[Alex Flex]

Hello Rob,

On 08/12/2013 03:41 PM, /dev/rob0 wrote:
> On Mon, Aug 12, 2013 at 01:28:59PM -0600, Alex Flex wrote:
>> 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.

RE: Help with stateless firewall

[André Paulsberg]

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 .

> 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 )

> 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 !!


> 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 


> 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é