[lug] RH 7.x word of caution

[David Trowbridge]

I've found in my usage of iptables and custom kernel configurations that
it works best if you compile iptables as a module, but compile everything
else (targets and such) directly into the kernel. The targets are
remarkably small and it makes the whole thing quite a bit easier to
maintain.

Just a thought,
-David

-------------------
David Trowbridge
jupiter at flatirons.org
http://jupiter.babylonia.flatirons.org

"Base 8 is just like base 10 really...if you're missing two fingers"
	-Tom Lehrer

On Wed, 6 Jun 2001, D. Stimits wrote:

> Kevin Fenzi wrote:
> >
> > >>>>> "DStimits" == D Stimits <stimits at idcomm.com> writes:
> >
> > DStimits> Somehow failing to check the return value of something so
> > DStimits> significant reminds me of the story of a supertanker that
> > DStimits> went under and killed everyone onboard because a small
> > DStimits> personel hatch at the bow wasn't latched.
> >
> > indeed. It's pretty apparent that they don't expect most people to
> > upgrade the kernel they are using. The stock redhat kernel works fine
> > with the ipchains module. ;(
> >
> > DStimits> I'm having a hell of a time finding complete info on
> > DStimits> netfilter. The man pages, HOWTO, FAQ, kernel Documentation,
> > DStimits> so on, are all very incomplete.  One of my problems is that
> >
> > really? I found the netfilter-HOWTO to be pretty good.
> > Avaliable at
> > packetstorm.securify.com/UNIX/firewall/ipchains/netfilter/
> > (and other places).
> > Perhaps thats just me tho... :)
>
> I'll check it out. The HOWTO's I've found so far give only part of the
> required information; they lack, for example, exact information on
> modules to be compiled (possibly this is due in part to the 2.4.x
> kernels being a rapidly moving target). One source I found even failed
> to mention that the table needs to be specified...and it was a netfilter
> document.
>
> >
> > DStimits> apparently there is a different kernel module required for
> > DStimits> each change, DENY, one for REJECT (or is it DROP?), one for
> > DStimits> MASQ, so on. I have compiled with a ton of iptables modules
> > DStimits> enabled, but I cannot get the right module for DENY. The
> >
> > yeah, the netfilter stuff is set to be pretty modular. This allows you
> > to easily add things. However, the targets: ACCEPT, DROP, QUEUE, or
> > RETURN are all built into the ip_tables module.
>
> Much of my experimenting has been thwarted by iptables cussing at me for
> not having a module for a table. I am, at the moment, compiling a kernel
> with every single network option possibly related to iptables created as
> a module. As I figure it out, I will delete unused modules.
>
> >
> > DStimits> kernel Documentation/Configure.help does not give direct
> > DStimits> comments to say that a particular module is used for
> >
> > yeah, it's unclear on that.
> >
> > DStimits> DENY. Worse, some of the old ipchains functionality, it
> > DStimits> simply states it is now required to be downloaded
> > DStimits> separately...one can find this separate source, and even
> > DStimits> install it, but there is absolutely no useful documentation
> >
> > huh? what is required to be downloaded seperatly? cite?
>
> Kernel source tree, 2.4.5, Documentation/Changes:
> General changes
> ---------------
>
> The IP firewalling and NAT code has been replaced again.  The new
> netfilter software (including ipfwadm and ipchains backwards-
> compatible modules) is currently distributed separately.
> ...
> ...
> ...
> Netfilter
> ---------
> o  <http://netfilter.filewatcher.org/iptables-1.2.tar.bz2>
> o  <http://netfilter.samba.org/iptables-1.2.tar.bz2>
> o  <http://netfilter.kernelnotes.org/iptables-1.2.tar.bz2>
>
> NOTE: I downloaded and installed this. It lacks any real documentation,
> at least the version downloaded from filewatcher.org.
>
> Kernel source tree, 2.4.5, Documentation/Configure.help:
>   Various modules exist for netfilter which replace the previous
>   masquerading (ipmasqadm), packet filtering (ipchains), transparent
>   proxying, and portforwarding mechanisms. Please see
>   Documentation/Changes under "iptables" for the location of these
>   packages.
>
> Getting the source and detailed information about what it provides seem
> to be painfully separated.
>
> >
> > DStimits> after that...I fail to see how RH ever got the 2.4.2 kernel
> > DStimits> they use to work with ipchains. If using iptables -t filter,
> >
> > they load the 'ipchains' compatibility module. Then everything works
> > just like 2.2.x...
>
> My big question of the day...where can I get this module? It is
> apparently not part of the kernel source. I have a large set of very
> useful ipchains rules I'd love to operate until I get iptables figured
> out. This module would solve many problems for me, at least for a while.
>
> >
> > DStimits> some parts are very similar to ipchains, but when I try them
> > DStimits> and restart iptables, it does not work as expected (no
> > DStimits> denial or reject seems possible, but the machine at the
> > DStimits> other end gave error reports...the chain rule I tried did
> > DStimits> not block or drop, but it did mangle things to the point
> > DStimits> that xinetd had to be restarted on the other end).
> >
> > the sender had to restart? thats very weird. What was in your chain?
>
> The machine sending is what I tested a DENY for output. I simply denied
> TCP to telnet port 23 going out on the ethernet to an internal network
> machine. Prior telnets worked fine, once I did this in
> /etc/sysconfig/iptables (and restarted iptables):
> -A OUTPUT  -p tcp -s 0/0 -t filter -d 10.0.0.2/32 --dport 23 -o eth0 -j
> REJECT
>
> The result was, on the receiving machine at the other end, in
> /var/log/messages:
> xinetd[1064]: execv( /usr/sbin/in.telnetd ) failed: Bad address (errno =
> 14)
>
> >From that point, rebooting the machine that sent the attempt to login by
> telnet did not matter. I had to go to the other machine and run
> /etc/rc.d/init.d/xinetd restart. No more telnet connections would
> succeed till then.
>
> >
> > DStimits> I will look at freshmeat, but I would be very happy if
> > DStimits> someone here could tell me exactly what modules in the more
> > DStimits> recent kernels (I am using 2.4.5 with ac patches or 2.4.6
> > DStimits> pre1 at the moment...except when connected to the internet I
> > DStimits> must use 2.4.2) I need to do the following: ACCEPT REJECT
> > DStimits> DENY MASQ
> >
> > ACCEPT and DROP are builtin.
> > REJECT requires the ipt_REJECT.o module be loaded. (It should autoload
> > tho...you shouldn't have to do anything special except make sure it's
> > there).
> > MASQ is taken care of by the 'nat' table.
>
> Hmm. I wonder if I have built something in not as a module, and it is
> screaming because it thinks it must be a module. I'll have to do some
> kernel recompiling, I think something bogus is going on with what works
> or fails as a module/compiled-in combination.
>
> >
> > Perhaps a simple example would help?
>
> Yes! This is very much needed, thank you.
>
> >
> > ---cut---
> > #!/bin/sh
> > #
> > # flush all rules
> > #
> > /sbin/iptables -F INPUT
> > /sbin/iptables -F OUTPUT
> > /sbin/iptables -F FORWARD
> > /sbin/iptables -F POSTROUTING -t nat
> > /sbin/iptables -F PREROUTING -t nat
> > #
> > # allow all icmp through if it's for our machine
> > #
> > /sbin/iptables -A INPUT -p icmp -s 0/0 -d your-outside-ip -j ACCEPT
> > #
> > # allow ssh from outside
> > #
> > /sbin/iptables -A INPUT -p tcp -s 0/0 -d your-outside-ip --dport 22 -j ACCEPT
> > #
> > # masquerade internal machines
> > #
> > /sbin/iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
> > #
> > # redirect ssh into an internal machine
> > #
> > /sbin/iptables -t nat -A PREROUTING -p tcp -d your-outside-ip/32 --dport 22 -j DNAT --to-destination 10.1.1.1
> > #
> > # log and drop everything else.
> > #
> > /sbin/iptables -A INPUT -j LOG --log-prefix "DROPPING packet: "
> > /sbin/iptables -A INPUT -j DROP
>
> Excellent, this is better than the HOWTO I found so far (though I
> haven't browsed the one you mentioned yet).
>
> >
> > ---cut---
> >
> > DStimits> Next, can anyone tell me how to log? I see vague references
> > DStimits> to syslog.conf containing the log levels, but absolutely no
> > DStimits> samples. Is it not possible to create a rule that
> > DStimits> simultaneously REJECTs or DENYs, while logging? Does each
> > DStimits> log type also need its own kernel module?  Documentation
> > DStimits> totally sucks.
> >
> > you need to have a LOG target before the rule you are DROPing or
> > REJECTING. See above. ;)
> >
> > DStimits> Needless to say, I'm not having any fun yet.
> >
> > awwww...learning is fun! ;)
>
> Normally I'd agree. But when I saw ftp and telnet connect messages, and
> wondered why ipchains wasn't spitting out warnings first...then
> discovered bind and other ports had been tested also, for almost two
> weeks...possibly leaving both my new and old system invaded...it makes
> me unhappy. Things like persevering a 154 MB download of the XFS kernel
> source on a slow modem add to it when I think I may need to wipe out
> much of my system just to guarantee no break-ins (I keep current on most
> packages, but it makes my blood turn to ice when I see an unfirewalled
> pride-and-joy machine being hit while RH's scripts falsely tell me
> firewalling is active...the list of exploits is huge, and without a
> firewall, I really don't know what was hit).
>
> D. Stimits, stimits at idcomm.com
>
> >
> > DStimits> D. Stimits, stimits at idcomm.com
> >
> > kevin
> > _______________________________________________
> > Web Page:  http://lug.boulder.co.us
> > Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
>