[ale] ipchains in 2.4.13

Thu Jan 24 23:07:19 EST 2002

> From: James P. Kinney III [mailto:jkinney at localnetsolutions.com] 
> Sent: Wednesday, January 23, 2002 3:30 PM
> To: cfowler at outpostsentinel.com
> Cc: Atlanta Linux User Group (E-mail)
> Subject: Re: [ale] ipchains in 2.4.13

> Avoid setting up new uses of ipchains. It's no longer under development
> as it has been replaced with iptables. It was replaced because of
> several fundamental design flaws. iptables is HIGHLY recommended. The
> only reason to keep using ipchains is if the kernel won't support
> iptables. As iptables has been backported to 2.2 kernels for quite a
> while now, there is no excuse at all other than stubbornness. 

I don't see the facts to back up your claim that IP Tables has significant
advantages over IP Chains.

IP Tables does have a statefull capability, though poorly documented.
This means that if some random Internet system tries to send to your
client process without the client first sending a packet to the Internet
(or other system) then IP Tables tosses the packet.  This is its ONLY
real advantage over IP Chains but IP Tables is harder to use and much
more cumbersome.

The reality (IMO) is that this statefull capability is not all that useful
in a well designed Firewall and network.  Your servers (web, email,
public DNS, etc.) will be accepting connections from the world anyway
so the statefullness is of no value.  Your clients using TCP will use
both the packet sender's IP address and sequence number to toss bogus
packets from attackers.

The only commonly used UDP service generally allowed over the Internet is
DNS (port 53).  A carefully configured Firewall only will allow DNS to and
from one's ISP's DNS servers.  Thus the only to attack your systems via
DNS is by spoofing the ISP DNS servers' IP addresses.  While I've never
heard of this attack, no Firewall can protect against it.  If you have
a network of more than 10 systems or so then you should have your own
caching DNS server at the minimum and allow only it to hit your ISP's
DNS server.  Require your other internal systems to hit your internal
DNS server.  Use Linux for your DNS server and ensure that you use
named's -u and -g flags or similar functionality in *inetd.

Consider clients with poorly designed network stacks that neither
randomize TCP sequence numbers nor check that incoming packets have
a source address of the remote system that the TCP connection was
established with.  These would not be Linux or Unix but older Winbloz
systems may be vulnerable.  In this case IP Chains' lack of statefullness
might allow an unrelated IP on the Internet to hijack the connection,
though I suspect that this would be very unlikely.

IP Tables does allow one to block ICMP echo replies (type 0) inbound
unless recently there was an outgoing ICMP echo (type 8).  While this
would block a few Trojans from activating any zombies residing inside
your network, proper egress filtering would both prevent the zombies
from doing any harm and would detect their activation.  This this is a
very minor feature.

Actually, IP Chains has statefullness too.  That's what IP Masquerading
and the ip_masq* modules get you.  Btw, many of them did not compile
for IP Tables in RH7.1.  That brings me to the first disadvantage of
IP Tables.

IP Tables has not (IMO) passed from Beta to Production quality yet.

IP Tables has syntax and semantics that, while seeming very similar
to IP Chains, has deliberate (and really stupid IMO) incompatibilities
that make converting complex IP Chains rule sets a painful, error-prone,
time-consuming prospect.  The names and capitalizations of names such
as targets (what goes after -j) and "input", etc. change.

In IP Tables one must have separate rules for packets going to and from
the Firewall system itself than those being forwarded.  Why?  IP Chains'
"-i" flag to specify the interface, such as eth0, now means only if
inputted from the interface.  Since whether it's "input" or "output"
this is obvious it just makes for wasted debugging time.  True, it offers
slight capability for forwarded packets.  Big deal.

In IP Tables the order of parameters to the iptables command is important
due to an implementation detail and laziness on the part of the programmer
who wrote IP Tables.  IP Chains has no such limitation.

IP Chains allows you to set the timings for IP Masquerading of TCP
connections, UDP and ICMP pseudo connections, etc.  IP Tables compiles
fixed values into the kernel as naked constants (not even #define'ed)!
Sheesh.

If you are happy with IP Chains and don't need the 2.4 kernel or can
live with the 2.4 kernel's retrofitted IP Chains that has all of the
full 2.2 kernel's IP Chains functionality [except for port forwarding]
then stay with IP Chains.  If you need to convert for good reasons then
plan on spending lots of time and suffering.

Realistically, if one is so worried about having statefullness for added
security then plan on doing virus filtering first because that is a much
larger risk.

For those that still want "real" statefullness, get

     http://packetstorm.decepticons.org/linux/firewall/spf-2.0.3.tar.gz

and use with IP Chains.

> [Matt Kern] 
> What about if you need to vpn?  I haven't seen a patch to allow vpn yet
> (like ip_masq_pptp or ip_masq_ipsec)...or is it just plain not needed?
> That's all that's held me back...

IPSec is overkill designed by committee.

I use PPP on top of SSH as my preferred VPN solution for my clients.  It's
easy, works great, gets along fine with firewalls, and is easy to
configure.

> Once the
> (small) relearning curve is over, the rewards of easier maintenance of
> firewall rules, as well as capabilities that did not exist in ipchains,
> will be appreciated.

Bit learning curve for serious firewall rule sets.  My largest set is
2400 lines.

...
> -- 
> James P. Kinney III   \Changing the mobile computing world/
> President and COO      \          one Linux user         /
> Local Net Solutions,LLC \           at a time.          /
> 770-493-8244             \.___________________________./

> GPG ID: 829C6CA7 James P. Kinney III (M.S. Physics)
> <jkinney at localnetsolutions.com>
> Fingerprint = 3C9E 6366 54FC A3FE BA4D 0659 6190 ADC3 829C 6CA7 

Bob Toxen
transam at cavu.com                       [Bob's ALE Bulk email]
bob at cavu.com                           [Please use for email to me]
http://www.cavu.com                    [Network&Linux/Unix security consulting]
http://www.realworldlinuxsecurity.com/ [My 5* book:"Real World Linux Security"]
http://www.cavu.com/sunset.html        [Sunset Computer]
Fly-By-Day Consulting, Inc.      "Don't go with a fly-by-night outfit!"
Quality Linux & UNIX security and SysAdmin & software consulting since 1990.

GPG Public key available at http://www.cavu.com/pubkey.txt (book at cavu.com)
pub  1024D/E3A1C540 2000-06-21 Bob Toxen <book at cavu.com>
     Key fingerprint = 30BA AA0A 31DD B68B 47C9  601E 96D3 533D E3A1 C540
sub  2048g/03FFCCB9 2000-06-21

---
This message has been sent through the ALE general discussion list.
See http://www.ale.org/mailing-lists.shtml for more info. Problems should be 
sent to listmaster at ale dot org.