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

Re: iptables gui



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 brunel ac uk

<<winmail.dat>>


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