Is this config OK, plus were should I be logging...

Is this config OK, plus were should I be logging...

[Stuart Lamble]

:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
-A INPUT -i lo -j ACCEPT 
-A INPUT -i eth1 -j ACCEPT 
-A INPUT -p icmp -j ACCEPT 
-A INPUT -p tcp -m tcp --sport 25 -j ACCEPT 
-A INPUT -i ppp0 -p tcp -m tcp --dport 22 -j ACCEPT 
-A INPUT -i ppp0 -p tcp -m tcp --dport 25 -j ACCEPT 
-A INPUT -i ppp0 -p tcp -m tcp --dport 80 -j ACCEPT 
-A INPUT -i ppp0 -p tcp -m tcp --dport 443 -j ACCEPT 
-A INPUT -i ppp0 -p tcp -m tcp --dport 10000 -j ACCEPT 
-A INPUT -i ppp0 -p udp -m udp --sport 53 -j ACCEPT 
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT 
-A FORWARD -s 192.168.100.0/255.255.255.0 -j ACCEPT 
-A FORWARD -d 192.168.100.6 -p tcp -m tcp --dport 22 -j ACCEPT 
-A FORWARD -d 192.168.100.6 -p tcp -m tcp --dport 7783 -j ACCEPT 
-A OUTPUT -s 127.0.0.1 -j ACCEPT 
-A OUTPUT -o eth1 -j ACCEPT 
-A OUTPUT -p tcp -m tcp --sport 80 -j ACCEPT 
-A OUTPUT -p tcp -m tcp --sport 25 -j ACCEPT 
-A OUTPUT -p tcp -m tcp --sport 22 -j ACCEPT 

:PREROUTING ACCEPT [10:1191]
:POSTROUTING ACCEPT [1:48]
:OUTPUT ACCEPT [0:0]
-A PREROUTING -i ppp0 -p tcp -m tcp --dport 555 -j DNAT --to-destination
192.168.100.6:22 
-A PREROUTING -i ppp0 -p tcp -m tcp --dport 7783 -j DNAT
--to-destination 192.168.100.6:7783 
-A POSTROUTING -s 192.168.100.0/255.255.255.240 -o ppp0 -j MASQUERADE 

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.648 / Virus Database: 415 - Release Date: 3/31/2004
 

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.648 / Virus Database: 415 - Release Date: 3/31/2004
 

Re: Is this config OK, plus where should I be logging...

[Antony Stone]

On Sunday 04 April 2004 6:26 pm, Stuart Lamble wrote:

> Is this config OK, plus where should I be logging...

We need a bit more information in order to answer either of those questions.

Two things we need to know which you haven't said are:

1. What services are supposed to be allowed from/to where, so we can comment 
on whether this ruleset does what you want it to?

2. What would you like to have logged, so we can advise where to do the 
logging?

Also a few more questions added at points through your ruleset:

> :INPUT DROP [0:0]
> :FORWARD DROP [0:0]
> :OUTPUT DROP [0:0]
>
> -A INPUT -i lo -j ACCEPT
> -A INPUT -i eth1 -j ACCEPT

What is interface eth1 used for?   (We don't know if it's reasonable to accept 
all packets from there into the firewall - we can assume, but that wouldn't 
be an answer to your question.   Do you have only a single trusted machine 
there?   Do you have lots of machines with possibly trusted, possibly 
untrusted users?   Is it connected to the Internet?   We need more info....)

> -A INPUT -p icmp -j ACCEPT
> -A INPUT -p tcp -m tcp --sport 25 -j ACCEPT

Your firewall machine in running a mail client !?

> -A INPUT -i ppp0 -p tcp -m tcp --dport 22 -j ACCEPT
> -A INPUT -i ppp0 -p tcp -m tcp --dport 25 -j ACCEPT

Your firewall machine is running a mail server !!!???

> -A INPUT -i ppp0 -p tcp -m tcp --dport 80 -j ACCEPT
> -A INPUT -i ppp0 -p tcp -m tcp --dport 443 -j ACCEPT
> -A INPUT -i ppp0 -p tcp -m tcp --dport 10000 -j ACCEPT

What's that supposed to be for?

> -A INPUT -i ppp0 -p udp -m udp --sport 53 -j ACCEPT
> -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
> -A FORWARD -s 192.168.100.0/255.255.255.0 -j ACCEPT

That's a nice way to allow spoofed packets through your firewall....

> -A FORWARD -d 192.168.100.6 -p tcp -m tcp --dport 22 -j ACCEPT
> -A FORWARD -d 192.168.100.6 -p tcp -m tcp --dport 7783 -j ACCEPT

What's that for?

> -A OUTPUT -s 127.0.0.1 -j ACCEPT
> -A OUTPUT -o eth1 -j ACCEPT
> -A OUTPUT -p tcp -m tcp --sport 80 -j ACCEPT

You allowed in packets addressed to ports 80 and 443 - how come you only allow 
out reply packets from 80?

> -A OUTPUT -p tcp -m tcp --sport 25 -j ACCEPT
> -A OUTPUT -p tcp -m tcp --sport 22 -j ACCEPT

You allowed in packets to port 10000 - you don't allow the replies out again?

> :PREROUTING ACCEPT [10:1191]
> :POSTROUTING ACCEPT [1:48]
> :OUTPUT ACCEPT [0:0]

So, you set up a nice default DROP policy, added some ACCEPT rules allowing 
the traffic you want, and then change the policy to ACCEPT so that everything 
is allowed (and you don't have any DROP rules).   You may as well not bother 
with the OUTPUT ACCEPT rules - it's all going to get ACCEPTed anyway.

> -A PREROUTING -i ppp0 -p tcp -m tcp --dport 555 -j DNAT --to-destination
> 192.168.100.6:22
> -A PREROUTING -i ppp0 -p tcp -m tcp --dport 7783 -j DNAT
> --to-destination 192.168.100.6:7783
> -A POSTROUTING -s 192.168.100.0/255.255.255.240 -o ppp0 -j MASQUERADE

You seem confused about your network size.   Here you've used a 20 bit netmask 
- earlier you used a 24 bit (on the FORWARDing rule).   Probably best to be 
consistent (what subnet mask are you using on the eth1 interface, and on the 
client machines?)

Also, by the way, what happened to interface eth0?

Regards,

Antony.

-- 
90% of networking problems are routing problems.
9 of the remaining 10% are routing problems in the other direction.
The remaining 1% might be something else, but check the routing anyway.

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

RE: Is this config OK, plus where should I be logging...

[Stuart Lamble]

Hi

Ok, here is an update...
I have added the results of iptables-save as is, without hacking
anything off. ;-)
I have the firewall box that is running the following...
mail server on port 25
ssh server on port 22
webmin running port 10000 over SSL 443
web server on port 80
DNAT to another lan server running oracle web services on port 7783 =
7783 (from the web)
DNAT to another lan server running ssh services on port 22 = 555 (from
the web)

My internal 192.168.100.0/255.255.255.0 is masqueraded for internet
browsing and prity much everything else.
The firewall itself needs to do DNS lookups, browse the net and send
SMTP traffic.

All that I require, stated above is working.
I want to know if the config is secure, where are the holes, what are
the best practices.
Also, I want to log suspicious behaviour, port scans, what gets dropped
etc.
I am stuck with that ;-(

This config is very much in TEST phase, I am on a quest to hone it,
hoping to make it as robust as possible.

Thanks in advance for any advice...


# Generated by iptables-save v1.2.7a on Sun Apr  4 22:25:58 2004
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
-A INPUT -i lo -j ACCEPT 
-A INPUT -i eth1 -j ACCEPT 
-A INPUT -p icmp -j ACCEPT 
-A INPUT -p tcp -m tcp --sport 25 -j ACCEPT 
-A INPUT -i ppp0 -p tcp -m tcp --dport 22 -j ACCEPT 
-A INPUT -i ppp0 -p tcp -m tcp --dport 25 -j ACCEPT 
-A INPUT -i ppp0 -p tcp -m tcp --dport 80 -j ACCEPT 
-A INPUT -i ppp0 -p tcp -m tcp --dport 443 -j ACCEPT 
-A INPUT -i ppp0 -p tcp -m tcp --dport 10000 -j ACCEPT 
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT 
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT 
-A FORWARD -s 192.168.100.0/255.255.255.0 -j ACCEPT 
-A FORWARD -d 192.168.100.6 -p tcp -m tcp --dport 22 -j ACCEPT 
-A FORWARD -d 192.168.100.6 -p tcp -m tcp --dport 7783 -j ACCEPT 
-A OUTPUT -s 127.0.0.1 -j ACCEPT 
-A OUTPUT -o eth1 -j ACCEPT 
-A OUTPUT -p tcp -m tcp --sport 80 -j ACCEPT 
-A OUTPUT -p tcp -m tcp --sport 25 -j ACCEPT 
-A OUTPUT -p tcp -m tcp --sport 22 -j ACCEPT 
-A OUTPUT -o ppp0 -p udp -m udp -m multiport --ports domain -j ACCEPT 
-A OUTPUT -o ppp0 -p tcp -m tcp -m multiport --ports http -j ACCEPT 
-A OUTPUT -o ppp0 -p tcp -m tcp -m multiport --ports smtp -j ACCEPT 
-A OUTPUT -o ppp0 -p tcp -m tcp -m multiport --ports ndmp -j ACCEPT 
COMMIT
# Completed on Sun Apr  4 22:25:58 2004
# Generated by iptables-save v1.2.7a on Sun Apr  4 22:25:58 2004
*mangle
:PREROUTING ACCEPT [1006:286916]
:INPUT ACCEPT [169:78179]
:FORWARD ACCEPT [834:208581]
:OUTPUT ACCEPT [171:64908]
:POSTROUTING ACCEPT [1005:273489]
COMMIT
# Completed on Sun Apr  4 22:25:58 2004
# Generated by iptables-save v1.2.7a on Sun Apr  4 22:25:58 2004
*nat
:PREROUTING ACCEPT [7:348]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A PREROUTING -i ppp0 -p tcp -m tcp --dport 555 -j DNAT --to-destination
192.168.100.6:22 
-A PREROUTING -i ppp0 -p tcp -m tcp --dport 7783 -j DNAT
--to-destination 192.168.100.6:7783 
-A POSTROUTING -s 192.168.100.0/255.255.255.0 -o ppp0 -j MASQUERADE 
COMMIT
# Completed on Sun Apr  4 22:25:58 2004




















-----Original Message-----
From: netfilter-admin@lists.netfilter.org
[mailto:netfilter-admin@lists.netfilter.org] On Behalf Of Antony Stone
Sent: Sunday, April 04, 2004 7:56 PM
To: netfilter@lists.netfilter.org
Subject: Re: Is this config OK, plus where should I be logging...


On Sunday 04 April 2004 6:26 pm, Stuart Lamble wrote:

> Is this config OK, plus where should I be logging...

We need a bit more information in order to answer either of those
questions.

Two things we need to know which you haven't said are:

1. What services are supposed to be allowed from/to where, so we can
comment 
on whether this ruleset does what you want it to?

2. What would you like to have logged, so we can advise where to do the 
logging?

Also a few more questions added at points through your ruleset:

> :INPUT DROP [0:0]
> :FORWARD DROP [0:0]
> :OUTPUT DROP [0:0]
>
> -A INPUT -i lo -j ACCEPT
> -A INPUT -i eth1 -j ACCEPT

What is interface eth1 used for?   (We don't know if it's reasonable to
accept 
all packets from there into the firewall - we can assume, but that
wouldn't 
be an answer to your question.   Do you have only a single trusted
machine 
there?   Do you have lots of machines with possibly trusted, possibly 
untrusted users?   Is it connected to the Internet?   We need more
info....)

> -A INPUT -p icmp -j ACCEPT
> -A INPUT -p tcp -m tcp --sport 25 -j ACCEPT

Your firewall machine in running a mail client !?

> -A INPUT -i ppp0 -p tcp -m tcp --dport 22 -j ACCEPT
> -A INPUT -i ppp0 -p tcp -m tcp --dport 25 -j ACCEPT

Your firewall machine is running a mail server !!!???

> -A INPUT -i ppp0 -p tcp -m tcp --dport 80 -j ACCEPT
> -A INPUT -i ppp0 -p tcp -m tcp --dport 443 -j ACCEPT
> -A INPUT -i ppp0 -p tcp -m tcp --dport 10000 -j ACCEPT

What's that supposed to be for?

> -A INPUT -i ppp0 -p udp -m udp --sport 53 -j ACCEPT
> -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
> -A FORWARD -s 192.168.100.0/255.255.255.0 -j ACCEPT

That's a nice way to allow spoofed packets through your firewall....

> -A FORWARD -d 192.168.100.6 -p tcp -m tcp --dport 22 -j ACCEPT -A 
> FORWARD -d 192.168.100.6 -p tcp -m tcp --dport 7783 -j ACCEPT

What's that for?

> -A OUTPUT -s 127.0.0.1 -j ACCEPT
> -A OUTPUT -o eth1 -j ACCEPT
> -A OUTPUT -p tcp -m tcp --sport 80 -j ACCEPT

You allowed in packets addressed to ports 80 and 443 - how come you only
allow 
out reply packets from 80?

> -A OUTPUT -p tcp -m tcp --sport 25 -j ACCEPT
> -A OUTPUT -p tcp -m tcp --sport 22 -j ACCEPT

You allowed in packets to port 10000 - you don't allow the replies out
again?

> :PREROUTING ACCEPT [10:1191]
> :POSTROUTING ACCEPT [1:48]
> :OUTPUT ACCEPT [0:0]

So, you set up a nice default DROP policy, added some ACCEPT rules
allowing 
the traffic you want, and then change the policy to ACCEPT so that
everything 
is allowed (and you don't have any DROP rules).   You may as well not
bother 
with the OUTPUT ACCEPT rules - it's all going to get ACCEPTed anyway.

> -A PREROUTING -i ppp0 -p tcp -m tcp --dport 555 -j DNAT 
> --to-destination 192.168.100.6:22 -A PREROUTING -i ppp0 -p tcp -m tcp 
> --dport 7783 -j DNAT --to-destination 192.168.100.6:7783
> -A POSTROUTING -s 192.168.100.0/255.255.255.240 -o ppp0 -j MASQUERADE

You seem confused about your network size.   Here you've used a 20 bit
netmask 
- earlier you used a 24 bit (on the FORWARDing rule).   Probably best to
be 
consistent (what subnet mask are you using on the eth1 interface, and on
the 
client machines?)

Also, by the way, what happened to interface eth0?

Regards,

Antony.

-- 
90% of networking problems are routing problems.
9 of the remaining 10% are routing problems in the other direction. The
remaining 1% might be something else, but check the routing anyway.

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



---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.648 / Virus Database: 415 - Release Date: 3/31/2004
 

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.648 / Virus Database: 415 - Release Date: 3/31/2004
 

Re: Is this config OK, plus where should I be logging...

[Antony Stone]

On Sunday 04 April 2004 7:41 pm, Stuart Lamble wrote:

> Hi
>
> Ok, here is an update...
> I have added the results of iptables-save as is, without hacking
> anything off. ;-)
> I have the firewall box that is running the following...
> mail server on port 25
> ssh server on port 22
> webmin running port 10000 over SSL 443
> web server on port 80

So, this thing is not a firewall, it's a general purpose server which happens 
to run some netfilter rules :)

(Yes, I disapprove of firewalls running network services... :)

By the way, what do you mean by "webmin running port 10000 over SSL 443"?

Is this thing listening on port 10000, or port 443?   Set up one rule to allow 
whichever type of packets you need, and remove the other rule.

> DNAT to another lan server running oracle web services on port 7783 =
> 7783 (from the web)
> DNAT to another lan server running ssh services on port 22 = 555 (from
> the web)
>
> My internal 192.168.100.0/255.255.255.0 is masqueraded for internet
> browsing and prity much everything else.
> The firewall itself needs to do DNS lookups, browse the net and send
> SMTP traffic.
>
> All that I require, stated above is working.

Okay, good.

> I want to know if the config is secure, where are the holes, what are
> the best practices.

Best practice item 1: don't run network services on your firewall :)

As I said in my earlier reply, I can't see why you have bothered to put OUTPUT 
ACCEPT rules in place, when you then put a default ACCEPT policy on the 
OUTPUT chain (and you have no DROP rules).   Absolutely everything is allowed 
out of this box, so why not make it obvious that that is the case, instead of 
making someone (perhaps you, in six months' time) think that the ACCEPT rules 
are there for a purpose and anything not specified will not be allowed?

Also, whilst we're talking about those rules, why have you used multiport, and 
then specified only a single port in each rule?

The simpler your rules are, the easier they are to understand.

The more compilcated you make them, the easier it is to make mistakes.

> Also, I want to log suspicious behaviour, port scans, what gets dropped
> etc.
> I am stuck with that ;-(

Put your LOGging rules at the end of FORWARD and INPUT, just before the 
default DROP policy takes effect.   At first you may as well just log 
everything with a simple rule "iptables -A INPUT -j LOG", and then once you 
get bored of seeing loads of packets addressed to port 135 on your firewall, 
you can DROP those before the LOG rule and start to narrow down what you log 
to only the stuff you find interesting.

> # Generated by iptables-save v1.2.7a on Sun Apr  4 22:25:58 2004
> *filter
>
> :INPUT DROP [0:0]
> :FORWARD DROP [0:0]
> :OUTPUT DROP [0:0]
>
> -A INPUT -i lo -j ACCEPT
> -A INPUT -i eth1 -j ACCEPT
> -A INPUT -p icmp -j ACCEPT
> -A INPUT -p tcp -m tcp --sport 25 -j ACCEPT
> -A INPUT -i ppp0 -p tcp -m tcp --dport 22 -j ACCEPT
> -A INPUT -i ppp0 -p tcp -m tcp --dport 25 -j ACCEPT
> -A INPUT -i ppp0 -p tcp -m tcp --dport 80 -j ACCEPT
> -A INPUT -i ppp0 -p tcp -m tcp --dport 443 -j ACCEPT
> -A INPUT -i ppp0 -p tcp -m tcp --dport 10000 -j ACCEPT
> -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
> -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
> -A FORWARD -s 192.168.100.0/255.255.255.0 -j ACCEPT

I still disapprove of the above rule.   It will allow packets from the 
Internet which have a source address matching your internal network to get 
through the firewall.   You should tighten it by adding the source interface 
eth1 as well:

iptables -A FORWARD -s 192.168.100.0/24 -i eth1 -j ACCEPT

> -A FORWARD -d 192.168.100.6 -p tcp -m tcp --dport 22 -j ACCEPT
> -A FORWARD -d 192.168.100.6 -p tcp -m tcp --dport 7783 -j ACCEPT
> -A OUTPUT -s 127.0.0.1 -j ACCEPT
> -A OUTPUT -o eth1 -j ACCEPT
> -A OUTPUT -p tcp -m tcp --sport 80 -j ACCEPT

You still have INPUT rules for ports 80 and 443, but a OUTPUT rule only for 
port 80 (as well as a default ACCEPT policy which will allow the 443 packets 
as well as any others).   This inconsistency doesn't look good.

> -A OUTPUT -p tcp -m tcp --sport 25 -j ACCEPT
> -A OUTPUT -p tcp -m tcp --sport 22 -j ACCEPT
> -A OUTPUT -o ppp0 -p udp -m udp -m multiport --ports domain -j ACCEPT
> -A OUTPUT -o ppp0 -p tcp -m tcp -m multiport --ports http -j ACCEPT
> -A OUTPUT -o ppp0 -p tcp -m tcp -m multiport --ports smtp -j ACCEPT
> -A OUTPUT -o ppp0 -p tcp -m tcp -m multiport --ports ndmp -j ACCEPT
> COMMIT
> # Completed on Sun Apr  4 22:25:58 2004

Personally I would prefer to see:

iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT ......... -j ACCEPT
  .... for each type of traffic you want to allow in to the "firewall"
iptables -A OUTPUT ........ -j ACCEPT
  .... for each type of traffic you want to allow out
iptables -A FORWARD ........ -j ACCEPT
  .... for each type of traffic you want to allow through.

By using the ESTABLISHED,RELATED rules more effectively, you can focus only on 
the destination ports in all three chains, and not need to have matching 
rules in INPUT and OUTPUT, with source ports in one and destination ports in 
the other, as you have done.

Hope this helps,

Regards,

Antony.

-- 
One good tern deserves another.

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

RE: Is this config OK, plus where should I be logging...

[Stuart Lamble]

Thanks for your reply, it has me thinking here.

I agree, running local services on a firewall is asking for it,
especially with SMTP.
I think what I need to do is add a third network card to the firewall
and create a DMZ, probably safer than dnat-ing to these services on the
LAN, such as SMTP server on the LAN.
That will add some extra rules to the firewall, but at least now it will
be a pure netfilter machine ;-)
I will probably just open UDP 53,TCP 80 and FTP for the purposes of
connecting to the net and running updates from the firewall itself.
I may also want ssh, so I can admin from the internet, but then I could
always ssh to the DMZ and then ssh from there to the firewall, probably
safer.

Just a few questions on your reply below?
On the "-t nat" table , PREROUTING, OUTPUT and POSTROUTING is -P ACCEPT.
Good or bad, should I drop here and add the rules as I need them?

Also, I currently have an eth0 which is the Un-trusted interface
connecting to my DSL modem.
I have eth1 which is my trusted LAN and ppp0, which is the virtual
interface that comes up when the DSL line is up, pritty much 24/7.
However, I base my rules on ppp0 as the un-trusted interface and not
eth0, in fact in a previous email, you asked where is eth0? What should
I do here?

What is the very first table that a packet will "touch" as it comes into
the firewall? PREROUTING or INPUT?
I believe it will be PREROUTING, as a packet may be destined for another
machine on the network, dnat...
So, should this table be not be the most "looked after" as so to speak,
followed by the FORWARD table?
Especially if we have a DMZ, where we are PREROUTING most services to
that interface, and almost nothing will be for INPUT as no services will
be running on the firewall itself, except for ssh????

Thanks
For your time, it is truly appreciated.



-----Original Message-----
From: netfilter-admin@lists.netfilter.org
[mailto:netfilter-admin@lists.netfilter.org] On Behalf Of Antony Stone
Sent: Sunday, April 04, 2004 9:07 PM
To: netfilter@lists.netfilter.org
Subject: Re: Is this config OK, plus where should I be logging...


On Sunday 04 April 2004 7:41 pm, Stuart Lamble wrote:

> Hi
>
> Ok, here is an update...
> I have added the results of iptables-save as is, without hacking 
> anything off. ;-) I have the firewall box that is running the 
> following... mail server on port 25
> ssh server on port 22
> webmin running port 10000 over SSL 443
> web server on port 80

So, this thing is not a firewall, it's a general purpose server which
happens 
to run some netfilter rules :)

(Yes, I disapprove of firewalls running network services... :)

By the way, what do you mean by "webmin running port 10000 over SSL
443"?

Is this thing listening on port 10000, or port 443?   Set up one rule to
allow 
whichever type of packets you need, and remove the other rule.

> DNAT to another lan server running oracle web services on port 7783 = 
> 7783 (from the web) DNAT to another lan server running ssh services on

> port 22 = 555 (from the web)
>
> My internal 192.168.100.0/255.255.255.0 is masqueraded for internet 
> browsing and prity much everything else. The firewall itself needs to 
> do DNS lookups, browse the net and send SMTP traffic.
>
> All that I require, stated above is working.

Okay, good.

> I want to know if the config is secure, where are the holes, what are 
> the best practices.

Best practice item 1: don't run network services on your firewall :)

As I said in my earlier reply, I can't see why you have bothered to put
OUTPUT 
ACCEPT rules in place, when you then put a default ACCEPT policy on the 
OUTPUT chain (and you have no DROP rules).   Absolutely everything is
allowed 
out of this box, so why not make it obvious that that is the case,
instead of 
making someone (perhaps you, in six months' time) think that the ACCEPT
rules 
are there for a purpose and anything not specified will not be allowed?

Also, whilst we're talking about those rules, why have you used
multiport, and 
then specified only a single port in each rule?

The simpler your rules are, the easier they are to understand.

The more compilcated you make them, the easier it is to make mistakes.

> Also, I want to log suspicious behaviour, port scans, what gets 
> dropped etc. I am stuck with that ;-(

Put your LOGging rules at the end of FORWARD and INPUT, just before the 
default DROP policy takes effect.   At first you may as well just log 
everything with a simple rule "iptables -A INPUT -j LOG", and then once
you 
get bored of seeing loads of packets addressed to port 135 on your
firewall, 
you can DROP those before the LOG rule and start to narrow down what you
log 
to only the stuff you find interesting.

> # Generated by iptables-save v1.2.7a on Sun Apr  4 22:25:58 2004 
> *filter
>
> :INPUT DROP [0:0]
> :FORWARD DROP [0:0]
> :OUTPUT DROP [0:0]
>
> -A INPUT -i lo -j ACCEPT
> -A INPUT -i eth1 -j ACCEPT
> -A INPUT -p icmp -j ACCEPT
> -A INPUT -p tcp -m tcp --sport 25 -j ACCEPT
> -A INPUT -i ppp0 -p tcp -m tcp --dport 22 -j ACCEPT
> -A INPUT -i ppp0 -p tcp -m tcp --dport 25 -j ACCEPT
> -A INPUT -i ppp0 -p tcp -m tcp --dport 80 -j ACCEPT
> -A INPUT -i ppp0 -p tcp -m tcp --dport 443 -j ACCEPT
> -A INPUT -i ppp0 -p tcp -m tcp --dport 10000 -j ACCEPT
> -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
> -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
> -A FORWARD -s 192.168.100.0/255.255.255.0 -j ACCEPT

I still disapprove of the above rule.   It will allow packets from the 
Internet which have a source address matching your internal network to
get 
through the firewall.   You should tighten it by adding the source
interface 
eth1 as well:

iptables -A FORWARD -s 192.168.100.0/24 -i eth1 -j ACCEPT

> -A FORWARD -d 192.168.100.6 -p tcp -m tcp --dport 22 -j ACCEPT -A 
> FORWARD -d 192.168.100.6 -p tcp -m tcp --dport 7783 -j ACCEPT -A 
> OUTPUT -s 127.0.0.1 -j ACCEPT -A OUTPUT -o eth1 -j ACCEPT
> -A OUTPUT -p tcp -m tcp --sport 80 -j ACCEPT

You still have INPUT rules for ports 80 and 443, but a OUTPUT rule only
for 
port 80 (as well as a default ACCEPT policy which will allow the 443
packets 
as well as any others).   This inconsistency doesn't look good.

> -A OUTPUT -p tcp -m tcp --sport 25 -j ACCEPT
> -A OUTPUT -p tcp -m tcp --sport 22 -j ACCEPT
> -A OUTPUT -o ppp0 -p udp -m udp -m multiport --ports domain -j ACCEPT 
> -A OUTPUT -o ppp0 -p tcp -m tcp -m multiport --ports http -j ACCEPT -A

> OUTPUT -o ppp0 -p tcp -m tcp -m multiport --ports smtp -j ACCEPT -A 
> OUTPUT -o ppp0 -p tcp -m tcp -m multiport --ports ndmp -j ACCEPT 
> COMMIT # Completed on Sun Apr  4 22:25:58 2004

Personally I would prefer to see:

iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT ......... -j ACCEPT
  .... for each type of traffic you want to allow in to the "firewall"
iptables -A OUTPUT ........ -j ACCEPT
  .... for each type of traffic you want to allow out
iptables -A FORWARD ........ -j ACCEPT
  .... for each type of traffic you want to allow through.

By using the ESTABLISHED,RELATED rules more effectively, you can focus
only on 
the destination ports in all three chains, and not need to have matching

rules in INPUT and OUTPUT, with source ports in one and destination
ports in 
the other, as you have done.

Hope this helps,

Regards,

Antony.

-- 
One good tern deserves another.

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



---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.650 / Virus Database: 416 - Release Date: 4/4/2004
 

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.650 / Virus Database: 416 - Release Date: 4/4/2004
 

Re: Is this config OK, plus where should I be logging...

[Antony Stone]

On Monday 05 April 2004 6:46 am, Stuart Lamble wrote:

> Thanks for your reply, it has me thinking here.
>
> I agree, running local services on a firewall is asking for it,
> especially with SMTP.
> I think what I need to do is add a third network card to the firewall
> and create a DMZ, probably safer than dnat-ing to these services on the
> LAN, such as SMTP server on the LAN.

Yes; if you DNAT external IPs to an internal LAN address, and then someone 
finds out how to exploit your mail server, your LAN is wide open to them.

If you place the mail server on a DMZ, it should have very restricted access 
to your LAN (if any), so someone who gets into your mail server has your mail 
server and nothing else.

> That will add some extra rules to the firewall, but at least now it will
> be a pure netfilter machine ;-)
> I will probably just open UDP 53,TCP 80 and FTP for the purposes of
> connecting to the net and running updates from the firewall itself.
> I may also want ssh, so I can admin from the internet, but then I could
> always ssh to the DMZ and then ssh from there to the firewall, probably
> safer.

The more hoops a cracker has to go through to get at something valuable, the 
less likely it is they'll succeed.

> Just a few questions on your reply below?
> On the "-t nat" table , PREROUTING, OUTPUT and POSTROUTING is -P ACCEPT.
> Good or bad

Absolutely vital.   *Always* leave nat tables with ACCEPT policies.   All 
sorts of nasty and incomprehensible things will happen if you set default 
DROP policy on a nat table :)

> Also, I currently have an eth0 which is the Un-trusted interface
> connecting to my DSL modem.
> I have eth1 which is my trusted LAN and ppp0, which is the virtual
> interface that comes up when the DSL line is up, pritty much 24/7.
> However, I base my rules on ppp0 as the un-trusted interface and not
> eth0, in fact in a previous email, you asked where is eth0? What should
> I do here?

To be honest I'm not sure - I'm not familiar with that arrangement.   I use 
DSL, however I have an ethernet cable between my firewall and my DSL modem 
and I talk pure IP/ethernet over that - no PPP involved anywhere.   Maybe 
someone else can suggest how you should deal with this.

> What is the very first table that a packet will "touch" as it comes into
> the firewall? PREROUTING or INPUT?
> I believe it will be PREROUTING, as a packet may be destined for another
> machine on the network, dnat...

Exactly.   It has to be PREROUTING (think about the name) because the next 
step is the routing decision and the selection of whether the packet is going 
to enter INPUT or FORWARD....

> So, should this table be not be the most "looked after" as so to speak,
> followed by the FORWARD table?

You should not put filtering (DROP, REJECT) rules in your nat tables, 
therefore place whatever DNAT rules you need in PREROUTING, but put your 
security effort into INPUT and FORWARD.

> Especially if we have a DMZ, where we are PREROUTING most services to
> that interface, and almost nothing will be for INPUT as no services will
> be running on the firewall itself, except for ssh????

Remember the DMZ services will still go through FORWARD - that is where you 
should be selective about what you allow and in which direction/s.

> For your time, it is truly appreciated.

Thank you.   Glad you found the mailing list useful.

Regards,

Antony.

-- 
There's no such thing as bad weather - only the wrong clothes.

 - Billy Connolly

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

Re: Is this config OK, plus where should I be logging...

[Unknown, Alistair Tonner]

On April 5, 2004 05:11 am, Antony Stone wrote:
> 
		< much snippage for brevity>
>
> > Also, I currently have an eth0 which is the Un-trusted interface
> > connecting to my DSL modem.
> > I have eth1 which is my trusted LAN and ppp0, which is the virtual
> > interface that comes up when the DSL line is up, pritty much 24/7.
> > However, I base my rules on ppp0 as the un-trusted interface and not
> > eth0, in fact in a previous email, you asked where is eth0? What should
> > I do here?
>
> To be honest I'm not sure - I'm not familiar with that arrangement.   I use
> DSL, however I have an ethernet cable between my firewall and my DSL modem
> and I talk pure IP/ethernet over that - no PPP involved anywhere.   Maybe
> someone else can suggest how you should deal with this.
>


	I'm in the pppoe boat myself.  I have eth0 connected to a DSL modem, and the 
	ineternet pipe is indeed ppp0.  What my system does is come up with 
	eth0 configured to 0.0.0.0 to get the pppoe tunnel running, then after its
	up configures eth0 to the ip address range that the modem itself talks
	on (10.0.3.x in my case) and then drops all traffic initiated from the modem 
	side. I allow out ONLY telnet (to allow management of the modem in those freaky 
	moments when someone is playing in the CO) and related established back in,
	based on the source ip of the modem. -- works for me.
	
	This causes no havoc for me since my internal lan is on a different 10. subnet and
	since there really aren't too many 'sploits that can get back through the modem 
	I'm probably being paranoid.  In this configuration the modem doesn't 'exist' on the 
	internet, nor is it a device that can be connected to --- it HAS no ip address on the internet,
	the internet IP is attached to the ppp0 device on my machine.


	Alistair Tonner

	(on an aside Anthony ... what value do you see in a smoll system config of breaking the traffic down
	into user chains based on direction of traffic? -- and only using the builtins to get the packets into those
	user chains?)

Re: Is this config OK, plus where should I be logging...

[Antony Stone]

On Monday 05 April 2004 2:14 pm, Alistair Tonner, the man with no email 
address, wrote:

> 	(on an aside Antony ... what value do you see in a smoll system config of
> breaking the traffic down into user chains based on direction of traffic?
> -- and only using the builtins to get the packets into those user chains?)

I see no benefit in that unless your traffic rules are sufficiently complex to 
make them easier to understand if you break them down into multiple user 
chains (and for what I think you described as a "small system", you wouldn't 
have that complexity).

Most systems below an unreasonable level of complication have rules which fall 
into the following categories:

1. Clients on local LAN accessing servers on Internet.
2. Clients on local LAN accessing servers on DMZ.
3. Systems on the Internet accessing servers on DMZ.
4. Servers on DMZ accessing the Internet.
5. Replies to any/all the above.

For the very simplest systems of course you don't even have categories (2), 
(3) or (4).

For most small systems, (1) is very simple - allow everything.
(2) and (4) (for a simple setup) provide the same services, so combined rules 
can be used without bothering about the input interface.
(3) is the area where your level of paranoia determines how complex your rules 
get.
(5) is a single rule on the whole firewall allowing Established / Related 
packets.

Therefore I see no reason not to put the whole lot of the above into a single 
FORWARD chain, with the proviso that rule (5) comes first.

Regards,

Antony.

-- 
I don't know, maybe if we all waited then cosmic rays would write all our 
software for us. Of course it might take a while.

 - Ron Minnich, Los Alamos National Laboratory

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

Re: Is this config OK, plus where should I be logging...

[Antony Stone]

On Monday 05 April 2004 2:34 pm, Antony Stone wrote in error:

> Most systems below an unreasonable level of complication have rules which
> fall into the following categories:
>
> 1. Clients on local LAN accessing servers on Internet.
> 2. Clients on local LAN accessing servers on DMZ.
> 3. Systems on the Internet accessing servers on DMZ.
> 4. Servers on DMZ accessing the Internet.
> 5. Replies to any/all the above.
>
> For most small systems, (1) is very simple - allow everything.
> (2) and (4) (for a simple setup) provide the same services, so combined
> rules can be used without bothering about the input interface.
> (3) is the area where your level of paranoia determines how complex your
> rules get.
> (5) is a single rule on the whole firewall allowing Established / Related
> packets.

I got 3 and 4 mixed up there, of course...

It should read "(2) and (3) (for a simple setup) provide the same services, so 
combined rules can be used without bothering about the input interface.
(4) is the area where your level of paranoia determines how complex your rules 
get."

Regards,

Antony.

-- 
Normal people think "If it ain't broke, don't fix it".
Engineers think "If it ain't broke, it doesn't have enough features yet".

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