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

Re: Why not have firewall rules by default?



William Twomey wrote:

If this is needed/wanted to Debian, no problems, but remember obscure isn't security. With fwbuilder, lokkit (Gnome), kmyfirewall (kde) etc is very easy made and maintain firewall/s at Linux and all of these are regular Debian packages. That is true at there should be more information about firewall possibilities example at http://www.debian.org/doc/manuals/securing-debian-howto/

I guess my point is if the 'iptables' package is installed by default on Debian, then better integration with Debian would probably be a good idea.

Why is iptables installed by default and why is there no debian way to load/save/unload the iptables rules without making your own init script? Why was the init script removed from Debian (security? no maintainer?)
Iptables is included to kernel and Debian offer i think all kernel facilities via modules their stock kernels.

Problem was at these init scripts were deprecated and maintainer don't want maintain them if i understand right. Check below historical document. Today Debian offer iptables, but no scripts. You find scripts example from fwbuilder package. I think at maintainers think at firewall is easy enough configure with graphical tools like fwbuilder and peoples read all fine manuals :)

Same issue is example selinux. It is installed, but disabled state and you should install some extra packages if you considered use it, but again selinux is part of kernel and enabled at default Debian kernel.

Firewall cannot protect you for everything. Consider that.

src    dst            protocol   action
any   your_host http          accept.

Attacker can now try attack you host and after successfully attack if your host have these kind of rule.

src             dst   protocol   action
your_host  any  http          accept.

Attacker can download malicious software with wget. This software made iptables -F and disabled your firewall. This is always problem desktop based machine. You don't like reject your surfing.

If your firewall have got only this rule.
src             dst                               protocol   action
your_host  security.debian.org   http          accept.

Now attacker cannot download malicious software and firewall stopped attack. This kind configuration isn't suitable for desktop, but for server.

Every time when you firewall rules have any (allow everything) parameter one of these src, dst or protocol and action is accept. That means it is possible at your rules aren't enough tight and your firewall is useless.

There is some historical info from http://ace-host.stuart.id.au/russell/files/debian/sarge/iptables/

This is old iptables-1.2.11/debian/README.Debian:

[ 1. upgrade notes ]
init scripts If you have upgraded from an earlier version of the iptables
     package, you may still have the deprecated init.d scripts and
     state information installed, but orphaned from the package.
     This was necessary to preserve existing configurations. Run
     "update-rc.d -f iptables remove" and delete this list of files
     and directories to get rid of it all:
/etc/default/iptables /etc/init.d/iptables /var/lib/iptables/
       /var/lib/ip6tables/
I'm certain someone will file a bug report about the orphaned
     files, but it was done intentionally. Suggestions for a better
     approach are welcomed.
owner module owner module support for kernels versions less than 2.4.20 was officially removed with the 1.2.9-7 upload. It was broken since at least 1.2.9-6. [ 2. quick start ] Here is a quick example of using ifupdown, possibly the simplest
   method of initiating a packet filtering script in Debian. This is
   an example of "auto" and "iface" stanzas in /etc/network/interfaces
   that run the a packet filtering script (with the interface
   name and address as arguments) before actually bringing up the
   interface.
auto eth0
     iface eth0 inet dhcp
       pre-up /etc/myfirewall.sh $IFACE $IF_ADDRESS
The next example uses inline calls to iptables to configure ip
   masquerading (basically, connection sharing) for a ppp or pppoe
   provider. This example is not intended to secure or anything.
auto ppp0
     iface ppp0 inet ppp
       provider bobsispchickenandribshack
       pre-up echo 1 > /proc/sys/net/ipv4/ip_forward
       pre-up iptables -t nat -A POSTROUTING -o $IFACE -j MASQUERADE
[ 3. running iptables ] There are a number of ways to "run" iptables in Debian. The
   closest to standard is the ipmasq package, which walks the
   user through a series of questions to produce a packet filter
   configuration.
Others may prefer packages like firehol, shorewall, firestarter,
   ipmenu, fireflier, ferm, firewall-easy, fwbuilder-iptables, fwctl,
   gfcc, lokkit, gnome-lokkit, guarddog, hlfl, knetfilter, mason,
   lokkit, easyfw, fiaif, filtergen, guidedog, or uif -- just to name
   some that are packaged for Debian, to configure maintain packet
   filtering rules.
Do-it-yourselfers may prefer any variety of self-written or
   acquired scripts to run at system startup. These are relatively
   easy to incorporate into Debian's SysV init tree by placing
   the executable script into /etc/init.d and applying it with
   update-rc.d, preferably at a level before any network interfaces
   are configured. (This example calls the script before network
   interfaces are enabled.):
update-rc.d myfirewall start 40 S . stop 89 0 6 . Some may prefer to use iptables-save and iptables-restore to save
   rule sets. The deprecated iptables init.d script in included in
   the example section as a reference for a state based init script.
   You can get the same basic functionality by using saving your
   rules with iptables-save and using ifupdown to apply them.
# sample /etc/network/interfaces lines
     pre-up iptables-restore < /etc/iptables.up.rules
     post-down iptables-restore < /etc/iptables.down.rules
One of the more powerful packet filter configurations is a number
   of scripts called through Debian's ifupdown system. Here is a
   brief introduction to ifupdown:
Debian uses ifupdown (see ifup(8), ifdown(8) and interfaces(5))
     to manipulate network interfaces. Each interface is provided
     with several scripting hooks: pre-up, up, down, and post-down.
     These hooks are available to each interface as in-line
     directives in /etc/network/interfaces and also as *.d/
     directories called with run-parts (see run-parts(8)):
/etc/network/if-up.d/
        /etc/network/if-pre-up.d/
        /etc/network/if-down.d/
        /etc/network/if-post-down.d/
There are a couple of caveats with the .d/ directories. They
     are run automatically when interfaces go up and down -- they
     are not the place to store arbitrary scripts. Also, run-parts
     runs all the scripts in those dirs, once for each interface that
     changes state. You can do something like this in shell scripts
     to prevent unwanted duplicate execution:
test "$IFACE"="eth0" || exit A useful set of variables are passed to the environment of
     the hooks with either the in-line directives or the *.d
     sub-directories. Here is a sample of such variables passed to a
     hook for eth0:
IFACE=eth0
        IF_ADDRESS=192.168.2.2
        IF_BROADCAST=192.168.2.255
        IF_GATEWAY=192.168.2.1
        IF_NETMASK=255.255.255.0
        IF_NETWORK=192.168.2.0




I like Debian because it don't tried install for me selinux, firewalls and all bells and whistles. This isn't sometimes remember at some distributions :) I can choose myself which is suitable for me.
I agree; not having all the bells and whistles is good, but having choice is good too. No one (I hope) is complaining that after install ssh/apache a file is put in /etc/init.d and /etc/rc2.d. Or that services are starting by default when you install them.

The fact that a debian machine connected to the internet is vulnerable to attacks that have build-in protection on Linux/iptables is strange to me. It would be nice to be able to enable these settings so they stay after a reset via apt or the install.

Regards, Riku

-Will



Regards, Riku


Reply to: