'ipfw' IOCTLS available as python module?

Jeff jam at quark.emich.edu
Mon Oct 4 10:41:10 EDT 1999


On Mon, Oct 04, 1999 at 09:56:26AM -0400, François Pinard wrote:
> Jeff <jam at quark.emich.edu> writes:
> 
> > I have need to write a firewall configuration script in python, and
> > one of my design goals is that python not act as just another /bin/bash
> > replacement.  what I'd like is a module that knows how to directly make
> > the ioctl calls described in the ipfw(4) man page (so I don't have to
> > resort to 'os.system("/sbin/ipchains -F")', which looks ugly).
> 
> I worked on about the same problem this weekend.  I still do not feel ready
> to dive into a C interface.  I did not want to repeatedly do `os.system',
> which would surely incurs a lot of overhead.  As a compromise, even if
> far from being a speed winner, I do the equivalent of "popening" `/bin/sh'
> and feeding it with the generated `ipfwadm' or `ipchains' commands, so at
> least, the shell is called only once, instead of once per command.  Still,
> the shell has to decode the command text that my Python script generates,
> and repeatedly fork the program: much less than ideal.
> 

I have implemented a similar thing for similar reasons, so I understand the
frustration factor with making something that looks and feels clean. what I
have is some simple functions that I can pass things too, but they are
nothing more than scaled-up '#define' type macros and not quite an 'api'.
heck.. I haven't even tested it yet ;)

> Enough problems with organising the chains, I told to myself, no need to
> tackle too many problems at once and drawn myself: I'll live with the slow
> speed in the meantime, and probably for a long while.  What I would love
> to have, however, is a Tkinter interface to drive all this, as my users
> are quite lost if they cannot "click easy", and I would like to give them
> the possibility to dig momentary tunnels without having to call me.
> 

I have a similar goal in mind, though I don't expect anyone to be able to
grok the code at first-- I'm more concerned with a common script to manage
the half-dozen machines I want to protect. primarily what I want to do is
not so much 'bullet proof' the machines, but simply try to keep the honest
people honest. this is a university-- to put up a firewall here would be
*asking* for more trouble than it's worth ;)

a Tk (or, actually, GTK) interface wouldn't be *that* hard to implement, and
redhat 6.0 has already done a little work in this regard-- you can use
linuxconf to set up simple firewalls, and I think it even lets you manage it
all remotely. you might want to check it out if you are mostly interested in
a point-and-click interface.

> I would like to seek some generality in my things, but I hardly see how.
> Things are so tuned to of our particular setup, that it seems to me that
> making things general enough to be exportable, sharable or publishable
> would require an effort which is inordinate with our real needs.  Moreover,
> to be fully honest, playing such games is far from being my preferred bag,
> anyway.  I still hardly accept that there are bad guys on this planet:
> this is really not the world I was hoping for in my youth :-).  Life would
> be *so* easier without them.  Good guys should kill all the bad guys! :-)
> 

"good will always triumph over evil, because evil is dumb" -- spaceballs.
that's a perfect world, though, so it's best to shoot for keeping the honest
people honest ;).. as for generality, I have some of that, but it's an
interface to 'os.system' not direct calls into the kernel. if anything it
keeps the code cleaner because it will be less likely to change across
kernel versions.

> > I am willing to work on the project, but I thought I saw *something*
> > whiz by on the mailing list regarding this same issue.
> 
> I do not clearly see how we could put our efforts in common, nor what I
> can bring which you would not already know, but yet, I'm open to fruitful
> collaboration, if it can be organised easily and time-economically! :-)
> 

well, I'll post the code I have so far.. use it if you can, just give credit
where credit is due, and please send patches back to me directly or post to
the list.. comments (including 'This code sucks, and here's some better code
to prove it") appreciated. 

perhaps trying to hook directly into the kernel is 'too much' for this
project, and we ought to run with the other approach instead. 

note that this code *does not* actually execute the 'ipchains' command, it
just echoes it to the screen. this is as much to protect the programmer from
mucking up his machines during the testing phase than anything else, and it
ought to be pretty easy to see what needs to be changed.

regards,
J

-- begin ipchains.py code --
import getopt

def run_command(args):
	buf = "/sbin/ipchains %s" % (args)
	print "run_command: buf='%s'" % (buf)
	return

def flush_all():
	return run_command("-F")


def set_policy(chain, policy):
	return run_command("-P %s %s" % (chain, policy))

def append_rule(chain, **kw):
	
	buf = "-A %s" % (chain)
	for k, v in kw.items():
		if k == "intf":
			buf = buf + " -i %s" % (v)
		if k == "src":
			buf = buf + " -s %s" % (v)
		if k == "dst":
			buf = buf + " -d %s" % (v)
		if k == "protocol":
			buf = buf + " -p %s" % (v)
		if k == "jump":
			buf = buf + " -j %s" % (v)
		if k == "log":
			if v == 1:
				buf = buf + " -l"

	return run_command(buf)

def main():
	_OPEN = 0
	flush_all()
	
	if _OPEN:
		set_policy("input", "ACCEPT")
		set_policy("output", "ACCEPT")
		set_policy("forward", "ACCEPT")
		append_rule("forward", intf="eth0", src="192.168.2.0/24", jump="MASQ")
		return

	set_policy("input", "DENY")
	set_policy("output", "ACCEPT")
	set_policy("forward", "DENY")

	append_rule("forward", intf="eth0", src="192.168.2.0/24",     jump="MASQ")

	append_rule("input",   intf="ppp0", dst="164.76.56.12/32 22", jump="ACCEPT")
	append_rule("input",   intf="eth0", src="192.168.2.0/24",     jump="ACCEPT")

	append_rule("output",  intf="eth0", src="192.168.2.0/24",     jump="ACCEPT")

if __name__ == "__main__":
	main()
-- end ipchains.py code --

-- 
|| visit gfd <http://quark.newimage.com/> 
|| psa member #293 <http://www.python.org/> 
|| New Image Systems & Services, Inc. <http://www.newimage.com/>




More information about the Python-list mailing list