[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: KMyFirewall in KDE 3.x?
From:       Kuba Ober <kuba () mareimbrium ! org>
Date:       2002-11-04 17:19:56
[Download RAW message or body]

On sobota 26 październik 2002 09:42 am, Christian Hubinger wrote:
> On Friday 25 October 2002 23:59, Troels Tolstrup wrote:
> > On Fredag 25 oktober 2002 23:13, Kuba Ober wrote:
> > > I think it should play nice by:
> > > - detecting which of the common firewall config scripts are in place
> > > (like redhat's iptables, which reads /etc/sysconfig/iptables)
> > > - putting the settings into the detected script, and properly
> > > activating/deactivating the script using distro-specific way (say, on
> > > redhat using chkconfig)
> >
> > In those cases where kde comes with system config tools, i would much
> > rather see it do things ONE way. If you want to use redhats scripts and
> > and settings, then why not use their config program as well? I would
> > much rather be able to copy kmyfirewalls configuration from one machine
> > to another and then have the same firewall running on that machine. If
> > this would work across different unix types, then it would be an added
> > bonus, but i doubt that will happen :) I know this could be
> > accomplished while playing nice with the distros, but i can't help but
> > think it would be a maintanaince nightmare as things could easily
> > change with every new release of a distro
>
> Thanks thats exactely why i don't wanted to integrate it directely in the
> distributin specific stuff - they are changing to often and maintaining
> this will end up with my suicide :-)
> The way it's done is a general way that should work on all Linux systems.
> The user must decide if he like to use the distro specific tools or KMF -
> using both will allways endup in a mess.

In case of RedHat, the /etc/sysconfig/iptables is a text file formatted like 
this:

#[aaa:bbb] are packet counters, just leave them alone

*mangle
:PREROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
COMMIT

*nat
:PREROUTING ACCEPT [0:0]
:POSTROUTING DROP [0:0]
:OUTPUT ACCEPT [0:0]

### NAT pre forwarding
-A PREROUTING -p tcp -m tcp -d 213.36.220.213 --dport 0:8099 -j ACCEPT
-A PREROUTING -p tcp -m tcp -d 213.36.220.213 --dport 8170:65535 -j ACCEPT
# [...]

### NAT post forwarding
-A POSTROUTING -s 192.168.0.0/24 -d 213.36.220.213 -j ACCEPT
-A POSTROUTING -s 192.168.0.0/24 -j SNAT --to-source 213.36.220.213
COMMIT
# [...]

*filter
:INPUT ACCEPT [1680:124944]
:FORWARD ACCEPT [70:4176]
:OUTPUT ACCEPT [1074:114672]

### World UDP
# domain
-A INPUT -p udp -m udp -d 213.36.220.213 --dport 53 -i ppp+ -j ACCEPT
# joanna ntp
-A INPUT -p udp -m udp -s 213.36.220.214 -d 213.36.220.213 --dport 123 -i ppp+ 
-j ACCEPT
# priv'd ports
-A INPUT -p udp -m udp -d 213.36.220.213 --dport 0:1023 -i ppp+ -j REJECT
# unpriv'd ports
-A INPUT -p udp -m udp -d 213.36.220.213 --dport 1024:65535 -i ppp+ -j ACCEPT

# [...]

COMMIT

It's almost like a bash script invoking iptables, just that it doesn't 
replicate certain things (like iptables, table name) all over the place.

I don't think that having an option to import from/export to this file is such 
a hard thing to do. And this file's format stayed fixed since its inception, 
IIRC. Maybe the packet counters weren't present just after iptables were 
introduced in 7.0, but I think that's all that has changed.

Cheers, Kuba Ober
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic