[gentoo-amd64] Re: KISS firewall not working on Gentoo Hardened

[Duncan]

"P.V.Anthony" <pvantony@×××××××××××.sg> posted
470438AA.8040502@×××××××××××.sg, excerpted below, on  Thu, 04 Oct 2007
08:49:46 +0800:

> I was trying to get the KISS firewall working on Gentoo Hardened amd64.
>
> The firewall script is from the following,
> http://www.geocities.com/steve93138/
>
> I am not at all good with firewalls. That is why I am using this KISS
> script.
>
> Have emerged iptables. Currently using kernel version 2.6.22 from the
> gentoo hardened sources.
>
> Searched google and found no good solution.
>
> It seems that the kernel modules are different for some kernels
> versions.
>
> Cannot find the ipt_unclean module. Tried compiling all the modules
> under Network.
>
> If there are any links, please share them. Or better please help with
> advice.

First a direct answer, then my experience/opinion, FWIW.

Direct answer:  With a bit of googling, I found the following:

http://www.groupsrv.com/linux/about16735.html

The gist of it is that the ipt_unclean module was always considered 
experimental and not recommended by the IPTables folks, and was removed 
shortly before kernel 2.6.0, due to conflict with header usage for IETF 
network congestion notification.

It's also worth noting that it was never entirely free of problems -- 
race conditions and the like -- thus its constant "experimental" status 
even while it existed.  At one point, and the first page of the google 
results for it was full of hits on this, it was actually locking up the 
kernel.  Thus, while it was /intended/ to filter unclean packets, it was 
always considered iffy at best and was not recommended, since the cure 
was effectively worse than the disease!

Obviously, given the above, it's not something you'd want on in any case 
-- unless you were someone experimenting with it, thus the "experimental" 
label.

So that answer your question... you won't find that module per se in a 
2.6 kernel, and since it was removed before 2.6.0, any kind of firewall 
script you find that still references it is either for 2.4 kernels only 
(and then either specifically for folks experimenting, or by someone who 
obviously didn't know what he was doing), or hopelessly outdated at this 
point.  IOW, anything that references it without some sort of HUGE 
warning... isn't something I'd be trusting in the first place.

... Which brings me to the second part of this post, some "advice" since 
you asked for it, based on my own experience.  Obviously, this part is 
opinion only.  Feel free to treat it as worth what you are paying for it 
(nothing). =8^)

Personally, I tried a number of different firewall scripts, but wasn't 
really satisfied with any of them.  Most of them tried to do too much -- 
they had all sorts of config options for configuring big commercial 
networks, options for shutting off net access to a specific segment of 
the internal network at a specific time, for instance.  I didn't /need/ 
that sort of complex configuration, and it only made things more 
confusing, not less.

At the same time, stuff that should have been simple ended up hugely 
complex.  I was never sure which modules I needed for which options, and 
since I was configuring scripts that did the actual configuring of the 
IPTables based firewall, when something didn't work, I was never quite 
sure whether it was the script, or a bug in the kernel, or a missing 
module, or my mistake, or...  Well, I'm sure you can identify right about 
now! =8^(

So I decided that just wasn't going to work, and for several years I just 
depended on a NAPT based router (which I had bought when I was back on 
MSWormOS) to do my firewalling.  It was relatively simple, but had 
documentation, actually worked according to it, and did the job I needed 
done.

However, that router was an old generation 1.5 Netgear, limited to 10Mbit 
Ethernet on the WAN port, with actual thruput limited to about 6.5 Mbps.  
When my Internet connection was upped to 7Mbps, the router became the 
bottleneck, and I realized I either needed to buy a new one or quit 
putting off learning IPTables the /right/ way.

I learned IPTables directly.  As I expected, it was /much/ simpler than 
the scripts /ever/ were.  This is particularly true for Gentoo users 
already accustomed to running emerges and doing various other sysadmin 
tasks from a CLI, as opposed to doing everything from a GUI, and who 
already configure and compile their own kernel and don't run screaming 
when someone mentions the very idea of doing so in ordered to get a 
specific netfilter module.  Arguably, the scripts /could/ be better for 
folks used to running a distribution's precompiled binary kernel, with 
all its precompiled modules, who as I said run screaming at the very idea 
of compiling their own, tho I never found it so (I was on Mandrake back 
when I first tried, altho I must say I learned to compile my own kernel, 
even if it was from Mandrake sources, pretty early on), but my opinion is 
that most Gentoo users will be better served learning IPTables directly.  
It's NOT that hard, and as I said, I actually found it /vastly/ simpler 
than trying to figure out all those indirect scripts and the like.  YMMV 
of course...

So, assuming I've convinced you and you want to learn IPTables itself, 
what's an easy way to start?  Well, one way's to merge the iptables 
package and then read the iptables manpage.  From my experience, even 
that would be on par with trying to run those stupid supposedly "simple" 
firewall configuration scripts, but I'd call that "intermediate".  That 
works best after you have your bearings and know the basics.  There are 
easier ways to start.

You said firewall, but didn't mention whether you are more interested in 
running a firewall protecting a standalone machine, or whether you really 
had in mind a dedicated firewall machine, protecting a whole LAN worth of 
machines (tho that might be only one) behind it.

My case is the first, a firewall protecting a standalone machine, and in 
any event, as long as you have direct console access to your firewall, 
it's easiest to start there, and deal with the forwarding later, after 
you learn the basics.  If you are logging into your firewall machine over 
the LAN and don't have any direct console access, you do of course need 
to be careful you don't block your own command connection.  That's 
possible, but to keep things simple, the below assumes a direct console 
connection. 

For the Gentoo user especially, the simplest and most direct guide is the 
one DRobbins himself wrote for IBM developerWorks, back for kernel 2.4, 
but still useful today, and now hosted on the Gentoo infrastructure and 
listed in the main docs list.

http://www.gentoo.org/doc/en/articles/linux-24-stateful-fw-design.xml

Courtesy of some googling, here are some more paralleling that (links may 
wrap):

David Mair's very basic firewall protecting a standalone machine version:

http://www.cyberciti.biz/tips/how-do-i-build-a-simple-linux-firewall-for-
dsldial-up-connection.html

Here's another David Mair link, this one for a dedicated firewall 
protecting a LAN:

http://www.novell.com/coolsolutions/feature/18139.html

Another useful one.  As the DRobbins tutorial, it starts with a simple 
single standalone machine firewall and gets more complex from there:

http://wiki.centos.org/HowTos/Network/IPTables

If you are doing a dedicated router, Gentoo has a guide specifically for 
that, too.  In addition to firewalling and routing, it covers setting up 
additional stuff such as mail/web/ntp servers and the like, that you may 
wish to host on your firewall/router machine.
 
http://www.gentoo.org/doc/en/home-router-howto.xml

OK, here's the official netfilter site tutorial list, but unfortunately, 
it seems like it isn't kept up to date, and some of the links are dead-
ends.  Many of the others don't seem real appropriate, but I'll list a 
few of the more useful ones below:

http://www.netfilter.org/documentation/index.html#documentation-tutorials

The first one, IPTables Tutorial by Oskar Andreasson, may be useful if 
you don't know much about the basics of TCP/IP, and want to get a general 
orientation on that, with IPTables in mind, before you get to doing stuff 
with IPTables itself.

Down the list a way, there's Netfilter tutorial, by crhalpin.  It has a 
nice example at the end, specifically for a firewall/NAT box, thus it 
should be most useful for that, but it has a couple rather useful hints 
sections, "Tips and Style Issues", and "Common Mistakes (or Don't Follow 
in my Footsteps)".

The last three links on that official tutorials list are to 
professionally written magazine articles, by David Coulson.  The links 
are to the PDFs as taken straight from the magazines, so if you like nice 
glossy magazine layouts, these are likely to be right down your alley! 
=8^)

OK, some misc. discussion and additional links:

Useful info if you run bittorrent, by Vivek:

http://www.cyberciti.biz/tips/linux-iptables-open-bittorrent-tcp-
ports-6881-to-6889.html

For Gentoo, the in-tree iptables package places the iptables initscript 
in the usual place, /etc/init.d, with its config likewise in the usual 
place, /etc/conf.d.  Many of the above links use scripts to setup and 
take down their iptables setup, but Gentoo naturally already has that 
covered.  Once you get the running iptables setup the way you wish, 
configure /etc/conf.d/iptables, then run 

/etc/init.d/iptables save

to save your setup to the configured location.  FWIW, I decided I wanted 
mine in /etc/iptables.rules instead of the default /var location, but 
that of course is up to you. 

Particularly if you turned on the SAVE_ON_STOP option, you may wish to 
make it a point of backing up your useful config every time you change 
it, just to be sure your specific config you worked so hard to setup 
isn't accidentally overwritten by a non-working config if you change it.  
I like to use dates on my backups so I know when they were made, so along 
with my rules in /etc, I have a backup iptables.rules.20070731 (the last 
date I tweaked it) as well.

Once you have your config saved, you will want to add the iptables 
service to the appropriate runlevel, in boot if your network starts 
there, or in default if there.  It'll start before the network if it's in 
the appropriate level.  You can add it to nonetwork if you wish as well 
-- it won't harm anything, and will activate on any network interfaces as 
they are brought up if you start networking manually that way.

FWIW, in addition to the "save" action and the normal start/stop/restart/
zap type actions, Gentoo's iptables initscript has two additional 
actions, "reload", to reload the saved config, and "panic", which I've 
never used but appears to shut down all net access immediately, 
accomplished by setting everything to immediate drop.  (I'd be more 
inclined to unplug my cable modem in that situation, thus my not feeling 
the need to investigate the panic function, but it's useful to know it's 
there anyway.)

There are two commands to display active rules.  iptables -L lists them 
in one format, iptables-save, which outputs to STDOUT thus to the 
terminal if not redirected to a file, lists them in a somewhat different 
format.  iptables -L is perhaps more useful as an overview as it's more 
tabular and less cluttered, but the output of iptables-save is much 
closer to the command line parameters actually entered to create the 
rules.  Thus, iptables-save tends to be more useful when actually 
creating and deleting rules, or anyway I certainly found it so.

Finally, in addition to the stuff covered in the tutorials above, there 
are a few additional rules general and useful enough to mention here.

First, if your ISP (as mine) uses DHCP, you'll want to add a rule 
allowing that, since it won't be covered by the usual established,related 
rule because the connection is just being setup at that point.  After 
reading the tutorials above and referencing the iptables manpage if 
necessary, this should make enough sense that you can setup your own rule 
for it reasonably easily.  DHCP is an extension of bootp, and uses the 
same ports, udp ports 67 and 68.  Incoming, you'll want a rule allowing 
udp sport 67, dport 68.  The outgoing rule if you need one (basic setups 
normally allow outgoing by default, in which case you probably don't) 
would be the reverse, udp sport 68, dport 67.

Additionally, I found that while I wanted to log most traffic before it 
was dropped, I wanted to limit the logging rate so it wouldn't use up all 
the space on my log partition if I got attacked, and there were a few 
things, like messenger spam (udp dport 1026-1031 inbound) that were SO 
common it wasn't worth logging at all.  I accomplished this by setting up 
a logging chain, adding a rule to the end of the input chain (after all 
my normal allows) to jump to the logging chain.  The rules in this 
logging chain then drop anything (like udp dport 1026-1031 as mentioned 
above) I consider too common to log, with the last rule in the logging 
chain a rate-limited logging rule.  Processing then returns to the input 
chain, which having no additional rules (the one invoking the logging 
chain being the last one) and a DROP policy, then drops any remaining 
packets.

As the logging paragraph above indicates, I found it useful to create a 
few chains beyond the default INPUT/OUTPUT/FORWARD.  Specifically, I have 
(for input):

in-except, for exceptions to the following,
in-allow, for explicit allow rules,
in-log, to drop the real common stuff and log whatever has fallen thru.

The default INPUT chain with a default DROP policy then consists of three 
simple rules jumping to the above three input chains in order, as follows 
(format is as output by iptables-save):

-A INPUT -j in-except
-A INPUT -j in-allow
-A INPUT -j in-log

in-exceptions is currently empty, but from previous experience I've found 
it useful to have.  It comes in handy if I want to block packets from a 
specific IP or something that would otherwise be allowed.

in-allow has the following three rules:

-A in-allow -m state --state RELATED,ESTABLISHED -j ACCEPT
-A in-allow -i lo -j ACCEPT
-A in-allow -p udp -m udp --sport 67 --dport 68 -j ACCEPT

The related/established one should be well covered in the tutorials.  I 
allow everything from the localhost loopback interface, and as discussed 
above, I allow DHCP packets.  (The DHCP rule could be tightened down 
somewhat if necessary, but this works and is reasonably limited, 
considering the dhcp client only has the port open a limited time when it 
leases or renews the IP.)

in-log also has three rules, as follows:

-A in-log -i eth0 -p icmp -m icmp --icmp-type 8/0 -j DROP
-A in-log -i eth0 -p udp -m udp --dport 1026:1031 -j DROP
-A in-log -m limit --limit 20/hour -j LOG --log-prefix "IPTables:"

ICMP type 8/0 is ICMP echo, aka "ping", ICMP implementation.  I choose to 
drop this, and to do so before logging.  The second entry is the 
messenger spam entry I mentioned above, since the things otherwise fill 
my logs.  The third is the logging entry itself, using the default burst 
level of (IIRC) five, then limited to one every three minutes.

Since this is a stand-alone machine, I don't have to worry about 
forwarding so it's simply a default DROP policy. I don't have a reason to 
filter output, so it's simply a default ACCEPT policy.  Thus, similar to 
a NAPT based router, the only filtering I'm doing is on incoming packets, 
and generally limited to related/established, with a limited set of 
exceptions, and everything else rate-limit logged, again with a limited 
set of too-common exceptions, before dropping.

The entire set, again as output from iptables-save, is as follows (packet/
byte stats where displayed xxed out):

# Generated by iptables-save v1.3.8 on Thu Oct  4 07:00:23 2007
*filter
:INPUT DROP [xxx:xxx]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [xxx:xxx]
:in-allow - [0:0]
:in-except - [0:0]
:in-log - [0:0]
-A INPUT -j in-except
-A INPUT -j in-allow
-A INPUT -j in-log
-A in-allow -m state --state RELATED,ESTABLISHED -j ACCEPT
-A in-allow -i lo -j ACCEPT
-A in-allow -p udp -m udp --sport 67 --dport 68 -j ACCEPT
-A in-log -i eth0 -p icmp -m icmp --icmp-type 8/0 -j DROP
-A in-log -i eth0 -p udp -m udp --dport 1026:1031 -j DROP
-A in-log -m limit --limit 20/hour -j LOG --log-prefix "IPTables:"
COMMIT
# Completed on Thu Oct  4 07:00:23 2007

To enable that and provide a bit of additional flexibility, I have the 
following related kernel config items enabled (I prefer builtin for 
regularly used stuff, so most of these are =y here, but some can be 
modularized, =m, if desired):

#General netfilter option, under Networking > Networking Options
CONFIG_NETFILTER
# Under that...

# ... Under Core Netfilter Configuration

# Netfilter connection tracking support
CONFIG_NF_CONNTRACK_ENABLED
# FTP protocol support
CONFIG_NF_CONNTRACK_FTP
# Netfilter Xtables support
CONFIG_NETFILTER_XTABLES
# "NFLOG" target support
CONFIG_NETFILTER_XT_TARGET_NFLOG
# "helper" match support
CONFIG_NETFILTER_XT_MATCH_HELPER
# "limit" match support
CONFIG_NETFILTER_XT_MATCH_LIMIT
# Multiple port match support
CONFIG_NETFILTER_XT_MATCH_MULTIPORT
# "pkttype" packet type match support
CONFIG_NETFILTER_XT_MATCH_PKTTYPE
# "state" match support
CONFIG_NETFILTER_XT_MATCH_STATE

# ... Under IP: Netfilter Configuration

# IPv4 connection tracking support (required for NAT)
CONFIG_NF_CONNTRACK_IPV4
# IP tables support (required for filtering/masq/NAT)
CONFIG_IP_NF_IPTABLES
# IP range match support
CONFIG_IP_NF_MATCH_IPRANGE
# Owner match support
CONFIG_IP_NF_MATCH_OWNER
# Packet filtering
CONFIG_IP_NF_FILTER
# REJECT target support
CONFIG_IP_NF_TARGET_REJECT
# LOG target support
CONFIG_IP_NF_TARGET_LOG

All the other Netfilter related kernel options are off.

Hope that's all useful, if not to you then to someone, as it took me 
quite some time to compose it! =8^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@g.o mailing list