Greetings all, I had initially thought I might be too late to make any contribution to this project when Brent informed me that development had already begun, but I've been tracking its development since, and since it's still at this early stage, I feel I may as well emerge from the shadows and introduce myself. I'm also mostly a (in chronological order) BASIC/ARM Assembler/C/C++/Java/PHP programmer, but I keep hearing good things about Python, and this seems like as good an excuse as any to learn it. I have, however, no previous experience of developing 'real' packaged software - I have only ever created very small programs to do very specific tasks. I can't (yet) use Makefiles, build RPM's, etc, but I can design algorithms and write code. Unfortunately, I'm a student with a few late coursework assignments and a lot of unattended lectures :-/ at the moment, so that's going to be my number 1 priority for a while at least. If I get myself up to date in time, and depending on the pace of development, I'll learn some new skills and take a more active role (I'll keep you posted on that one). Regardless, I, like a few of you others, have toyed with the idea of doing this project myself, so I'll still watch the development closely and present any ideas I come up with as and when. I've been feeling a growing obligation to join in the development within this community for some time now, and this is exactly the kind of thing that'll start pulling administrators back toward Unix/Linux and away from Microsoft <spit>. Now I wish I'd kept up to date with my uni stuff - it seems you guys are gonna have all the fun for now ;) . On Sat, 2004-02-21 at 17:00, Tyler Larson wrote: > <snip> As far as rule parsing is concerned, here's a few things to keep in mind: > > * We should be liberal in what we accept as far as rule symantics are > concerned. We can never be totally certain that what we don't know how to parse > is an invalid rule. If someone comes up with a new firewall module, the > iptables firewall rule is very likely where that module's configuration will > go. When we can't parse a rule, we ought to let the user know, but I'm not sure > we should do anything drastic like mangle it or throw it out. On the other > hand, if we try to re-insert an invalid rule back into the kernel, it will barf > reject the whole ruleset--something to avoid. So... Maybe we should validate > the rules and display a warning if we don't understand them before sending them > off to the kernel. > > * Rules technically only have to be parsed if they're going to be modified or > examined. A rule *can* be read in and written back without any examination at > all, for whatever that's worth. Granted, it might be best to parse once on > read, but then again, it might also be best to parse on-demand. I'm not sure > what all the implications of either method may be. > It might be better to manipulate the ruleset by inserting and deleting individual rules directly rather than writing a configuration file and using iptables-restore. This would obviously lend itself to a user interface where any changes made will take effect immediately on a per-rule basis, so our 'Apply' button will be in the rule editor rather than at a more global level. On the more global level, the user will then have options to either save or undo and discard changes. This may seem a little illogical at first, but it could actually be useful in situations where you want to make a temporary change to the firewall set (to do a port scan, for example :D ) and you don't want the rule to still be there on reboot, should you happen to forget to remove it. This approach would also alleviate any problems regarding rules that we can't parse for whatever reason - any rules that are already in place will go untouched, and we can leave it to iptables-save to generate a configuration file, which it will do reliably. This way, any bugs in the GUI will only affect the rule it operates on, rather than trashing the entire firewall. Remember this is a security tool we're creating, so minimising the possible effect of any bugs will be important. My advice would certainly be to stay in close communication with iptables itself rather than work 'behind its back'. * Remember that the "native* format for any parameters is text--we read it in > as text, and we write it out as text. Once again, I'm not sure what the best > method to use here is, but when we take a parameter (such as an IP address) and > convert it into its numeric representation for internal storage rather than its > textual representation, we're introducing an extra step and increasing the > complexity of our application. Now, if we're going to do any numeric > comparisions using the address, we have to have it in numeric form, so that > step is necessary. I guess what I'm saying here is that we have to decide which > parameters should be "transparent" (e.g. numeric form) , and which ones should > be "opaque" (e.g. textual form). Making parameters transparent allows for > greater flexibility, but introduces more opportunity for error. Leaving them > opaque reduces the chance of error and bugs, but it less useful. > > My original concept application used one-time parsing of parameters (i.e. > classifying the "chunks" of a rule), but relied on on-demand interpretation of > parameters (i.e. converting textual addresses to numeric ones). I don't know if > that's the best way to do things, but I figured it would be best to bring up > the issue and let people think about it. > Hostname-to-IP address resolution can be left to iptables when inserting rules at the very least. Caution though, inserting a rule involving a hostname can cause iptables to actually insert a series of rules rather than just one in some cases, here's an example: # iptables -A OUTPUT -j ACCEPT -d post.demon.co.uk # iptables-save -A OUTPUT -d 194.217.242.89 -j ACCEPT -A OUTPUT -d 194.217.242.88 -j ACCEPT -A OUTPUT -d 194.217.242.86 -j ACCEPT -A OUTPUT -d 194.217.242.85 -j ACCEPT -A OUTPUT -d 194.217.242.92 -j ACCEPT -A OUTPUT -d 194.217.242.91 -j ACCEPT -A OUTPUT -d 194.217.242.90 -j ACCEPT So keep the GUI and firewall talking closely if you go for this approach. This kind of bug could easily go unnoticed for some time. One final note - it is generally considered (so I hear) a very bad idea to use hostnames in /etc/sysconfig/iptables, since it can leave a system susceptible to DNS poisoning upon reboot. If you do write hostnames into a configuration file, have iptables reload the config but then recreate the config file using output from iptables-save, which will /always/ address things numerically. I hope this helps, and I'll be in touch... Many regards, -- Dylan Piergies Brunel University, UK ma03dlp@xxxxxxxxxxxx
<<winmail.dat>>