Is this firewall good enough?

Is this firewall good enough?

[Sagara Wijetunga]

Hi all

I have set up my first firewall using iptables. I want
to check with more experienced users of iptables
whether my firewall is good enough to protect the
server.

My server expressly offer following services only:
1.  FTP server
2.  SSH server
3.  SMTP server
4.  DNS server
5.  HTTP server
6.  POP3 server
7.  IMAP server
8.  HTTPS server
9.  SMTP over SSL
10. IMAP over SSL
11. POP3 over SSL

I have set up the firewall with following rules:

1.  /sbin/iptables -A INPUT -s 127.0.0.1 -d 127.0.0.1
-j ACCEPT
2.  /sbin/iptables -A INPUT -p tcp -m state --state
ESTABLISHED,RELATED -j ACCEPT
3.  /sbin/iptables -A INPUT -p tcp --dport 20  --syn
-j ACCEPT	#ftp-data
4.  /sbin/iptables -A INPUT -p tcp --dport 21  --syn
-j ACCEPT	#ftp
5.  /sbin/iptables -A INPUT -p tcp --dport 22  --syn
-j ACCEPT	#ssh
6.  /sbin/iptables -A INPUT -p tcp --dport 25  --syn
-j ACCEPT	#smtp
7.  /sbin/iptables -A INPUT -p tcp --dport 53  --syn
-j ACCEPT	#DNS
8.  /sbin/iptables -A INPUT -p tcp --dport 80  --syn
-j ACCEPT	#http
9.  /sbin/iptables -A INPUT -p tcp --dport 110 --syn
-j ACCEPT	#POP3
10. /sbin/iptables -A INPUT -p tcp --dport 143 --syn
-j ACCEPT	#IMAP
11. /sbin/iptables -A INPUT -p tcp --dport 443 --syn
-j ACCEPT	#https
12. /sbin/iptables -A INPUT -p tcp --dport 465 --syn
-j ACCEPT	#smtp over SSL
13. /sbin/iptables -A INPUT -p tcp --dport 993 --syn
-j ACCEPT	#IMAP over SSL
14. /sbin/iptables -A INPUT -p tcp --dport 995 --syn
-j ACCEPT	#POP3 over SSL
15. /sbin/iptables -P INPUT DROP
16. /sbin/iptables -P FORWARD DROP
17. /sbin/iptables -P OUTPUT ACCEPT

Ofcourse, the comment style #string is not included in
the real rule.

I have following queries regarding the above firewall:

1. Does this effectively offer connections ONLY to the
services I offer and nothing more than that? 

2. Does the rule 2 create any security loophole?

3. This firewall allows passive as well as non-passive
FTP connections. Is passive FTP connections   a
security threat?

4. Is this firewall good enough to protect the server?
If no, could you kindly comment how could I improve
further?

Many thanks in advance.

Kindest regards
Sagara



	
		
__________________________________
Do you Yahoo!?
Friends.  Fun.  Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/ 

Re: Is this firewall good enough?

[Feizhou]

>4.  DNS server
>2.  /sbin/iptables -A INPUT -p tcp -m state --state
>ESTABLISHED,RELATED -j ACCEPT
>  
>

Forget about this. It makes things easier yes but it is too slow if you 
come under attack...but then you put everything on one box seemly so I 
guess you don't get much traffic.

> <>7. /sbin/iptables -A INPUT -p tcp --dport 53 --syn -j ACCEPT #DNS

Where's the udp rule?

> <>1. Does this effectively offer connections ONLY to the
> services I offer and nothing more than that?

It does not open dns udp. Why do you have ssh open to the world?

> <>
> 2. Does the rule 2 create any security loophole?

Performance issues are probable.

> <>
> 4. Is this firewall good enough to protect the server?
> If no, could you kindly comment how could I improve
> further?

Why do you have ssh open to the world?

The second thing is, make sure you run secure software like djb's 
publicfile for your ftp service (example only) for the firewall ain't 
gonna protect you if you have exploitable software on the service ports.

Re: Is this firewall good enough?

[Rob Sterenborg]

> I have set up the firewall with following rules:
>
> 1.  /sbin/iptables -A INPUT -s 127.0.0.1 -d 127.0.0.1
> -j ACCEPT

You could place this rule below the next, because this rule only matches
the first packet and the rest will be RELATED or ESTABLISHED.
This is done for performance reasons. When you look at the byte counters
of each rule, you'll notice that the rule below matches the most packets
by far.
However, you don't have a large script so I think you won't notice the
difference.

> 2.  /sbin/iptables -A INPUT -p tcp -m state --state
> ESTABLISHED,RELATED -j ACCEPT

I don't think you'll use tcp only. E.g. for DNS you need udp too, see
below.
Maybe it's better not to specify a protocol at all since this rule is
supposed to match all subsequent packets that have matched below.

> 3.  /sbin/iptables -A INPUT -p tcp --dport 20  --syn
> -j ACCEPT #ftp-data

You don't need the above rule. The initial connection is made to port
21/tcp. Port 20/tcp is RELATED.

> 4.  /sbin/iptables -A INPUT -p tcp --dport 21  --syn
> -j ACCEPT #ftp
> 5.  /sbin/iptables -A INPUT -p tcp --dport 22  --syn
> -j ACCEPT #ssh
> 6.  /sbin/iptables -A INPUT -p tcp --dport 25  --syn
> -j ACCEPT #smtp

> 7.  /sbin/iptables -A INPUT -p tcp --dport 53  --syn
> -j ACCEPT #DNS

DNS uses udp for normal lookups. Only in special cases tcp is used.

> 8.  /sbin/iptables -A INPUT -p tcp --dport 80  --syn
> -j ACCEPT #http
> 9.  /sbin/iptables -A INPUT -p tcp --dport 110 --syn
> -j ACCEPT #POP3
> 10. /sbin/iptables -A INPUT -p tcp --dport 143 --syn
> -j ACCEPT #IMAP
> 11. /sbin/iptables -A INPUT -p tcp --dport 443 --syn
> -j ACCEPT #https
> 12. /sbin/iptables -A INPUT -p tcp --dport 465 --syn
> -j ACCEPT #smtp over SSL
> 13. /sbin/iptables -A INPUT -p tcp --dport 993 --syn
> -j ACCEPT #IMAP over SSL
> 14. /sbin/iptables -A INPUT -p tcp --dport 995 --syn
> -j ACCEPT #POP3 over SSL

> 15. /sbin/iptables -P INPUT DROP
> 16. /sbin/iptables -P FORWARD DROP
> 17. /sbin/iptables -P OUTPUT ACCEPT

Put these 3 on top of your script so that the server is closed (almost)
immediately, depending on the script startup order, and after that the
appropriate ports are opened.

> I have following queries regarding the above firewall:
>
> 1. Does this effectively offer connections ONLY to the
> services I offer and nothing more than that?

Yes.

> 2. Does the rule 2 create any security loophole?

No, not that I know of.

> 3. This firewall allows passive as well as non-passive
> FTP connections. Is passive FTP connections   a
> security threat?

FTP is not secure by nature ; nothing is encrypted so everything can be
sniffed etc.
You could also do sftp (from OpenSSH, also running on port 22/tcp) but
that's a subsystem of SSH and not as customizable as most FTP servers
(afaik : on or off).

> 4. Is this firewall good enough to protect the server?
> If no, could you kindly comment how could I improve
> further?

You could check for tcp_flags. Certain combinations can be logged and/or
dropped.
Packets with state INVALID could normally be safely dropped.


Gr,
Rob

Re: Is this firewall good enough?

[Antony Stone]

On Tuesday 08 June 2004 10:14 am, Sagara Wijetunga wrote:

> Hi all
>
> I have set up my first firewall using iptables. I want
> to check with more experienced users of iptables
> whether my firewall is good enough to protect the
> server.
>
> My server expressly offer following services only:
> 1.  FTP server
> 2.  SSH server
> 3.  SMTP server
> 4.  DNS server
> 5.  HTTP server
> 6.  POP3 server
> 7.  IMAP server
> 8.  HTTPS server
> 9.  SMTP over SSL
> 10. IMAP over SSL
> 11. POP3 over SSL

Are all these services being offered to *any* IP address, or do you want to 
offer some things to internal users and some things to external users 
perhaps?

> I have set up the firewall with following rules:
>
> 1.  /sbin/iptables -A INPUT -s 127.0.0.1 -d 127.0.0.1
> -j ACCEPT
> 2.  /sbin/iptables -A INPUT -p tcp -m state --state
> ESTABLISHED,RELATED -j ACCEPT

Don't restrict this just to TCP.   You need UDP as well, and ICMP will be 
important.

> 3.  /sbin/iptables -A INPUT -p tcp --dport 20  --syn
> -j ACCEPT	#ftp-data

No need for this rule given the above ESTABLISHED,RELATED rule - ftp data is 
considered RELATED to ftp-control

> 4.  /sbin/iptables -A INPUT -p tcp --dport 21  --syn
> -j ACCEPT	#ftp
> 5.  /sbin/iptables -A INPUT -p tcp --dport 22  --syn
> -j ACCEPT	#ssh
> 6.  /sbin/iptables -A INPUT -p tcp --dport 25  --syn
> -j ACCEPT	#smtp
> 7.  /sbin/iptables -A INPUT -p tcp --dport 53  --syn
> -j ACCEPT	#DNS

You need to allow UDP port 53 for DNS as well as TCP port 53

> 8.  /sbin/iptables -A INPUT -p tcp --dport 80  --syn
> -j ACCEPT	#http
> 9.  /sbin/iptables -A INPUT -p tcp --dport 110 --syn
> -j ACCEPT	#POP3
> 10. /sbin/iptables -A INPUT -p tcp --dport 143 --syn
> -j ACCEPT	#IMAP
> 11. /sbin/iptables -A INPUT -p tcp --dport 443 --syn
> -j ACCEPT	#https
> 12. /sbin/iptables -A INPUT -p tcp --dport 465 --syn
> -j ACCEPT	#smtp over SSL
> 13. /sbin/iptables -A INPUT -p tcp --dport 993 --syn
> -j ACCEPT	#IMAP over SSL
> 14. /sbin/iptables -A INPUT -p tcp --dport 995 --syn
> -j ACCEPT	#POP3 over SSL
> 15. /sbin/iptables -P INPUT DROP
> 16. /sbin/iptables -P FORWARD DROP
> 17. /sbin/iptables -P OUTPUT ACCEPT
>
> Ofcourse, the comment style #string is not included in
> the real rule.
>
> I have following queries regarding the above firewall:
>
> 1. Does this effectively offer connections ONLY to the
> services I offer and nothing more than that?

I would say yes.

> 2. Does the rule 2 create any security loophole?

Depends on the applications running on the machine and what outbound 
connections they open - for example, if someone can start netcat on the 
machine, OUTPUT is completely open, and Rule 2 will allow replies; you then 
have an open link to some system on the outside world.   However, if you 
don't trust the applications (or users) on your server, then a firewall is 
not your solution.

> 3. This firewall allows passive as well as non-passive
> FTP connections. Is passive FTP connections   a
> security threat?

Not with a stateful firewall, no.   Passive FTP is no less secure than active 
FTP.

> 4. Is this firewall good enough to protect the server?

Look good enough to me.   Of course, you haven't said how valuable the data on 
the server is, how attractive a target it might be, etc (a server run by GCHQ 
or the NSA is more likely to get challenged than a server run by Joe Brown's 
Motor Trading Company).

> If no, could you kindly comment how could I improve
> further?

You might want to add a LOGging rule at the end of the INPUT chain, just to 
get an idea of what stuff you're blocking - it's a way of finding out how 
good a job the firewall is doing for you.

Regards,

Antony.

-- 
There are two possible outcomes:

 If the result confirms the hypothesis, then you've made a measurement.
 If the result is contrary to the hypothesis, then you've made a discovery.

 - Enrico Fermi

                                                     Please reply to the list;
                                                           please don't CC me.

Re: Is this firewall good enough?

[Antony Stone]

On Tuesday 08 June 2004 10:42 am, Feizhou wrote:

> >2.  /sbin/iptables -A INPUT -p tcp -m state --state
> >ESTABLISHED,RELATED -j ACCEPT
>
> Forget about this. It makes things easier yes but it is too slow if you
> come under attack...but then you put everything on one box seemly so I
> guess you don't get much traffic.

How do you recommend dealing with reply packets instead?

Regards,

Antony.

-- 
"The future is already here.   It's just not evenly distributed yet."

 - William Gibson

                                                     Please reply to the list;
                                                           please don't CC me.

Re: Is this firewall good enough?

[Chris Brenton]

On Tue, 2004-06-08 at 05:14, Sagara Wijetunga wrote:
>
> 1. Does this effectively offer connections ONLY to the
> services I offer and nothing more than that? 

Others have commented on your rules specifically, so I'll skip that
commentary. One thing I would like to point out however is that you are
exposing 11 services to Internet connectivity. That's 11 opportunities
for someone to find a way into the box.

> 2. Does the rule 2 create any security loophole?

#2 just lets in replies to outbound traffic. Its not so much a problem
as this:

17. /sbin/iptables -P OUTPUT ACCEPT

This rule reads "If you can find a way to exploit any one of the 11
exposed services, you can use any outbound transport to pull over your
rootkit". 

> 3. This firewall allows passive as well as non-passive
> FTP connections. Is passive FTP connections   a
> security threat?

Nope, because it will be handled via inspection in your RELATED rule.

> 4. Is this firewall good enough to protect the server?
> If no, could you kindly comment how could I improve
> further?

IMHO you have two problems:
1) Too many exposed services
2) You have configured the box to act like a client and a server
resulting in even more open conduits

Also keep in mind that iptables is a packet filter, not a proxy. This
means you are not seeing any protection to payload based attacks.

So in an ideal world you would want to break up these services across
multiple boxes. You would also want to limit them to server activity
only, and not permit them to generate random outbound sessions. 

Now with all that said, it could be that you don't have the resources to
setup multiple boxes and you are stuck with this setup. If that's the
case, you are going to have to live with an elevated level of risk to
getting whacked. 

Some other things you could do to mitigate this risk:
Setup an automatic patching system
Setup Tripwire or Aide to check system integrity
Setup another system to collect the logs off of this system 
	Setup Swatch or a similar tool to check these logs
Setup an IDS

HTH,
Chris

Re: Is this firewall good enough?

[Feizhou]

Antony Stone wrote:
> On Tuesday 08 June 2004 10:42 am, Feizhou wrote:
> 
> 
>>>2.  /sbin/iptables -A INPUT -p tcp -m state --state
>>>ESTABLISHED,RELATED -j ACCEPT
>>
>>Forget about this. It makes things easier yes but it is too slow if you
>>come under attack...but then you put everything on one box seemly so I
>>guess you don't get much traffic.
> 
> 
> How do you recommend dealing with reply packets instead?

I would create multiple chains

iptables -N tcp_packets and so on.

So to avoid loading the connection tracking module, I would put rules to 
handle return packets in the proper chain.

eg: iptables -A tcp_packets -p tcp --sport 1024:65535 --dport 80 -j ACCEPT

Then i put tcp/udp/icmp packets to the proper chain

eg: iptables -A INPUT -p tcp -j tcp_packets

You could make a catch all for return packets like:

iptables -A INPUT -p tcp ! --syn -j ACCEPT

Re: Is this firewall good enough?

[Antony Stone]

On Tuesday 08 June 2004 4:03 pm, Feizhou wrote:

> Antony Stone wrote:
> > On Tuesday 08 June 2004 10:42 am, Feizhou wrote:
> >>>2.  /sbin/iptables -A INPUT -p tcp -m state --state
> >>>ESTABLISHED,RELATED -j ACCEPT
> >>
> >>Forget about this. It makes things easier yes but it is too slow if you
> >>come under attack...but then you put everything on one box seemly so I
> >>guess you don't get much traffic.
> >
> > How do you recommend dealing with reply packets instead?
>
> I would create multiple chains
>
> iptables -N tcp_packets and so on.
>
> So to avoid loading the connection tracking module, I would put rules to
> handle return packets in the proper chain.
>
> eg: iptables -A tcp_packets -p tcp --sport 1024:65535 --dport 80 -j ACCEPT

That rule allows packets *to* port 80 - I was asking how you deal with *reply* 
packets - the ones *from* port 80 on the remote server.

> Then i put tcp/udp/icmp packets to the proper chain
>
> eg: iptables -A INPUT -p tcp -j tcp_packets
>
> You could make a catch all for return packets like:
>
> iptables -A INPUT -p tcp ! --syn -j ACCEPT

You seem to be advocating not using the ESTABLISHED,RELATED match - which 
would render the firewall stateless (like ipchains) instead of stateful.   
That seems a backwards step to me - or have I misunderstood something?

Regards,

Antony.

-- 
In Heaven, the police are British, the chefs are Italian, the beer is Belgian, 
the mechanics are German, the lovers are French, the entertainment is 
American, and everything is organised by the Swiss.

In Hell, the police are German, the chefs are British, the beer is American, 
the mechanics are French, the lovers are Swiss, the entertainment is Belgian, 
and everything is organised by the Italians.

                                                     Please reply to the list;
                                                           please don't CC me.

Re: Is this firewall good enough?

[David Cannings]

On Tuesday 08 June 2004 15:03, Feizhou wrote:
> Antony Stone wrote:
> > On Tuesday 08 June 2004 10:42 am, Feizhou wrote:
> >>>2.  /sbin/iptables -A INPUT -p tcp -m state --state
> >>>ESTABLISHED,RELATED -j ACCEPT
> >>Forget about this. It makes things easier yes but it is too slow if
> >> you come under attack...but then you put everything on one box
> >> seemly so I guess you don't get much traffic.
> > How do you recommend dealing with reply packets instead?
> So to avoid loading the connection tracking module, I would put rules
> to handle return packets in the proper chain.

A lot of work has gone into connection tracking and, whilst it is entirely 
possible to implement it yourself using many flag matches, it's hardly 
worth it.  Connection tracking works very well for me and I imagine many 
others, I see no reason to try and circumvent that.

Is there any good reason not to load connection tracking?

David

Re: Is this firewall good enough?

[Feizhou]

>>So to avoid loading the connection tracking module, I would put rules to
>>handle return packets in the proper chain.
>>
>>eg: iptables -A tcp_packets -p tcp --sport 1024:65535 --dport 80 -j ACCEPT
> 
> 
> That rule allows packets *to* port 80 - I was asking how you deal with *reply* 
> packets - the ones *from* port 80 on the remote server.

Sorry, the OP was about packets to his box and not from replies from a 
box he is trying to access.

iptables -A tcp_packets -p --sport 80 --dport 1024:65535 -j ACCEPT
> 
> 
>>Then i put tcp/udp/icmp packets to the proper chain
>>
>>eg: iptables -A INPUT -p tcp -j tcp_packets
>>
>>You could make a catch all for return packets like:
>>
>>iptables -A INPUT -p tcp ! --syn -j ACCEPT
> 
> 
> You seem to be advocating not using the ESTABLISHED,RELATED match - which 
> would render the firewall stateless (like ipchains) instead of stateful.   
> That seems a backwards step to me - or have I misunderstood something?
> 

Stateful is expensive. If you have a high traffic load, it is not worth 
it. The context is when the box is a server. If you are protecting your 
home box, by all means, use stateful.

Re: Is this firewall good enough?

[Feizhou]

David Cannings wrote:
> On Tuesday 08 June 2004 15:03, Feizhou wrote:
> 
>>Antony Stone wrote:
>>
>>>On Tuesday 08 June 2004 10:42 am, Feizhou wrote:
>>>
>>>>>2.  /sbin/iptables -A INPUT -p tcp -m state --state
>>>>>ESTABLISHED,RELATED -j ACCEPT
>>>>
>>>>Forget about this. It makes things easier yes but it is too slow if
>>>>you come under attack...but then you put everything on one box
>>>>seemly so I guess you don't get much traffic.
>>>
>>>How do you recommend dealing with reply packets instead?
>>
>>So to avoid loading the connection tracking module, I would put rules
>>to handle return packets in the proper chain.
> 
> 
> A lot of work has gone into connection tracking and, whilst it is entirely 
> possible to implement it yourself using many flag matches, it's hardly 
> worth it.  Connection tracking works very well for me and I imagine many 
> others, I see no reason to try and circumvent that.
> 
> Is there any good reason not to load connection tracking?

SLOW. It isn't good enough to use on a high traffic server.

You don't even have to use stateful checks. Just do iptables -t nat -L 
-n which will load the conntrack module and boom, you've just slowed 
down your box big time network wise if you have a high packet rate.

Re: Is this firewall good enough?

[Sagara Wijetunga]

--- Chris Brenton <cbrenton@chrisbrenton.org> wrote:
> Others have commented on your rules specifically, so
> I'll skip that
> commentary. One thing I would like to point out
> however is that you are
> exposing 11 services to Internet connectivity.
> That's 11 opportunities
> for someone to find a way into the box.
> 
Here I have almost no choice, just have budget for one
server :(

> 17. /sbin/iptables -P OUTPUT ACCEPT
> 
> This rule reads "If you can find a way to exploit
> any one of the 11
> exposed services, you can use any outbound transport
> to pull over your
> rootkit". 
> 
Could you elaborate this a bit? What are the possible
outbound transports and what are the possible
solutions? 

> > 4. Is this firewall good enough to protect the
> server?
> > If no, could you kindly comment how could I
> improve
> > further?
> 
> IMHO you have two problems:
> 1) Too many exposed services
> 2) You have configured the box to act like a client
> and a server
> resulting in even more open conduits
> 
Our intension to host the server in a data center. Our
server is not required to act as a client other than
receiving mail from other STMP servers. We do not even
offer recursive DNS. Is the SMTP, the client service
that you refer? What are the other client services do
you see? What are the possible solutions?

> Also keep in mind that iptables is a packet filter,
> not a proxy. This
> means you are not seeing any protection to payload
> based attacks.
> 
Could you kindly elaborate payload based attacks? Is
it the packet rate per second? And what are the
possible solutions for payload based attacks?

> So in an ideal world you would want to break up
> these services across
> multiple boxes. You would also want to limit them to
> server activity
> only, and not permit them to generate random
> outbound sessions. 
> 
kindly elaborate this and possible solutions to not to
permit generate random outbound sessions.

> Now with all that said, it could be that you don't
> have the resources to
> setup multiple boxes and you are stuck with this
> setup. If that's the
> case, you are going to have to live with an elevated
> level of risk to
> getting whacked. 
> 
Yup, trying to live best with the limited resources
given :)

> Some other things you could do to mitigate this
> risk:
> Setup an automatic patching system
> Setup Tripwire or Aide to check system integrity
> Setup another system to collect the logs off of this
> system 
> 	Setup Swatch or a similar tool to check these logs
> Setup an IDS
> 
Could you point me to learn more into above setup
subjects?

Appreciate your and other's kind comments on this
issue. 

Sagara



	
		
__________________________________
Do you Yahoo!?
Friends.  Fun.  Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/ 

Re: Is this firewall good enough?

[Sagara Wijetunga]

--- Rob Sterenborg <rob@sterenborg.info> wrote:
> > 7.  /sbin/iptables -A INPUT -p tcp --dport 53 
> --syn
> > -j ACCEPT #DNS
> 
> DNS uses udp for normal lookups. Only in special
> cases tcp is used.
> 
I noted --syn can only be used with protocol tcp. How
do I write a similar rule to accept connections to udp
port 53?

> You could check for tcp_flags. Certain combinations
> can be logged and/or
> dropped.
> Packets with state INVALID could normally be safely
> dropped.
> 
I don't see a good explanation of tcp-flags either on
iptables man pages or Packet Filtering HOWTO. What are
meaning of SYN,ACK,FIN,RST,URG,PSH? What combinations
can be logged/dropped?

Appreciate your comment on this issue.

Sagara



	
		
__________________________________
Do you Yahoo!?
Friends.  Fun.  Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/ 

Re: Is this firewall good enough?

[Sagara Wijetunga]

--- Feizhou <feizhou@linuxmail.org> wrote:
> Antony Stone wrote:
> > How do you recommend dealing with reply packets
> instead?
> 
> I would create multiple chains
> 
> iptables -N tcp_packets and so on.
> 
> So to avoid loading the connection tracking module,
> I would put rules to 
> handle return packets in the proper chain.
> 
> eg: iptables -A tcp_packets -p tcp --sport
> 1024:65535 --dport 80 -j ACCEPT
> 
Do we have to worry at all on --sport? Our concern is
our server ports only, isn't it?

Don't we have to include --syn in above rule?

How do we accept udp connection requests on a given
destination port(ie. equivalent to --syn)?

> Then i put tcp/udp/icmp packets to the proper chain
> 
> eg: iptables -A INPUT -p tcp -j tcp_packets
> 
> You could make a catch all for return packets like:
> 
> iptables -A INPUT -p tcp ! --syn -j ACCEPT
> 
Can we consider it is either ESTABLISHED or RELATED
any packet other than --syn packet receiving on INPUT
chain?  Or how do we write rule/s equivalent to
ESTABLISHED and RELATED?

Appreciate your comment on this issue.

Sagara


	
		
__________________________________
Do you Yahoo!?
Friends.  Fun.  Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/ 

Re: Is this firewall good enough?

[Jozsef Kadlecsik]

On Wed, 9 Jun 2004, Feizhou wrote:

> > Is there any good reason not to load connection tracking?
>
> SLOW. It isn't good enough to use on a high traffic server.

Could you back your claims up with data?

At testing connection tracking we could pump trough two million concurrent
connection at 200000pps rate with opening up 20000 new connection per
second on a dual Xeon PC with Serverworks chipset and Intel copper GE
cards. Best results were achieved by Linux kernel 2.6.x with conntrack
locking and TCP window tracking patches applied and NAPI enabled.
I'd say that's not bad at all.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: Is this firewall good enough?

[Antony Stone]

On Tuesday 08 June 2004 9:11 pm, Feizhou wrote:

> > That rule allows packets *to* port 80 - I was asking how you deal with
> > *reply* packets - the ones *from* port 80 on the remote server.
>
> iptables -A tcp_packets -p --sport 80 --dport 1024:65535 -j ACCEPT

That is not my idea of a secure firewall rule - you are allowing an external 
scanner  / attacker to access the machine on any TCP port from 1024 to 65535, 
simply by setting their source port to 80.

Sheesh - we might as well go back to stateless routers with access control 
lists.

> Stateful is expensive. If you have a high traffic load, it is not worth
> it. The context is when the box is a server. If you are protecting your
> home box, by all means, use stateful.

Hm - strange, then, that Checkpoint, Cyberguard, Netscreen, Gauntlet etc. all 
seem to say that Stateful is better / more secure

However, you are quite correct - you have the choice of using stateful 
connection tracking or not using it, as you prefer.

My choice is to have the security of having my ports closed by using stateful 
filtering.   I don't have a fast enough Internet connection for performance 
to be a problem, and I don't know many people who do.

Regards,

Antony.

-- 
Most people have more than the average number of legs.

                                                     Please reply to the list;
                                                           please don't CC me.

Re: Is this firewall good enough?

[Rob Sterenborg]

> > > 7.  /sbin/iptables -A INPUT -p tcp --dport 53
> > --syn
> > > -j ACCEPT #DNS
> >
> > DNS uses udp for normal lookups. Only in special
> > cases tcp is used.
> >
> I noted --syn can only be used with protocol tcp. How
> do I write a similar rule to accept connections to udp
> port 53?

Packets with syn set are (almost ? someone please correct me if I'm
wrong) always in NEW state.
So, a similar rule would be :

iptables -A INPUT -p udp --dport 53 -j ACCEPT

which implies :

iptables -A INPUT -m state --state NEW -p udp \
  --dport 53 -j ACCEPT

> I don't see a good explanation of tcp-flags either on
> iptables man pages or Packet Filtering HOWTO. What are
> meaning of SYN,ACK,FIN,RST,URG,PSH? What combinations
> can be logged/dropped?

A little info I found about tcp flags :
http://www.whitehats.ca/main/members/Seeker/seeker_tcp_header/seeker_tcp_header.html
http://www.spirit.com/Network/net0900.html
http://www.securityfocus.com/infocus/1524
I don't think it's all that you want to know about it but it's as much
as I could find right now.
Not sure what URG and PSH really do.

You could DROP :
- SYN,FIN SYN,FIN (Both SYN and FIN set in 1 packet.)
- SYN,RST SYN,RST (SYN and RST set, probably a scan)
- Anybody any additions, comments ?


Gr,
Rob

Re: Is this firewall good enough?

[Feizhou]

Jozsef Kadlecsik wrote:
> On Wed, 9 Jun 2004, Feizhou wrote:
> 
> 
>>>Is there any good reason not to load connection tracking?
>>
>>SLOW. It isn't good enough to use on a high traffic server.
> 
> 
> Could you back your claims up with data?

What kind of data?

I can tell you what I observed.

I have two dnscaches running dnscache. Single PIII 800 cpus with 512MB 
of RAM.

One box had the command iptables -t nat -L -n run and that caused 
ipt_conntrack to be loaded.

Instantly queries to that box took over 200ms to return (cached entries) 
and sometimes timeouts even occured while the other box happily kept 
return times to under 20ms for cached entries.

These are with a RH 2.4.20-20 with XFS patches applied.

> 
> At testing connection tracking we could pump trough two million concurrent
> connection at 200000pps rate with opening up 20000 new connection per
> second on a dual Xeon PC with Serverworks chipset and Intel copper GE
> cards. Best results were achieved by Linux kernel 2.6.x with conntrack
> locking and TCP window tracking patches applied and NAPI enabled.
> I'd say that's not bad at all.


Which tcp window tracking patches? On my mail gateways, I had 2.6.4 with 
e100 driver and NAPI enabled and that proved to be a disaster. I had to 
turn NAPI off and also muck around:

net.ipv4.tcp_max_syn_backlog = 2048
net.ipv4.route.gc_thresh = 65536

to keep the box accessible. Otherwise, the kernel would spew dst cache 
overflow/BUGTRAP errors or oops or even garbage.

Re: Is this firewall good enough?

[Feizhou]

Antony Stone wrote:
> On Tuesday 08 June 2004 9:11 pm, Feizhou wrote:
> 
> 
>>>That rule allows packets *to* port 80 - I was asking how you deal with
>>>*reply* packets - the ones *from* port 80 on the remote server.
>>
>>iptables -A tcp_packets -p --sport 80 --dport 1024:65535 -j ACCEPT

whoops, that should be:

iptables -A tcp_packets -p --sport 80 --dport 1024:65535 ! --syn -j ACCEPT

:P
> 
> 
> That is not my idea of a secure firewall rule - you are allowing an external 
> scanner  / attacker to access the machine on any TCP port from 1024 to 65535, 
> simply by setting their source port to 80.
> 
> Sheesh - we might as well go back to stateless routers with access control 
> lists.

My problems could be related to hardware not being powerful enough. It 
does show though that there is a cost to stateful modules we have.

Re: Is this firewall good enough?

[Jozsef Kadlecsik]

On Wed, 9 Jun 2004, Feizhou wrote:

> >>>Is there any good reason not to load connection tracking?
> >>
> >>SLOW. It isn't good enough to use on a high traffic server.
> >
> > Could you back your claims up with data?
>
> What kind of data?
>
> I can tell you what I observed.
>
> I have two dnscaches running dnscache. Single PIII 800 cpus with 512MB
> of RAM.
>
> One box had the command iptables -t nat -L -n run and that caused
> ipt_conntrack to be loaded.
>
> Instantly queries to that box took over 200ms to return (cached entries)
> and sometimes timeouts even occured while the other box happily kept
> return times to under 20ms for cached entries.
>
> These are with a RH 2.4.20-20 with XFS patches applied.

That *is* data. Make sure there is enough ram in the machines
for doing both connection tracking and DNS cacheing: conntrack uses
non-swappable memory.

But I think your case is a special one, where you stress-test connection
tracking without any benefit. DNS queries are just queries. Request and
response typically fit into one (UDP) packet, so at the first packet
conntrack fires up, allocates memory, makes all its book-keeping
duties, etc, and at the second (response) packet it kicks the connection
into assured/replied state. Then the entry times out - there'll be no
other packets belonging to the DNS query.

If there is enough memory, then you have two choices:

- Not to use connection tracking at all. conntrack is not (and I think
  cannot be) optimized for this case.
- Use raw table and NOTRACK to skip conntrack for the (UDP) DNS queries
  and still benefit from conntrack for all other connections.

> > At testing connection tracking we could pump trough two million concurrent
> > connection at 200000pps rate with opening up 20000 new connection per
> > second on a dual Xeon PC with Serverworks chipset and Intel copper GE
> > cards. Best results were achieved by Linux kernel 2.6.x with conntrack
> > locking and TCP window tracking patches applied and NAPI enabled.
> > I'd say that's not bad at all.
>
> Which tcp window tracking patches?

That is the TCP window tracking patch from pom-ng (which play no role at
all for your UDP DNS queries), but the locking patch improves the
performance of conntrack.

> On my mail gateways, I had 2.6.4 with e100 driver and NAPI enabled and
> that proved to be a disaster. I had to turn NAPI off and also muck
> around:
>
> net.ipv4.tcp_max_syn_backlog = 2048
> net.ipv4.route.gc_thresh = 65536
>
> to keep the box accessible. Otherwise, the kernel would spew dst cache
> overflow/BUGTRAP errors or oops or even garbage.

For high performance servers one does have to tune the kernel. We used the
e1000 driver with NAPI and there were no problems at all.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: Is this firewall good enough?

[Feizhou]

Jozsef Kadlecsik wrote:
> On Wed, 9 Jun 2004, Feizhou wrote:
> 
> 
>>>>>Is there any good reason not to load connection tracking?
>>>>
>>>>SLOW. It isn't good enough to use on a high traffic server.
>>>
>>>Could you back your claims up with data?
>>
>>What kind of data?
>>
>>I can tell you what I observed.
>>
>>I have two dnscaches running dnscache. Single PIII 800 cpus with 512MB
>>of RAM.
>>
>>One box had the command iptables -t nat -L -n run and that caused
>>ipt_conntrack to be loaded.
>>
>>Instantly queries to that box took over 200ms to return (cached entries)
>>and sometimes timeouts even occured while the other box happily kept
>>return times to under 20ms for cached entries.
>>
>>These are with a RH 2.4.20-20 with XFS patches applied.
> 
> 
> That *is* data. Make sure there is enough ram in the machines
> for doing both connection tracking and DNS cacheing: conntrack uses
> non-swappable memory.

Ah, that explains why the dnscache on the box what had conntrack loaded 
could not use as much memory as the other box. Time to increase the size 
of the cache >=)
> 
> But I think your case is a special one, where you stress-test connection
> tracking without any benefit. DNS queries are just queries. Request and
> response typically fit into one (UDP) packet, so at the first packet
> conntrack fires up, allocates memory, makes all its book-keeping
> duties, etc, and at the second (response) packet it kicks the connection
> into assured/replied state. Then the entry times out - there'll be no
> other packets belonging to the DNS query.
> 
> If there is enough memory, then you have two choices:
> 
> - Not to use connection tracking at all. conntrack is not (and I think
>   cannot be) optimized for this case.

For a dnscache only box? Definitely not.
> - Use raw table and NOTRACK to skip conntrack for the (UDP) DNS queries
>   and still benefit from conntrack for all other connections.

Sorry, but what do you mean by raw table and is NOTRACK a pom patch/module?
> 
> 
>>>At testing connection tracking we could pump trough two million concurrent
>>>connection at 200000pps rate with opening up 20000 new connection per
>>>second on a dual Xeon PC with Serverworks chipset and Intel copper GE
>>>cards. Best results were achieved by Linux kernel 2.6.x with conntrack
>>>locking and TCP window tracking patches applied and NAPI enabled.
>>>I'd say that's not bad at all.
>>
>>Which tcp window tracking patches?
> 
> 
> That is the TCP window tracking patch from pom-ng (which play no role at
> all for your UDP DNS queries), but the locking patch improves the
> performance of conntrack.

Hmm, I tried the connlimit patch (which uses conntrack to do its stuff) 
on a mail gateway but found it wanting then. Will this help there?
> 
> 
>>On my mail gateways, I had 2.6.4 with e100 driver and NAPI enabled and
>>that proved to be a disaster. I had to turn NAPI off and also muck
>>around:
>>
>>net.ipv4.tcp_max_syn_backlog = 2048
>>net.ipv4.route.gc_thresh = 65536
>>
>>to keep the box accessible. Otherwise, the kernel would spew dst cache
>>overflow/BUGTRAP errors or oops or even garbage.
> 
> 
> For high performance servers one does have to tune the kernel. We used the
> e1000 driver with NAPI and there were no problems at all.

Do you get a very high packet rate? Apparently, the problem only shows 
up in boxes having to deal with very high packet rates and I had it 
without NAPI enabled. NAPI just make it worse/happen more quickly. I can 
but guess that you might be using larger payloads other than 1500 with 
your Gigabit link.

Re: Is this firewall good enough?

[Feizhou]

> - Use raw table and NOTRACK to skip conntrack for the (UDP) DNS queries
>   and still benefit from conntrack for all other connections.
> 

pom raw patch. Testing....ouch, bit on the edge for me to try to use that...

I'd love to be able to track nothing but smtp and optimize on that too 
so that I can give connlimit a go.

Re: Is this firewall good enough?

[Chris Brenton]

On Wed, 2004-06-09 at 03:32, Sagara Wijetunga wrote:
>
> Here I have almost no choice, just have budget for one
> server :(

That's what I figured. Thus the info I included at the end of my post. 

> 
> > 17. /sbin/iptables -P OUTPUT ACCEPT
> >  
> Could you elaborate this a bit? What are the possible
> outbound transports and what are the possible
> solutions? 

This rule permits any outbound session establishment. This means if an
attacker can exploit one of your exposed services they can use anything
they want (HTTP, FTP, TFTP, etc. etc.) as an outbound session to
transfer a toolkit/rootkit. 

A better solution may be to only permit the types of outbound access
that you actually need to support (outbound DNS, SMTP, etc.).

> Our intension to host the server in a data center. Our
> server is not required to act as a client other than
> receiving mail from other STMP servers. We do not even
> offer recursive DNS. Is the SMTP, the client service
> that you refer?

By "client services" I was referring to the rule above that permits all
outbound traffic. Sorry I was not clear. Typically with a server you
only permit the types of outbound access that you know you will need to
support. I was assuming that the box was going to act as someone's
desktop because of the "permit anything outbound" rule.

> Could you kindly elaborate payload based attacks? Is
> it the packet rate per second? And what are the
> possible solutions for payload based attacks?

iptables controls traffic at the header level (IP address, port numbers,
transport, etc.). So while you can use iptables to ensure that only
TCP/80 traffic reaches your Web server, this does not protect you
against someone launching an HTTP based attack through port TCP/80. Sure
you can use "--string" to match on payload, but unless you define every
possible attack pattern and ensure that people never fragment their data
stream its not going to be effective.

To protect against payload based attacks you need to use a proxy. Squid
is an excellent example of software you can run to help protect a Web
server from payload based attacks (especially if run Jean on top of
Squid).

Of course the problem is you only have one box to work with so trying to
proxy every service is not going to happen. This is one of the risks you
are going to have to live with because of the design. :(

> > Some other things you could do to mitigate this
> > risk:
> > Setup an automatic patching system
> > Setup Tripwire or Aide to check system integrity
> > Setup another system to collect the logs off of this
> > system 
> > 	Setup Swatch or a similar tool to check these logs
> > Setup an IDS
> > 
> Could you point me to learn more into above setup
> subjects?

Some additional reading you might find helpful:
http://www.novell.com/products/desktop/update.html
http://sourceforge.net/projects/aide
http://www.loganalysis.org/
http://www.snort.org/

HTH,
Chris

Re: Is this firewall good enough?

[Aleksandar Milivojevic]

Sagara Wijetunga wrote:
> I noted --syn can only be used with protocol tcp. How
> do I write a similar rule to accept connections to udp
> port 53?

UDP is stateless protocol.  So you have to choices.

Not using connection tracking:

    -A INPUT -p udp --dport 53 -j ACCEPT
    -A OUTPUT -p udp --sport 53 -j ACCEPT

Using connection tracking:

    -A INPUT -p udp --dport 53 -m state --state NEW -j ACCEPT

Both would allow for inbound DNS.  You'll probably want to allow
outbound also.

Somehow I don't think you'll have that much traffic that you will need
to worry about overhead of connection tracking (not even for DNS, as
discussed earlier in this thread).  So I would recommend using it in
your case.  For example, at home I'm using old 200MHz Pentium MMX as
firewall, and it is perfectly capable to handle two interfaces (~3Mbps
(effectivly) cable, and 100Mbps LAN) with connection tracking.

The connection tracking line mentioned above assumes you have a line to
handle outbound packets (responses) equivalent to:

    -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

While we are at it, I would replace the line you have:

    -P OUTPUT ACCEPT

With:

    -P OUTPUT DROP
    -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

(you might want to put this lines at top)

This would limit outbound packets to responses to already established
connections.  This addresses the issue some people pointed out to you
already (that you configured the box as both client and server).  If you
want something to originate from your server, add it explicitly.  You
would probably need to allow DNS server to make outbound connections.
Another example would be to allow you to ping from your server:

    -A OUTPUT -p icmp --icmp-type ping --state NEW -j ACCEPT

For FTP, you need only to allow NEW connections to port 21.  Data
connections will be RELATED, so you don't need separate line for them.
This is if you are using connection tracking.  For this to work, you'll
probably need to load ip_conntrack_ftp module manualy ("modprobe
ip_contrack_ftp" should do it).

So in short, I would organize things somethine like this:

    # Have this at top
    -P INPUT DROP
    -P OUTPUT DROP
    -P FORWARD DROP
    # Unomment FORWARD line and add rules to FORWARD chain if
    # this box is router.  99% of packets will match these three
    # rules, so it makes sense to have them first.
    -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
    -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
    # -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
    # Put inbound things you need here, these depend on OUTPUT line
    # from first section.  For example:
    -A INPUT -p tcp --dport 21 -m state --state NEW -j ACCEPT
    -A INPUT -p udp --dport 53 -m state --state NEW -j ACCEPT
    -A INPUT -p tcp --dport 53 -m state --state NEW -j ACCEPT
    -A INPUT -p tcp --dport 110 -m state --state NEW -j ACCEPT
       ...  add other services you have ...
    # Put outbound things you need here, these depend on INPUT line
    # from first section:
    -A OUTPUT -p udp --dport 53 -m state --state NEW -j ACCEPT
    -A OUTPUT -p tcp --dport 53 -m state --state NEW -j ACCEPT
    -A OUTPUT -p icmp --icmp-type ping --state NEW -j ACCEPT
       ...  add more as needed ...

If some of the services should be accessble only from LAN, than make
more restrictive rule.  For example, replacing POP3 line with:

    -A INPUT -p tcp -s 192.168.0.0/16 --dport 110 -m state --state NEW
-j ACCEPT

If your box has two separate interfaces (LAN and WAN), you can use even
more specific rule (assuming eth1 is LAN interface):

    -A INPUT -i eth1 -p tcp -s 192.168.0.0/16 --dport 110 -m state
--state NEW -j ACCEPT

These rules could be refined in many ways to make things more strict
(and secure).  But with so many services running on a single box, it is
questinable if you would gain anything.

> I don't see a good explanation of tcp-flags either on
> iptables man pages or Packet Filtering HOWTO. What are
> meaning of SYN,ACK,FIN,RST,URG,PSH? What combinations
> can be logged/dropped?

TCP flags are explained in many fine books.  I guess searching a web
(for example using Google) would result in many pages with good
explanations of those.  No point in explaining them again and again in
every single piece of networking software ;-)

-- 
Aleksandar Milivojevic <amilivojevic@pbl.ca>    Pollard Banknote Limited
Systems Administrator                           1499 Buffalo Place
Tel: (204) 474-2323 ext 276                     Winnipeg, MB  R3T 1L7

Re: Is this firewall good enough?

[Aleksandar Milivojevic]

Aleksandar Milivojevic wrote:
>    -A OUTPUT -p icmp --icmp-type ping --state NEW -j ACCEPT

Hm, typo (in two places), should read:

    -A OUTPUT -p icmp --icmp-type ping -m state --state NEW -j ACCEPT

-- 
Aleksandar Milivojevic <amilivojevic@pbl.ca>    Pollard Banknote Limited
Systems Administrator                           1499 Buffalo Place
Tel: (204) 474-2323 ext 276                     Winnipeg, MB  R3T 1L7

Re: Is this firewall good enough?

[Sagara Wijetunga]

Hi all

Thanks for all those who contributed to my post. Today
I managed to test and complete the firewall. 

Sagara


	
		
__________________________________
Do you Yahoo!?
Friends.  Fun.  Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/