As stated in the subject, I was looking through the INPUT chain rules and saw that there is a DROP all anywhere as well as an ACCEPT all anywhere.

I don't know that much about iptables, but are these rules working against each other? Should I delete both of them?

Or maybe I am interpreting this incorrectly?

Any explanation would be nice before I start messing around with iptables.

Thanks a lot,
Brian

iptables are a bit more complicated than just that. They can also filter by interface and I have an INPUT rule that ACCEPTs all anywhere from the local interface and then DROPs all anywhere after ACCEPTing specific ports, knowing that all are from the outside facing interface. Messing with those rules does require being familiar with just how a packet flows through the process. I wouldn't suggest deleting them without that knowledge.

I'm getting good with the SuSE firewall2 so I guess I'll just stick with that for now, although I do eventually want to learn iptables. Any suggestions on what I should read to help me understand it better (besides the MAN pages)?

Try this one:
http://iptables-tutorial.frozentux.n...-tutorial.html

In order:

• No (very probably)
• No (certainly)
• Yes (as far as I can tell)

OK, here we go (roughly): Rules are executed, one by one, in order So as a packet comes along, it meets the first rule, is tested against whatever test is implied by that rule and, if it matches, is sent off to be processed, as implied by the rule.

If it doesn't match, it is unprocessed by the first rule and then moves down to the next rule.

When (if) it falls all the way through the set of rules for a chain, there is another, implied, rule for the chain; the 'policy' for the chain, or, to be more explicit, 'a rule to deal with any packet that falls all the way through'. Having a policy of 'drop' is usually considered to be more sensible from a security point of view than 'accept'.

This process is described in a lot more detail in the frozentux tutorial (which is hardly light bedtime reading, except for serious insomniacs, but is an excellent manual). If, instead, you wanted a worked example, have a look at linuxhomenetworking. Their example is almost identical to the relevant chapter and appendix from Harrison's Linux Quick Fix Notebook - also excellent, but a bit more tutorial-ish, (where the supposed tutorial at frozen tux is more manual-ish).

A bit of advice; either use the SuSE firewall, or don't (or be prepared to struggle slightly). One of the troubles with 'going behind yast's back' to set up a set of firewall rules manually, is that yast has a habit of overwriting what you are doing, unless you are careful. You can get round this (either tell yast not to do anything with the firewall and do it all yourself, or let yast do what it does on boot and then modify the ruleset afterwards), but it does add a little complexity to the process.

For most purposes, Yast does a perfectly good job of writing a ruleset (I'm not trying to put you off learning - anything but), so you are probably not in the position of having to do this to 'cure' a 'broken' ruleset. But looking through the ruleset that it generates, and maybe even modifying what you tell yast and looking at the changes that it makes to the ruleset is all to the good as an easy learning stage.