[lug] RH 7.x word of caution
stimits at idcomm.com
Wed Jun 6 22:59:01 MDT 2001
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
> (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
> 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:
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.
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
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
The result was, on the receiving machine at the other end, in
xinetd: execv( /usr/sbin/in.telnetd ) failed: Bad address (errno =
More information about the LUG