Why not have firewall rules by default?

classic Classic list List threaded Threaded
31 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Why not have firewall rules by default?

William Twomey
It's my understanding (and experience) that a Debian system by default
is vulnerable to SYN flooding (at least when running services) and other
such mischeif. I was curious as to why tcp_syncookies (and similar
things) are not enabled by default.

Many distros (RPM-based mostly from my experience) ask you during the
install if you'd like to enable firewall protection. I was curious if
debian was every going to have this as an option?

One solution could be to have a folder called /etc/security/iptables
that contains files that get passed to iptables at startup (in the same
way /etc/rc2.d gets read in numeric order). So you could have files like
22ssh, 23ftp, etc. with iptable rules in each file. You could also have
an 'ENABLED' variable like some files in /etc/default have (so that
ports wouldn't be opened by default; the user would have to manually
enable them for the port to be opened).

 Then they'd just run /etc/init.d/iptables restart and the port would be
opened (flush the rules, reapply).

Even a central iptables-save format file that gets passed to iptables at
startup would be nice. It's easy enough to do manually, but would be
nice to see integrated with debian itself (packages managing their own
rules, etc.).

Is debian every going to introduce a better way of having iptables rules
be run at startup and easily saved/managed, or will this always be a
manual process?

Thanks!

-Will


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Why not have firewall rules by default?

Michael Loftis-2


--On January 23, 2008 9:19:01 AM -0600 William Twomey
<[hidden email]> wrote:

> It's my understanding (and experience) that a Debian system by default is
> vulnerable to SYN flooding (at least when running services) and other
> such mischeif. I was curious as to why tcp_syncookies (and similar
> things) are not enabled by default.

There was atleast at some point I believe evidence that some
platforms/firewalls didn't play well with SYN cookies.  I could be wrong.

> Many distros (RPM-based mostly from my experience) ask you during the
> install if you'd like to enable firewall protection. I was curious if
> debian was every going to have this as an option?

There are so many different choices of firewall management packages.
Shorewall is one I use, there are many others.  Some of which don't play
well with extra things that some users may use like wondershaper.  Debian
is still one of those distros that believes a little more in choice than
just pushing things down the users throat.

>
> One solution could be to have a folder called /etc/security/iptables that
> contains files that get passed to iptables at startup (in the same way
> /etc/rc2.d gets read in numeric order). So you could have files like
> 22ssh, 23ftp, etc. with iptable rules in each file. You could also have
> an 'ENABLED' variable like some files in /etc/default have (so that ports
> wouldn't be opened by default; the user would have to manually enable
> them for the port to be opened).
>  Then they'd just run /etc/init.d/iptables restart and the port would be
> opened (flush the rules, reapply).

It's better to leave the service disabled, or even better, completely
uninstalled from a security standpoint, and from a DoS standpoint as well.
The Linux kernel isn't very efficient at processing firewall rules.  Newer
kernels might be though (I honestly haven't looked as deeply into this in
late 2.6 as i did/do in 2.4...2.4 processes firewall rules strictly step by
step)

>
> Even a central iptables-save format file that gets passed to iptables at
> startup would be nice. It's easy enough to do manually, but would be nice
> to see integrated with debian itself (packages managing their own rules,
> etc.).

This much does exist.   invoke-rc.d iptables save --- i'm not sure what
package the /etc/init.d/iptables script is in, seems to me like it was part
of the same package that provided the binaries.

> Is debian every going to introduce a better way of having iptables rules
> be run at startup and easily saved/managed, or will this always be a
> manual process?

Probably not, as, in the distro, there's at least one good firewall
management utility, and probably more than one.  No need to reinvent the
wheel.



--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Why not have firewall rules by default?

Bugzilla from thomasdn@gmail.com
In reply to this post by William Twomey
On Jan 23, 2008 4:19 PM, William Twomey <[hidden email]> wrote:

> One solution could be to have a folder called /etc/security/iptables
> that contains files that get passed to iptables at startup (in the same
> way /etc/rc2.d gets read in numeric order). So you could have files like
> 22ssh, 23ftp, etc. with iptable rules in each file. You could also have
> an 'ENABLED' variable like some files in /etc/default have (so that
> ports wouldn't be opened by default; the user would have to manually
> enable them for the port to be opened).
>
>  Then they'd just run /etc/init.d/iptables restart and the port would be
> opened (flush the rules, reapply).

I think this would be a great feature!


--
Med venlig hilsen/Kind regards
Thomas Damgaard Nielsen
http://thomasdamgaard.dk


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Why not have firewall rules by default?

Rolf Kutz-2
In reply to this post by Michael Loftis-2
On 23/01/08 08:29 -0700, Michael Loftis wrote:
>
>It's better to leave the service disabled, or even better, completely
>uninstalled from a security standpoint, and from a DoS standpoint as well.
>The Linux kernel isn't very efficient at processing firewall rules.  Newer

I thought it was very efficient in doing so. YMMV.

>
>This much does exist.   invoke-rc.d iptables save --- i'm not sure what
>package the /etc/init.d/iptables script is in, seems to me like it was part
>of the same package that provided the binaries.

Didn't that get removed?

regards, Rolf
--
... But, conscience asks the question, 'Is it right?' ...


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Why not have firewall rules by default?

maximilian attems-9
In reply to this post by Michael Loftis-2
On Wed, Jan 23, 2008 at 08:29:25AM -0700, Michael Loftis wrote:
>
> It's better to leave the service disabled, or even better, completely
> uninstalled from a security standpoint, and from a DoS standpoint as well.
> The Linux kernel isn't very efficient at processing firewall rules.  Newer
> kernels might be though (I honestly haven't looked as deeply into this in
> late 2.6 as i did/do in 2.4...2.4 processes firewall rules strictly step by
> step)

baah any 2.4 info is terribly outdated these days
(beside not beeing supported on any modern distro).
it was already when 2.6.0 got released, but woow
for a better feeling of dev speed, check out git:

~/src/linux-2.6$ git diff --shortstat v2.6.22..v2.6.23
 7203 files changed, 406268 insertions(+), 339071 deletions(-)

2.6.24 is not yet released:
~/src/linux-2.6$ git diff --shortstat v2.6.23..
 10203 files changed, 775468 insertions(+), 482968 deletions(-)

--
maks


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Why not have firewall rules by default?

Riku Valli
In reply to this post by Rolf Kutz-2
Rolf Kutz wrote:

> On 23/01/08 08:29 -0700, Michael Loftis wrote:
>>
>> It's better to leave the service disabled, or even better, completely
>> uninstalled from a security standpoint, and from a DoS standpoint as
>> well. The Linux kernel isn't very efficient at processing firewall
>> rules.  Newer
>
> I thought it was very efficient in doing so. YMMV.
>
>>
>> This much does exist.   invoke-rc.d iptables save --- i'm not sure
>> what package the /etc/init.d/iptables script is in, seems to me like
>> it was part of the same package that provided the binaries.
>
> Didn't that get removed?
>
> regards, Rolf
Yes them were removed. I think at this is most right style today.
http://ace-host.stuart.id.au/russell/files/debian/sarge/iptables/

Cannot find original and seems at this info is removed from ..doc/iptables.

Debian haven't any open services by default, except portmapper and
behind portmapper aren't any services. So no need for host firewall.

If all services are allowed from host to anywhere firewall cannot do
nothing in case when host it compromised and is very difficult made
default rules for that. If user install example apache we need mechanism
which automatically allow connection/s  from outside to service/s. What
is different? Host without firewall and port 80 open or host with
firewall and rule which open port 80?


Regards, Riku


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Why not have firewall rules by default?

Ondrej Zajicek-3
In reply to this post by William Twomey
On Wed, Jan 23, 2008 at 09:19:01AM -0600, William Twomey wrote:
> One solution could be to have a folder called /etc/security/iptables
> that contains files that get passed to iptables at startup (in the same
> way /etc/rc2.d gets read in numeric order). So you could have files like
> 22ssh, 23ftp, etc. with iptable rules in each file.

This is IMHO nonsence. Why to firewall ports where nothing listens?
This would not give you anything.

> You could also have
> an 'ENABLED' variable like some files in /etc/default have (so that
> ports wouldn't be opened by default; the user would have to manually
> enable them for the port to be opened).

Better way is just not start that daemon.

--
Elen sila lumenn' omentielvo

Ondrej 'SanTiago' Zajicek (email: [hidden email], jabber: [hidden email])
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Why not have firewall rules by default?

Vincent Deffontaines-2
In reply to this post by Michael Loftis-2
Michael Loftis wrote:
[snip]
> It's better to leave the service disabled, or even better, completely
> uninstalled from a security standpoint, and from a DoS standpoint as
> well. The Linux kernel isn't very efficient at processing firewall
> rules.  Newer kernels might be though (I honestly haven't looked as
> deeply into this in late 2.6 as i did/do in 2.4...2.4 processes
> firewall rules strictly step by step)
The processing of Netfilter rules has not fundamentally changed from 2.4
to 2.6.
However, there is a way to load rules in a monilithic way, by using
iptables-restore, in place
of calling "iptables" multiple times. (IIRC, at some point in the past,
debian used that to save
rules at system shutdown and reload them at boot, but I may be wrong).

Vincent


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Why not have firewall rules by default?

Riku Valli
In reply to this post by Riku Valli
William Twomey wrote:

>
>> Debian haven't any open services by default, except portmapper and
>> behind portmapper aren't any services. So no need for host firewall.
> But isn't it reasonable to assume that most people will be installing
> services? Even a desktop user is likely to enable SSH and maybe even
> apache for convenience.  And I'm not asking for this to be mandatory;
> just an option during the initial install.
>>
>> If all services are allowed from host to anywhere firewall cannot do
>> nothing in case when host it compromised and is very difficult made
>> default rules for that. If user install example apache we need
>> mechanism which automatically allow connection/s  from outside to
>> service/s. What is different? Host without firewall and port 80 open
>> or host with firewall and rule which open port 80?
> It's less likely for the host to be compromised if it's behind a good
> firewall, don't you think?
Yes of course, but i think at perimeter firewall is for that expect you
really need tight server installation.

> For example, if only port 22 is allowed (after they install SSH) and
> they foolishly run a malicious program/script as root that creates a
> backdoor at some random portOr even restrict some outgoing ports
> (common rootkits, anything over port 1024 perhaps?)
>

If you restrict all over port 1024 you cannot use your computer :)

myhost:34873          otherhost:ssh         ESTABLISHED
otherhost:22            myhost:34873         ESTABLISHED


This is reason why use statefull inspection at perimeter firewall. It's
open high port/s related a allowed established connection and keep other
high port closed if you compare to old router's access list, only ports
< 1024 can filtered. Iptables have statefull capabilties.

http://www.checkpoint.com/products/downloads/Stateful_Inspection.pdf

If you have rootkit with root permissions it can disable your firewall
or connect with normal client software to anywhere. So in host firewall
you must restrict outside and inside port/s and this is nightmare
maintain at normal user desktop. Compare Windows Antivirus/Firewall
softwares and why it ask "This program tries connect to internet, allow
or deny". Yes many of Windows firewalls are packet filters ie. all high
ports open

Normally this kind systems are used only servers when needed really
tight security.

> A few prompts during the installation would be able to make a suitable
> firewall script for most users (and other users would choose not to
> use it).
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 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.

Regards, Riku
>>
>>
>
>


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Why not have firewall rules by default?

Rolf Kutz-2
In reply to this post by Riku Valli
On 23/01/08 18:48 +0200, Riku Valli wrote:
>
> Debian haven't any open services by default, except portmapper and behind
> portmapper aren't any services. So no need for host firewall.

Ack. I didn't want to argue pro a default
firewall.

regards, Rolf
--
...about the greatest democrazy in the world.

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Why not have firewall rules by default?

William Twomey
In reply to this post by Riku Valli

> 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?)

> 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.

-Will


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Why not have firewall rules by default?

Riku Valli
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


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Why not have firewall rules by default?

Riku Valli
In reply to this post by William Twomey
William Twomey wrote:
> It's my understanding (and experience) that a Debian system by default
> is vulnerable to SYN flooding (at least when running services) and
> other such mischeif. I was curious as to why tcp_syncookies (and
> similar things) are not enabled by default.
Sorry forgot that.

Submitted by admin <http://www.linuxinsight.com/user/1> on Thu,
2006-06-29 23:12.

Send out syncookies when the syn backlog queue of a socket overflows.
This is to prevent against the common "syn flood attack". Disabled (0)
by default.

Note, that syncookies is fallback facility. It must not be used to help
highly loaded servers to stand against legal connection rate. If you see
synflood warnings in your logs, but investigation shows that they occur
because of overload with legal connections, you should tune another
parameters until this warning disappear. See: tcp_max_syn_backlog
<http://www.linuxinsight.com/proc_sys_net_ipv4_tcp_max_syn_backlog.html>,
tcp_synack_retries
<http://www.linuxinsight.com/proc_sys_net_ipv4_tcp_synack_retries.html>,
tcp_abort_on_overflow
<http://www.linuxinsight.com/proc_sys_net_ipv4_tcp_abort_on_overflow.html>.

syncookies seriously violate TCP protocol, do not allow to use TCP
extensions, can result in serious degradation of some services (for
example SMTP relaying), visible not by you, but your clients and relays,
contacting you. While you see synflood warnings in logs not being really
flooded, your server is seriously misconfigured.

Regards, Riku


>
> Many distros (RPM-based mostly from my experience) ask you during the
> install if you'd like to enable firewall protection. I was curious if
> debian was every going to have this as an option?
>
> One solution could be to have a folder called /etc/security/iptables
> that contains files that get passed to iptables at startup (in the
> same way /etc/rc2.d gets read in numeric order). So you could have
> files like 22ssh, 23ftp, etc. with iptable rules in each file. You
> could also have an 'ENABLED' variable like some files in /etc/default
> have (so that ports wouldn't be opened by default; the user would have
> to manually enable them for the port to be opened).
> Then they'd just run /etc/init.d/iptables restart and the port would
> be opened (flush the rules, reapply).
>
> Even a central iptables-save format file that gets passed to iptables
> at startup would be nice. It's easy enough to do manually, but would
> be nice to see integrated with debian itself (packages managing their
> own rules, etc.).
>
> Is debian every going to introduce a better way of having iptables
> rules be run at startup and easily saved/managed, or will this always
> be a manual process?
>
> Thanks!
>
> -Will
>
>


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Why not have firewall rules by default?

Florian Weimer
In reply to this post by Ondrej Zajicek-3
* Ondrej Zajicek:

>> You could also have an 'ENABLED' variable like some files in
>> /etc/default have (so that ports wouldn't be opened by default; the
>> user would have to manually enable them for the port to be opened).
>
> Better way is just not start that daemon.

The daemon might have been installed by a package dependency, more or
less by accident.  Debian should have a policy that all daemons bind to
the loopback interface by default, but as long as this is not the case,
I can understand why people put paket filters on hosts as a safety net.

On the other hand, at this stage, it's very difficult for Debian as a
distribution to choose what firewall scripting framework should be used.
(But I don't think this is worth the effort.)


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Why not have firewall rules by default?

Maximilian Wilhelm
Am Wednesday, den 23 January hub Florian Weimer folgendes in die Tasten:

> * Ondrej Zajicek:

> >> You could also have an 'ENABLED' variable like some files in
> >> /etc/default have (so that ports wouldn't be opened by default; the
> >> user would have to manually enable them for the port to be opened).

> > Better way is just not start that daemon.

> The daemon might have been installed by a package dependency, more or
> less by accident.  Debian should have a policy that all daemons bind to
> the loopback interface by default, but as long as this is not the case,
> I can understand why people put paket filters on hosts as a safety net.

This might be a good idea, but on the other hand if you install packages
you should have a look what is installed and deactivate it or cut it of
the net if you don't want it.
IMO this is the task of the user/admin, not the distro.

> On the other hand, at this stage, it's very difficult for Debian as a
> distribution to choose what firewall scripting framework should be used.
> (But I don't think this is worth the effort.)

ACK
I think this kind of preseeded firewall would be the first thing
experienced users would kick away as it most probably would be
annoying for them.

Ciao
Max
--
        Follow the white penguin.


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Why not have firewall rules by default?

shupej
In reply to this post by Florian Weimer
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I believe Debian's method of handling iptables is perfect. if-up.d and its
counterparts provide a great means for scripting complex firewall sets.

For example, I have written a perl script that parses a custom config file
that defines certain IPs and ports and defines/enables a ruleset
automatically when the interface is brought up.

To maintain an iptables-save ruleset would be much more complex than
writing a one time script and editing a configuration file. It can, of
course, be argued that you can write custom scripts and run then via other
methods, but the way that Debian handles networking scripts creates a
warmer invite for this and simplifies this sort of thing.

On Wed, January 23, 2008 5:22 pm, Florian Weimer wrote:

> * Ondrej Zajicek:
>
>>> You could also have an 'ENABLED' variable like some files in
>>> /etc/default have (so that ports wouldn't be opened by default; the
>>> user would have to manually enable them for the port to be opened).
>>
>> Better way is just not start that daemon.
>
> The daemon might have been installed by a package dependency, more or
> less by accident.  Debian should have a policy that all daemons bind to
> the loopback interface by default, but as long as this is not the case,
> I can understand why people put paket filters on hosts as a safety net.
>
> On the other hand, at this stage, it's very difficult for Debian as a
> distribution to choose what firewall scripting framework should be used.
> (But I don't think this is worth the effort.)
>
>
> --
> To UNSUBSCRIBE, email to [hidden email]
> with a subject of "unsubscribe". Trouble? Contact
> [hidden email]
>
>


- --
James Shupe
HermeTek Network Solutions
http://www.hermetek.com
1.866.325.6207

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iEYEARECAAYFAkeXyKMACgkQVwQZh6k43zooKgCdH4cGLKe5VNd5gqWzwUjqO0fj
/NYAoNhVw5dGC09NH7GbzSUp9xtrZTYC
=AVJo
-----END PGP SIGNATURE-----


----------------------------------------------------------------------

This Email is covered by the Electronic Communications Privacy Act,
18 U.S.C. 2510-2521 and is legally privileged. The information
contained in this Email is intended only for use of the individual
or entity named above. If the reader of this message is not the intended
recipient, or the employee or agent responsible to deliver it to the
intended recipient, you are hereby notified that any dissemination,
distribution or copying of this communication is strictly prohibited.
If you have received this communication in error, please immediately
notify us by telephone 1.866.325.6207 and destroy the original message.


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Why not have firewall rules by default?

Russ Allbery-2
In reply to this post by Florian Weimer
Florian Weimer <[hidden email]> writes:

> The daemon might have been installed by a package dependency, more or
> less by accident.  Debian should have a policy that all daemons bind to
> the loopback interface by default, but as long as this is not the case,
> I can understand why people put paket filters on hosts as a safety net.

This would be a rather silly policy to have for, say, a Kerberos KDC or an
LDAP server.  The normal installation for such packages is on servers, and
defaulting to not providing the service just makes the administrator jump
through unnecessary hoops and isn't consistent with the idea that
installation should result in a working package.

--
Russ Allbery ([hidden email])               <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Why not have firewall rules by default?

Brent Clark-3
In reply to this post by shupej
Hi

Little something on the side, while its in my mind.

If there was anything i would like to see, that is more of the netfilters patch o matic's available in the kernel.

Hence, less need to wget patch o matic and to follow the process. Its not a big task, but still, total time waster.

Anyway, know this will fall on deaf ears. so keep cool.

Regards and all the best.
Brent Clark


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Why not have firewall rules by default?

Henrique de Moraes Holschuh
In reply to this post by Rolf Kutz-2
On Wed, 23 Jan 2008, Rolf Kutz wrote:
> On 23/01/08 08:29 -0700, Michael Loftis wrote:
>> It's better to leave the service disabled, or even better, completely  
>> uninstalled from a security standpoint, and from a DoS standpoint as
>> well. The Linux kernel isn't very efficient at processing firewall
>> rules.  Newer
>
> I thought it was very efficient in doing so. YMMV.

Quite the contrary. It is *dog* *slow* for non-trivial firewalls.  You have
to use a number of tricks to optimize the rule walk (many tables, hashing,
etc), and anything that reduces the number of rules (like IPSet) is a major
performance bonus.

Or you can rip the standard netfilter firewall out, and install a
high-performance one (such as HiPAC), but those are mostly unmaintained
these days, and have a lot less features than the standard one.

You need to be doing some *heavy* firewalling (many rules) for any of that
to really matter, and on very fast links (gigabit) because nobody will
notice the firewall's speed on something as a 10Mbit/s link...

--
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Why not have firewall rules by default?

Török Edwin
Henrique de Moraes Holschuh wrote:

> On Wed, 23 Jan 2008, Rolf Kutz wrote:
>  
>> On 23/01/08 08:29 -0700, Michael Loftis wrote:
>>    
>>> It's better to leave the service disabled, or even better, completely  
>>> uninstalled from a security standpoint, and from a DoS standpoint as
>>> well. The Linux kernel isn't very efficient at processing firewall
>>> rules.  Newer
>>>      
>> I thought it was very efficient in doing so. YMMV.
>>    
>
> Quite the contrary. It is *dog* *slow* for non-trivial firewalls.  You have
> to use a number of tricks to optimize the rule walk (many tables, hashing,
> etc), and anything that reduces the number of rules (like IPSet) is a major
> performance bonus.
>  

Are you referring to 2.4 or 2.6 kernel?
If it is 2.6, I suggest you to contact the netfilter mailing list [1],
and show them your firewall rules,
with speed measurements on real workload.
I'm sure they will try to optimize the kernel, if it turns out to be a
bottleneck in the kernel.

[1] http://vger.kernel.org/vger-lists.html#netfilter

Best regards,
--Edwin


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

12