[lug] RH 7.x word of caution

[D. Stimits]

kevin at scrye.com wrote:
> 
> >>>>> "DStimits" == D Stimits <stimits at idcomm.com> writes:
> 
> DStimits> Much of my experimenting has been thwarted by iptables
> DStimits> cussing at me for not having a module for a table. I am, at
> DStimits> the moment, compiling a kernel with every single network
> DStimits> option possibly related to iptables created as a module. As
> DStimits> I figure it out, I will delete unused modules.
> 
> yeah...thats the way to go. netfilter is kinda setup to be all modules...
> 
> >> huh? what is required to be downloaded seperatly? cite?
> 
> DStimits> Kernel source tree, 2.4.5, Documentation/Changes: General
> DStimits> changes ---------------
> 
> DStimits> The IP firewalling and NAT code has been replaced again.
> DStimits> The new netfilter software (including ipfwadm and ipchains
> DStimits> backwards- compatible modules) is currently distributed
> DStimits> separately.  ...  ...  ...  Netfilter --------- o
> DStimits> <http://netfilter.filewatcher.org/iptables-1.2.tar.bz2> o
> DStimits> <http://netfilter.samba.org/iptables-1.2.tar.bz2> o
> DStimits> <http://netfilter.kernelnotes.org/iptables-1.2.tar.bz2>
> 
> DStimits> NOTE: I downloaded and installed this. It lacks any real
> DStimits> documentation, at least the version downloaded from
> DStimits> filewatcher.org.
> 
> ah...yeah, you need the 'iptables' command for userspace. Just like
> you need ipchains or ipfwadm. This is only the tool that lets you set
> rules. It can't really be a part of the kernel.

Ok, I already had the command for userspace from the original Redhat
install, so maybe I didn't actually do much by running the install I
found (except possibly screwing up rpm). This is one of those things I
wish I had found documentation on...or at least more or better docs.

> 
> >> they load the 'ipchains' compatibility module. Then everything
> >> works just like 2.2.x...
> 
> DStimits> My big question of the day...where can I get this module? It
> DStimits> is apparently not part of the kernel source. I have a large
> DStimits> set of very useful ipchains rules I'd love to operate until
> DStimits> I get iptables figured out. This module would solve many
> DStimits> problems for me, at least for a while.
> 
> Yes, it is part of the standard kernel. It's:
> 
> CONFIG_IP_NF_COMPAT_IPCHAINS
> ipchains (2.2-style) support
> CONFIG_IP_NF_COMPAT_IPCHAINS
>   This option places ipchains (with masquerading and redirection
>   support) back into the kernel, using the new netfilter
>   infrastructure.  It is not recommended for new installations (see
>   `Packet filtering').  With this enabled, you should be able to use
>   the ipchains tool exactly as in 2.2 kernels.
> 
>   If you want to compile it as a module, say M here and read
>   Documentation/modules.txt.  If unsure, say `N'.
> 
> If you built iptables or ipfwadm into the kernel, you won't see this
> one. You can only have one at a time. You can build them all as
> modules tho...when you load the ipchains module, everything will work
> like you are on a 2.2.x kernel with ipchains.

I never use ipfwadm. Back in the 2.2.x kernel series, I did not
firewall; I became an early adopter of the 2.3.x series and ran ipchains
before ever touching ipfwadm.

The interesting thing is I cannot find the
"CONFIG_IP_NF_COMPAT_IPCHAINS" anywhere in any of my config files. This
might sound like I did not select it, but the way the config files work
is that unused options are commented out and to the right it appends "is
not set". The option is completely missing, not merely unset. I'll have
to investigate why I can't find it (these configs are from the
non-Redhat kernels though, I am wondering if this config item is patch
added). The kernels I am testing with so far range from earlier 2.4.3
and 2.4.4 testing (only a few times), and a LOT of 2.4.5 variations
(mostly Alan Cox's ac patches, plus SGI versions with XFS filesystem). I
will be able to at least now track down exactly which config option in
kernel compile is supposed to have this set.

> 
> >> the sender had to restart? thats very weird. What was in your
> >> chain?
> 
> DStimits> The machine sending is what I tested a DENY for output. I
> DStimits> simply denied TCP to telnet port 23 going out on the
> DStimits> ethernet to an internal network machine. Prior telnets
> DStimits> worked fine, once I did this in /etc/sysconfig/iptables (and
> DStimits> restarted iptables): -A OUTPUT -p tcp -s 0/0 -t filter -d
> DStimits> 10.0.0.2/32 --dport 23 -o eth0 -j REJECT
> 
> DStimits> The result was, on the receiving machine at the other end,
> DStimits> in /var/log/messages: xinetd[1064]: execv(
> DStimits> /usr/sbin/in.telnetd ) failed: Bad address (errno = 14)
> 
> DStimits> From that point, rebooting the machine that sent the attempt
> DStimits> to login by telnet did not matter. I had to go to the other
> DStimits> machine and run /etc/rc.d/init.d/xinetd restart. No more
> DStimits> telnet connections would succeed till then.
> 
> humm...a telnetd or xinetd bug sounds like. It should respawn that
> command on the next attempt. ;(

Yes, I think it was a real bug. I'll have to look into it at a later
date though. Incidentally, in the /var/log/messages, each time xinetd
spawns and logs a message, its pid is given...each spawned log message
did increment pid, so the spawned process was occurring as it should. I
would guess that an argument to parent (which in reality includes
environment variables) was the problem, rather than failing to spawn.

D. Stimits, stimits at idcomm.com

> 
> kevin
> --
> Kevin Fenzi
> MTS, tummy.com, ltd.
> http://www.tummy.com/  KRUD - Kevin's Red Hat Uber Distribution
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug