Re: Few questions about using rc.firewall.iptables
"Romanenko M.A." wrote:
>
> We have a firewall (Debian Linux sid, kernel 2.4.0, iptables 1.2) between our net and Internet. To configure iptables I use http://www.sentry.net/~obsid/IPTables/rc.scripts.dir/current/rc.firewall.iptables.
> I had to change the original script so that it matched our environment:
> Firewall is connected to the Internet via leased line (PPP), and to the private network via 100 MB Ethernet.
> Private network consist of 7 subnetworks: 172.16.0.0/16, 172.17.0.0/16, 172.18.0.0/16
> 172.25.0.0/16, 172.26.0.0/16, 172.27.0.0/16, 172.28.0.0/16
> We have domain of our own. DNS and Sedmail is running on the firewall.
> Some users (not everyone) are allowed to send/recieve E-mail to/from the Internet and are not allowed to connect to any other Internet resources.
> Some users (not everyone) are allowed to connect to any Internet resources (E-mail including).
>
> I made the followinf changes to the script:
>
> #!/bin/sh
> ##################################################################
> #
> ## rc.firewall.iptables -- Version 1.1b
> #
> ##################################################################
> ## Obsid@sentry.net
> ## http://www.sentry.net/~obsid/
> ## 10/20/00
>
> ## Example IPTables 1.1.2 script for a dual homed firewall.
> ## Please feel free to send me any comments or suggestions.
>
> ## Visit one of the NetFilter Project Home Pages for more information about IPTables.
> ## http://netfilter.kernelnotes.org/
>
> [...]
> ## Variables
> IPTABLES="/usr/sbin/iptables"
> INTERNAL="eth0" # Internal Interface
> EXTERNAL="ppp0" # External Interface
> LOOPBACK="lo" # Loopback Interface
> INTERNAL_NET="172.16.0.0/12"
> ANY_ALLOWED="<IP-addresses of users allowed to connect to any Internet resources>"
> MAIL_ALLOWED="<IP-addresses of users allowed to send/recieve E-mail to/from the Internet>"
>
> [...]
>
> ###############################################################################
> ## New chain for input to the internal interface
>
> $IPTABLES -N INTERNAL-input
> $IPTABLES -F INTERNAL-input
>
> ## ACCEPT internal to internal traffic
> #--- $IPTABLES -A INTERNAL-input -i $INTERNAL -s $INTERNAL_NET -d 0/0 -j ACCEPT
> for HOST in $ANY_ALLOWED $MAIL_ALLOWED; do
> $IPTABLES -A INTERNAL-input -i $INTERNAL -s $HOST -d 0/0 -j ACCEPT
> done
>
> [...]
>
> ##------------------------------------------------------------------------##
> ## Source NAT -- (SNAT/Masquerading)
> ##------------------------------------------------------------------------##
>
> ## Source NAT allows us to "masquerade" our internal machines behind our
> ## firewall.
>
> ## Static IP address ##
> ## Change source address of outgoing packets on external
> ## interface to our IP address.
> #--- $IPTABLES -t nat -A POSTROUTING -o $EXTERNAL -j SNAT --to $EXT_IP
> for HOST in $ANY_ALLOWED; do
> $IPTABLES -t nat -A POSTROUTING -o $EXTERNAL -s $HOST -j SNAT --to $EXT_IP
> done
>
> ## Dynamic IP address ##
> #--- $IPTABLES -t nat -A POSTROUTING -o $EXTERNAL -j MASQUERADE
> for HOST in $ANY_ALLOWED; do
> $IPTABLES -t nat -A POSTROUTING -o $EXTERNAL -s $HOST -j MASQUERADE
> done
>
> [...]
>
> ## EOF
One thing to note here,
If you have a static IP address the MASQUERADE rule is not needed here.
The SNAT rule is used for a static IP, and the MASQUERADE rule is used
if you have a dynamic IP address.
>
> It works, I don't see any warnings in the log files, but I'd like to be sure I didn't decrease security level by having made such modifications. My questions are:
>
> 1 Is it enough (for security reasons) to modify only INPUT chain for ALL_ALLOWED and
>MAIL_ALLOWED users, and NAT table for ALL_ALLOWED users. Isn't it be more secure to
>modify OUTPUT and FORWARD chains as well? I tried to modify FORWARD chain, but it
>gave me nothing. Any user which passed INPUT chain passed FORWARD as well never mind
>whether I tried to control his passing or not. Could it be because FORWARD policy is
>ACCEPT?
This could be so, yes. Unless I'm mistaken, packets routed through the
box shouldn't traverse the input/output chains. The script is designed
to have a user defined chain for input/output for each interface, and
those chains are called from the built in chains, INPUT/OUTPUT/FORWARD.
Of course, this doesn't always work as smoothly as I'd like :/
For those hosts that are allowed to send receive email I'd suggest
adding a few rules to REJECT everything except packets to/from port
25(smtp) and 110(pop3), or perhaps 143(imap2) or 220(imap3), depending
on your setup.
For example, you could add this to the end of the INTERNAL_INPUT chain
(called INTERNAL-input in your version).
for HOST in $MAIL_ALLOWED; do
$IPTABLES -A INTERNAL_INPUT -i $INTERNAL -s $HOST -p tcp -m multiport \
--destination-port 25,110 -j RETURN
$IPTABLES -A INTERNAL_INPUT -i $INTERNAL -s $HOST -j REJECT
done
Then, hopefully, the KEEP_STATE chain should take care of the rest....
> And here is my 2-d question.
>
> 2 In the script default policy are:
> [...]
> ## Set Default Policies
> $IPTABLES -P INPUT DROP ## Highly Recommended
> $IPTABLES -P OUTPUT ACCEPT
> $IPTABLES -P FORWARD ACCEPT
> [...]
> Isn't it be more secure to have all of them DROP?
>
I'd say yes, if you can get that to work ok for your setup. You'd have
to add a few new rules to specifically accept OUTPUT/FORWARD traffic,
but I'd say it would be reasonably manageable. Might also be a good
idea to keep a good supply of aspirin on hand just in case ;p
> 3 To let users send/receive E-mail to/from Internet I add to ALLOW_EXTERNAL_PORTS chain strings:
> [...]
> ## SMTP
> $IPTABLES -A ALLOW_PORTS-EXTERNAL -i $EXTERNAL -p tcp --dport 25 -j ACCEPT
> [...]
No, this will allow input to the external interface, meaning the world
will probably be able to see the sendmail daemon running on your
firewall. This may be what you want anyway.
> Shouldn't I add the same string for udp?
No, I don't believe so. I'm pretty sure most mta daemons use the tcp
protocol.
> 4 Do I uderstand right that INTERNAL_NET="172.16.0.0/12" match any network in range 172.16.0.0/16 - 172.32.0.0/16?
Let's see, 172.16.0.0 with a mask of 255.240.0.0 should match any
address between 172.16.0.0 - 172.31.255.255
>
> Thank you, Mikhail.
Hope this helps a bit,
Steve.
Reply to: