[lug] RH 7.x word of caution

D. Stimits stimits at idcomm.com
Thu Jun 7 11:28:21 MDT 2001


David Trowbridge wrote:
> 
> 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.

As I get things figured out, I'll be saving an updated configuration for
the next kernel I compile. When I find out which components I need, I'll
try to do this.

D. Stimits, stimits at idcomm.com

> 
> 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
> >
> 
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug



More information about the LUG mailing list