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

Re: Firewall for pppoe



On Thu, Nov 21, 2002 at 03:24:39PM -0800, Bill Moseley wrote:
[snip]
> So, my current iptables script uses eth0 as the external interface.  I
> assume this should be ppp0 when running pppoe.  On boot (before pppoe is
> running) should I leave it at eth0 and then when pppoe starts should I have
> a /etc/ppp/ip-up.d version that uses ppp0 instead of eth0?

I think you can just leave it as ppp0. Iptables doesn't complain about
you entering nonexistent interfaces, the rules mentioning ppp0 simply
won't match until ppp0 exists. The -j MASQUERADE rule takes care of
using the correct ip address for NAT.

> I'd like both (ppp0 when using ADSL and eth0 otherwise) incase the machine
> ends up on a static IP again.

I think you could do this by creating new chains for INPUT and OUTPUT,
that don't mention the incoming interface, and then have for example:

  iptables -A INPUT -i eth0 -j extinput
  iptables -A INPUT -i ppp0 -j extinput
  iptables -A OUTPUT -o eth0 -j extoutput
  iptables -A OUTPUT -o ppp0 -j extoutput

Then all your rules wouldn't need to test which interface packets came in
on. This still lets you add some interface-specific rules if needed, of
course.

> Again, this would seem to be a common home network setup.  Are there any
> suggested firewall/MASQ scripts to use?  I'm currently using:
> 
> http://www.tldp.org/HOWTO/IP-Masquerade-HOWTO/stronger-firewall-examples.html
> 
> and thinking about changing to:
> 
> http://www.linuxhelp.net/guides/iptables/

Can't really say. I've been using a custom script for about a year now,
that fits my needs pretty well. That second URL is certainly more
comprehensive than what I use.

> One last question:
> 
> On my other machines using ipchains I block both INPUT and OUTPUT and
> specifically set rules for both directions.  That is, to open up ssh I did:
> 
>     ipchains -A input  -i $EXTERNAL_INTERFACE -p tcp  \
>              --source-port $SSH_REMOTE_PORTS \
>              -d $IPADDR 22 -j ACCEPT
> 
>     ipchains -A output -i $EXTERNAL_INTERFACE -p tcp ! -y \
>              -s $IPADDR 22 \
>              --destination-port $SSH_REMOTE_PORTS -j ACCEPT
> 
> But the iptables scripts I've found seem to allow everything outgoing and
> just block new connections coming in.  I perfer the ipchanins method above
> so that I can track what's outgoing, but maybe that's pointless (pointless
> because some "bad" program could just use the non-blocked ssh port to send
> out from).

Yes, I think most people rely on the state match for implicit access
control, but you could certainly use both methods at once if you want
more flexibility.

  iptables -A extinput -p tcp --sport $SSH_REMOTE_PORTS --dport 22 \
           -m state --state ESTABLISHED -j ACCEPT
  iptables -A extinput -p tcp --sport $SSH_REMOTE_PORTS --dport 22 \
           -m state --state NEW -j do_we_want_to_accept_in

  iptables -A extoutput -p tcp --sport 22 --dport $SSH_REMOTE_PORTS \
           -m state --state NEW -j do_we_want_to_accept_out
  iptables -A extoutput -p tcp --sport 22 --dport $SSH_REMOTE_PORTS \
           -m state --state ESTABLISHED -j ACCEPT

This rule set would accept established connections automatically, call
another chain to decide on new connections, and deny any other type of
connection to port 22, assuming you have a deny-by-default policy.

Iptables state tracking just gives you some more information about
packets and streams, you don't have to use it.

By the way, here's a diagram I find useful for figuring out what chains
a given packet will traverse in iptables:
http://open-source.arkoon.net/kernel/kernel_net.png

HTH,

Jason McCarty



Reply to: