* [gentoo-amd64] Re: KISS firewall not working on Gentoo Hardened
2007-10-04 0:49 [gentoo-amd64] KISS firewall not working on Gentoo Hardened P.V.Anthony
@ 2007-10-04 16:24 ` Duncan
2007-10-04 18:55 ` Sebastian Redl
2007-10-20 16:13 ` P.V.Anthony
0 siblings, 2 replies; 7+ messages in thread
From: Duncan @ 2007-10-04 16:24 UTC (permalink / raw
To: gentoo-amd64
"P.V.Anthony" <pvantony@singnet.com.sg> posted
470438AA.8040502@singnet.com.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@gentoo.org mailing list
^ permalink raw reply [flat|nested] 7+ messages in thread