[ale] ipchains in 2.4.13
James P. Kinney III
jkinney at localnetsolutions.com
Fri Jan 25 07:40:39 EST 2002
OK. When the guru of practical linux security speaks, I've learned it's
a good idea to listen ;)
While I agree with everything that Bob noted, I must defend my statement
that iptables is superior to ipchains.
I based this opinion on two features of iptables missing in ipchains.
1. The structure of iptables is significantly clearer than ipchains.
Packets that are to be relayed traverse the forward chain only by
default. ipchains had relayed packets going through input, forward and
output. Input and output, for iptables, are only for packets destined
for the machine itself. That seems much clearer to me.
2. The mark function of iptables worked. I was unable to mark specified
packets in ipchains for specific routing needs.
I'm sure someone could explain how to mark packets in ipchains. But when
I emailed Rusty Russell, the chief architect of ipchains and iptables,
requesting a pointer as to how to make it work, his reply was to use
iptables for this, not ipchains. And it worked.
On Thu, 2002-01-24 at 23:07, Transam wrote:
> > 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.
>
> Portions not starting "> " are Copyright 2002 Fly-By-Day Consulting, Inc.
> All rights reserved. Posting on ALE and mirrors and repeaters granted.
>
> ...
> > --
> > 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.
>
--
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
This is a digitally signed message part
More information about the Ale
mailing list