[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: iptables for 1 interface pc and other questions

Benedict Verheyen wrote:
> Op vr 17-01-2003, om 19:04 schreef Jason McCarty:
> > You should specify the input interface (-i eth0) in these lines. Local
> > ( 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?

Yes, packets from lo would get dropped currently, so you'd have to have
explicit rules to ACCEPT them. A good way to do this, especially if
you're putting in another NIC, is to have a separate chain for each
interface. So you would do:
  iptables -N inet_in
  iptables -N lan_in
  iptables -N local_in
  iptables -A INPUT -i eth0 -j inet_in
  iptables -A INPUT -i eth1 -j lan_in
  iptables -A INPUT -i lo   -j local_in

As well as *_out chains for OUTPUT. Then you can do:
  iptables -A inet_out ...restrictive output rules...

And then to trust lo for everything,
  iptables -A local_in -j ACCEPT
  iptables -A local_out -j ACCEPT

This makes it easier to specify how much you trust each interface.

> > > 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?

Yes, that's what I do actually. I have these rules in my firewall:
  iptables -A INPUT -i $inet_if -j checkspoof
  iptables -N checkspoof
  iptables -N logspoof
  iptables -A checkspoof -s -j logspoof
  iptables -A checkspoof -s -j logspoof
  iptables -A checkspoof -s -j logspoof
  iptables -A logspoof -m limit --limit 3/min -j LOG --log-prefix \
    "ip spoofing detected " --log-tcp-sequence --log-level info
  iptables -A logspoof -j DROP

> > > * 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)

Yeah, either would work by itself, I just like to be thorough ;)

> > 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:
> 2. packets that are meant for the firewall machine
> 3. packets send from the firewall
> 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?

Not quite. When you're MASQUERADEing, and the firewall receives a packet
from the internet, it first checks whether the packet should be forwarded
to the LAN (i.e. it's part of a pre-existing connection to a LAN machine,
or you're doing port forwarding). If it is, it will rewrite the
destination address to match the correct LAN machine, then send the
packet through FORWARD (this address rewriting takes place in PREROUTING).
Otherwise, the packet goes through INPUT.

Something similar happens with packets from the lan going to the
internet, except the source address is rewritten, and it doesn't happen
until POSTROUTING (which is after FORWARD sees it).

So in the FORWARD chain, you can just pretend that all your LAN machines
have real public ip addresses.

> > 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.

Ah yes, the magic of caffeine :)

Have fun


Reply to: