* Is this config OK, plus were should I be logging... @ 2004-04-04 17:26 Stuart Lamble 2004-04-04 17:56 ` Is this config OK, plus where " Antony Stone 0 siblings, 1 reply; 9+ messages in thread From: Stuart Lamble @ 2004-04-04 17:26 UTC (permalink / raw) To: netfilter :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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Is this config OK, plus where should I be logging... 2004-04-04 17:26 Is this config OK, plus were should I be logging Stuart Lamble @ 2004-04-04 17:56 ` Antony Stone 2004-04-04 18:41 ` Stuart Lamble 0 siblings, 1 reply; 9+ messages in thread From: Antony Stone @ 2004-04-04 17:56 UTC (permalink / raw) To: netfilter 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: Is this config OK, plus where should I be logging... 2004-04-04 17:56 ` Is this config OK, plus where " Antony Stone @ 2004-04-04 18:41 ` Stuart Lamble 2004-04-04 19:07 ` Antony Stone 0 siblings, 1 reply; 9+ messages in thread From: Stuart Lamble @ 2004-04-04 18:41 UTC (permalink / raw) To: netfilter 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Is this config OK, plus where should I be logging... 2004-04-04 18:41 ` Stuart Lamble @ 2004-04-04 19:07 ` Antony Stone 2004-04-05 5:46 ` Stuart Lamble 0 siblings, 1 reply; 9+ messages in thread From: Antony Stone @ 2004-04-04 19:07 UTC (permalink / raw) To: netfilter 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: Is this config OK, plus where should I be logging... 2004-04-04 19:07 ` Antony Stone @ 2004-04-05 5:46 ` Stuart Lamble 2004-04-05 9:11 ` Antony Stone 0 siblings, 1 reply; 9+ messages in thread From: Stuart Lamble @ 2004-04-05 5:46 UTC (permalink / raw) To: netfilter 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Is this config OK, plus where should I be logging... 2004-04-05 5:46 ` Stuart Lamble @ 2004-04-05 9:11 ` Antony Stone 2004-04-05 13:14 ` Unknown, Alistair Tonner [not found] ` <200404050914.19563.Alistair Tonner <> 0 siblings, 2 replies; 9+ messages in thread From: Antony Stone @ 2004-04-05 9:11 UTC (permalink / raw) To: netfilter 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Is this config OK, plus where should I be logging... 2004-04-05 9:11 ` Antony Stone @ 2004-04-05 13:14 ` Unknown, Alistair Tonner [not found] ` <200404050914.19563.Alistair Tonner <> 1 sibling, 0 replies; 9+ messages in thread From: Unknown, Alistair Tonner @ 2004-04-05 13:14 UTC (permalink / raw) To: netfilter 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?) ^ permalink raw reply [flat|nested] 9+ messages in thread
[parent not found: <200404050914.19563.Alistair Tonner <>]
* Re: Is this config OK, plus where should I be logging... [not found] ` <200404050914.19563.Alistair Tonner <> @ 2004-04-05 13:34 ` Antony Stone 2004-04-05 13:48 ` Antony Stone 0 siblings, 1 reply; 9+ messages in thread From: Antony Stone @ 2004-04-05 13:34 UTC (permalink / raw) To: netfilter 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Is this config OK, plus where should I be logging... 2004-04-05 13:34 ` Antony Stone @ 2004-04-05 13:48 ` Antony Stone 0 siblings, 0 replies; 9+ messages in thread From: Antony Stone @ 2004-04-05 13:48 UTC (permalink / raw) To: netfilter 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2004-04-05 13:48 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-04-04 17:26 Is this config OK, plus were should I be logging Stuart Lamble
2004-04-04 17:56 ` Is this config OK, plus where " Antony Stone
2004-04-04 18:41 ` Stuart Lamble
2004-04-04 19:07 ` Antony Stone
2004-04-05 5:46 ` Stuart Lamble
2004-04-05 9:11 ` Antony Stone
2004-04-05 13:14 ` Unknown, Alistair Tonner
[not found] ` <200404050914.19563.Alistair Tonner <>
2004-04-05 13:34 ` Antony Stone
2004-04-05 13:48 ` Antony Stone
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).