Re: iptables for 1 interface pc and other questions
Op vr 17-01-2003, om 19:04 schreef Jason McCarty:
> Hi,
>
> I have some comments for you inline.
Cool. :)
> > ###############################################################################
> > #### INPUT ####
> > ###############################################################################
> > #is covered by last rule? $IPT -A INPUT -p ALL -m state --state NEW,INVALID -j DROP
> > $IPT -A INPUT -p ALL -m state --state ESTABLISHED, RELATED -j ACCEPT
> I think you can't have a space here. ^
I will change this.
>
> You should specify the input interface (-i eth0) in these lines. Local
> (127.0.0.1) packets go through the lo interface, so if you had a proxy
> like junkbuster running, your requests to it would get dropped by the
> line below.
I didn't think about this. But won't the packets from lo be dropped
because of the default drop policy in my rules? Or is this solved by
actually specifying -i eth0 here and -o eth0 in OUTPUT?
> Same issue with lo here as in the INPUT chain. Packets destined for
> 127.0.0.1 go out through lo, so you might not want the same restrictions
> on them as the ones going to the Internet. So these lines should have
> -o eth0.
See above.
>
> > ### all tcp ports ###
> > $IPT -A OUTPUT -p tcp --sport 67 --dport 68 -j ACCEPT # DHCP to isp
> I think dhcp is only udp, so you don't want this line.
Thanks. As you probably gathered it's not clear for me what goes on tcp
and what goes on udp so i looked everything up on /etc/services.
> > $IPT -A OUTPUT -p tcp --dport 80 -j ACCEPT # www
> > $IPT -A OUTPUT -p tcp --dport 22 -j ACCEPT # ssh
> > $IPT -A OUTPUT -p tcp --dport 21 -j ACCEPT # ftp
> > $IPT -A OUTPUT -p tcp --dport 110 -j ACCEPT # pop3
> > $IPT -A OUTPUT -p tcp --dport 143 -j ACCEPT # imap
> > $IPT -A OUTPUT -p tcp --dport 194 -j ACCEPT # irc
> Dunno if this is an obsolete entry in /etc/services or what, but every
> irc server I know runs on port 6667 or thereabouts.
Hhhm. There are several entries in /etc/services:
irc 194/tcp # Internet Relay Chat
irc 194/udp
ircs 994/tcp # IRC over SSL
ircs 994/udp # IRC over SSL
ircd 6667/tcp # Internet Relay Chat
dircproxy 57000/tcp # Detachable IRC Proxy
So i thought it as 194 because 6667 said "ircd". My bad.
> > ### all udp ports ###
> > $IPT -A OUTPUT -p udp --sport 67 --dport 68 -j ACCEPT # DHCP to isp
> > $IPT -A OUTPUT -p udp --dport 80 -j ACCEPT # www
> > $IPT -A OUTPUT -p udp --dport 22 -j ACCEPT # ssh
> > $IPT -A OUTPUT -p udp --dport 21 -j ACCEPT # ftp
> > $IPT -A OUTPUT -p udp --dport 110 -j ACCEPT # pop3
> > $IPT -A OUTPUT -p udp --dport 143 -j ACCEPT # imap
> > $IPT -A OUTPUT -p udp --dport 194 -j ACCEPT # irc
> > $IPT -A OUTPUT -p udp --dport 25 -j ACCEPT # smtp
> > $IPT -A OUTPUT -p udp --dport 119 -j ACCEPT # news
> Except for dhcp, these services all run on tcp only, so no need for
> the rest of the above lines.
I'll remove them then.
> The packet-filtering HOWTO says that if you have forwarding turned off,
> packets that want to be forwarded will just be dropped. So I don't think
> you need rules in FORWARD for a single machine.
OK. I thought so but i got confused. I've read the manpages, some 4 or 5
iptables tutorials and looked at several scripts. My brains are spinning
for the moment :)
> > ================================================================
> > Is this setup workable and safe? What should i add?
> > Do i need to add a rule to explicitly deny addresses on eth0 that are RFC 1918
> > or is this already covered by the rules i specified? (i think so)
>
> Yeah, they'll get logged and dropped by your rules.
The only benefit i could see in setting up explicit rules to deny them
is to make sure you see the spoofing attack in the kernel logs, right?
> > Also, do i need to add rules for ping of death in my input chain? Or is this
> > supposed to be added in the forward chain.
>
> If you did have them, they would go in INPUT. However, you already log
> and drop them. However, a real concern is that someone could easily fill
> up your logs with junk packets. You can prevent this by putting a limit
> match (-m limit --limit 2/min for example) in your LOG lines. The
> problem with that is that you might miss some important packets since
> the few that are getting logged are unimportant. I don't really know a
> solution to this conundrum. I just log at 3/min.
Or probably should be doing this in all my log lines then.
>
> > Some other questions:
> > * Am i correct in assuming that on a 1 interface system as above,
> > only the INPUT and OUTPUT chains are used? Or should one check the FORWARD
> > chain anyway?
>
> Correct.
Phew, at least 1 thing that i understood, hehe :)
> > * In a 2 interface gateway, eth0 (internet), eth1(lan):
> > -> from the net, to the firewall machine and then to a host on the lan passes
> > the FORWARD chain on eth0 and the INPUT chain on eth1. Correct?
>
> No. Packets destined for the LAN from the inet, and vice-versa, pass
> through FORWARD only. Only packets destined for the firewall machine
> itself go through INPUT.
> Also, chains aren't "on" interfaces.
I'm having trouble visualising this. In my head, it's a set of INPUT,
OUTPUT and FORWARD chains per interface. Hmm, so this is wrong.
But if you want to explicitly stop the firewall forwarding someting
to the lan, could you use both eth0 and eth1 then to stop
that forwarded packet? Or do you have to specify -i eth0 -o eth1?
(eth0 = net, eth1 = lan)
> If you want to know what interface a
> packet is coming or going on, you have to explicitly test it with -i or
> -o. For example, -i eth1 -o eth0 would match a packet being forwarded to
> the internet, and vice-versa for a packet going from the internet to
> your lan.
See above
> > -> from a host on the lan, to the firewall machine and then to the net passes
> > the OUTPUT chain on eth1 and the FORWARD chain on eth0. Correct?
>
> Only packets created by the firewall machine go through OUTPUT. Look at
> the HOWTOs on www.netfilter.org, they should provide some more clarity.
> I also find this image useful to figure out how packets traverse
> iptables, although it has the internal netfilter names instead of the
> iptables names: http://open-source.arkoon.net/kernel/kernel_net.png
That's quite an impressive picture :)
I rechecked your comments and then checked:
http://www.netfilter.org/documentation/tutorials/blueflux/iptables-tutorial.html
If i understand correctly:
1. packets for the lan and machines there only pass these chains:
PREROUTING, FORWARD and POSTROUTING
2. packets that are meant for the firewall machine
PREROUTING, INPUT
3. packets send from the firewall
POSTROUTING, OUTPUT
An example:
When i would make a dns query from my pc on the lan to the dns server of
my isp, if i get an answer back, it would not hit INPUT but hit the
FORWARD chain only?
But when dealing with MASQUERADE (which i'm going to have to use), it
will first hit INPUT and then FORWARD because the dns of the isp thinks
it's for the firewall. Then the firewall forwards it to the correct pc
on the internal lan. Is this correct?
> Cool. Let us know if you've got more questions.
I will post my 2 nic setup as soon as i get this one up and running. I
really love linux and everthing related to it. One band thing, for me
about linux is that it's so exciting that i stay up far to long and then
end up walking around all day in zombie like fashion :)
Luckily there is coffee.
>
> HTH,
>
> Jason
Jason, thanks for all your very helpful comments!
I'll change my firewall script in the comming days and then test it
on my machine. I'll let you know what happens or hopefully what doesn't
happen :)
Benedict
Reply to: