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
