Quote:
Originally Posted by mfoley
Astrogeek: Thanks for that extensive discourse and examples. Athough, I don't know if I totally agree with your assertion that "everything you need to know is in the man pages." I looked for information on understanding, for example, what the various datatypes meant and found little either in the man pages or on the web, although both referenced man pages were highly useful for syntax, if not in-depth explanation.
|
You are welcome, glad they were helpful!
All I can tell you is that pretty much everything I have learned about both iptables and ipsets came from reading the respective man pages, and lots of experimentation!
As I recall, my web searches turned up many references for specific rules and examples for iptables, but no stand-out general help understanding it in any depth. Ditto for books, of which I bought a few that were largely dissapointments.
For ipset, I found very little online and pieced it together almost entirely from the man page. And in retrospect, I would still say that all necessary information about "how it works" is there, and mostly well written if a bit terse. What is missing is a "how to use it in the real world" guide.
Although iptables and ipset are related, neither depends on the other - you can use iptables without ipset, and you can create and manage ipset sets without any interaction with iptables (which may seem pretty useless, but perhaps not entirely so). This makes it easy to explore ipset operations without upsetting your active firewall rules. That said, obviously their intended use is to work together.
One tip I would suggest is to set up test environment for learning each more usefully. Don't try to learn them in a live remote environment - you will stumble all over yourself and learn the meaning of the word "frustration"! Instead, set up an old or non-critical system as your learning target, and learn interactively by testing rule behavior by accessing it from another local machine.
Also, the iptables rules, including their ipset interactions, are, or should be, the implementation of clear firewall policies. So it is very helpful to write out in plain human language just what those policies are! Make that a habit while learning, then manage and test your real world rules against a clear policy document. Use your own outline or graph notation, whatever helps you quickly and unambiguously understand your meaning when you look at it after a few months. When you need to add or change something, annotate the policy document first, then make the rule change.
In doing so you will not only learn it well, you will also build your own best set of reference notes and examples and quickly improve your ability to organize and script multiple, complex rules sets.
Quote:
Originally Posted by mfoley
I did find that ipsets persist even when iptables is terminated, which is good. I suppose unless I do save ipsets they would not persist through reboot.
|
Yes, ipset sets are not affected by changes of iptables rules (other than number of references), and yes, they must be saved and restored, or initialized from a file after reboot.
I generally prefer managing my persistent set data in a text file rather than using the save/restore process, but do what is easiest for you. Dynamic sets are... dynamic, so I write those rules to take care of themselves, mostly.
Quote:
Originally Posted by mfoley
I guess my only remaining question has to do with your PREROUTING example and whether my --match rules are adequate or correct.
|
You can do what works best for your uses. The main reason I suggested the top of the raw::PREROUTING chain is that if you really want to ban everything from some locations and never have to see them again, that is a single point place to do it! Doing it in both the filter::FORWARD and filter::INPUT chains allows you to manage them separately and to see separate counters for each path, which may be important to you. It also means that packets you know up front that you want to ban may traverse more rules and consume CT resources before actually being dropped which might be a consideration.
My philosophy is to drop them as early as possible, which is early in the raw::PREROUTING chain.
