[ale] ipchains in 2.4.13

[Transam]

> On Fri, Jan 25, 2002 at 04:54:24PM -0500, Transam wrote:
> > > iptables -A FORWARD -p tcp -m state --state RELATED,ESTABLISHED -j ACCEPT
> > 
> > This rule suggests that SSH is allowed both in and out so a single rule
> > allowing this in IP Chains would have equivalent security.  I don't see
> > your 100 vs. 1 rule.

> When you only have a couple of hosts with one or two ports open, then
> the savings is insignificant.

You had claimed a 100 vs. 1 for the number of rules required between
IP Chains and IP Tables and I had asked you for an example as a point for
analysis because I looked at your claim.

> > True.  What problem are you trying to solve (i.e., protecting a server
> > in the DMZ or a client in an IP Masqueraded network, etc.)?  If you can
> > provide an example of a situation where you see a difference in security
> > or ease of configuration I'll be happy to provide concrete responses.

> All of the above, actually.  There are a total of eight seperate
> networks, plus the internet.  one of these segments is a DMZ, one for
> desktop machines, one for internal servers, one for development servers,
> etc.  Only the DMZ is not masqueraded..  but we need to protect the
> individual networks from each other as well.

> The only reason the firewall rules are manageable at all is because the
> guy who set it up has a whole pile of macros and bash functions to
> convert a metafirewall config into the real thing. 

> Oh, and it's IPChains.   I can't count the number of times I've had to
> go back and forth to open up a new machine in the DMZ.  

Your point?  Your original point was on claimed advantages of IP Tables
over IP Chains and I asked for an example of your 100:1 claim.

> > I don't see how your analogy fits.  IP Tables is the "next generation"
> > of Linux Firewalling.  New versions of things should have as few
> > incompatibilities with the old as possible.  This is known as "upward
> > compatibility" and a good gauge of the quality of design.

> *nod*  Of course, fewer changes from an interface is better.
> However, there's one fatal flaw in your reasoning -- who said the
> original design was better than the one which followed?  

How is that a fatal flaw in my reasoning?  I stated that unnecessary
incompatibility introduced in the later version of a design is bad in
that it has a substantial cost for the users using that design who are
faced with an upgrade.  This is one of the biggest criticisms of Winbloz
and rightly so.

> There are tools that exist to convert ipchains firewalls to iptables --
> and they work fairly well, except that they usually result in a more
> complex firewall config than is actually necessary.

I doubt that those tools are 100% accurate, thus debugging time and/or
security holes will result.  Further, if there was not unnecessary
incompatibility then they (whatever these tools might be) would not
be necessary.  Further, I doubt that they conveniently translate back
for someone maintaining some systems with IP Chains and some with IP Tables.

> > A better analogy would be "making incompatible changes to X between
> > Linux 2.2 and Linux 2.4 or RH6.y and RH7.y," where X is the shell's
> > language, lilo's features, the C or Perl language, etc.

> But that's not a good analogy either; we're talking about a firewall
> backend, not a tool whose sole purpose it to interact with the user.

Again, you miss my point.  It's irrelevant what a tool's purpose is.  The
issue is unnecessary incompatibility requiring significant effort by the
user of the tool.  As I am the user of this tool it is a big issue with me.

> > Changing the capitalization of chain (table) names was stupid as was
> > the renaming of the DENY target to DROP, etc.  Suppose FSF decided to
> > rename the "if" statement name to "IF" in their C compiler?

> Does DENY mean "don't allow" or "tell them they're not allowed?"

> DENY != DROP.  

DENY == DROP.

It seems that this unnecessary change confused even yourself.

> REJECT != DROP.

> The new names accurately represent the actual behaivor.

Perhaps but it was unnecessary.  Certainly recognizing the old syntax
and even semantics should be a capability, perhaps enabled with an
environment variable.

> And for someone coming in with zero knowledge, at worst, the new syntax
> is just as arbitrary as the old syntax.  And at best, it makes more
> sense to them.

Someone with zero knowledge has no business configuring Firewalls.

Let's go through the source of the kernel, c, c++, and Perl language
processors, vi & emacs, the shells, etc. and try to find every command
which could be named better and change the name and create a Linux
distribution from it and sell it as the Improved Linux.  Even Ken
Thompson said that the creat() system call should have been named create()
in retrospect.  See how many people will use what you created.

> > Not true.  The syntax could have been made a lot more similar.  The
> > recognition of an environment variable or (less desirable) a flag to
> > support the old syntax and semantics would not diminish security and
> > would make life much easier for converting.

> Okay, then why aren't we using the ipfwadm syntax from the 2.0.x
> kernels?  Why did they have to invent new syntax for ipchains?

I don't use ipfwadm often enough to answer this question without research.
It may be that dumb decisions were made there too.  However, the number of
people that use (used) IP Chains is vastly larger and so it is a more
important matter in the transition to IP Tables.

> The syntax exists for a reason, and that reason is the internals have
> drastically changed.  You have to speicfy '-p tcp --syn' in that order
> because it's an option to the 'tcp' module, not an option to the
> 'REJECT' module.

No, its required because the creator of the iptables command did not
understand the importance of upward compatibility, IMHO.  A user of
something should not have to be bothered with its implementation details.
I'll probably grab the source to it (the iptables user-level program)
and fix this and the other annoyances that never should have been allowed
in, such as disallowing the old names and capitalizations.

> > Besides being a change for the sake of change, capitals take longer to
> > type.  Thus, unneeded inefficiency.

> If you're typing in your firewall in by hand, then you don't deserve to
> talk about efficiency.  "reject 10.0.0.0/0 0.0.0.0" is much simpler
> to type than "ipchains -a input -s 10.0.0.0/0 -d 0.0.0.0/0 -j DENY"

I don't follow you.  I do like your idea, though.  Let's see, for csh:

     alias reject "ipchains -a input -s \!:1 -d \!:2 -j DENY"

I like it.

> >      /sbin/ipchains -i ! eth1 -b -s 10.0.0.0/8 -d 0.0 -j DENY
> >      /sbin/ipchains -i eth0 -s -s 10.0.0.0/8 -j DENY

> >      echo 1 > /proc/sys/net/ipv4/conf/eth0/rp_filter

> This doesn't do the same thing at all.  Witness the following route:

> Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
> 0.0.0.0         130.207.193.1   0.0.0.0         UG    0      0        0  eth0

> It is legal for a 10.* address to come in on that port, according to the
> routing tables.  After all, 10.21.1.15 does match the 0.0.0.0/0 pattern.

> rp_filter stops packets that come in a different interface than they
> would otherwise leave.  But since I don't actually have a 10.21.0.0/16
> network, it's a perfectly legal packet, and rp_filter won't stop it!

> It will only stop spoofing inside your network.   Firewall rules to
> exclude private addresses from non-private interfaces are still
> necessary.

You don't quote my text that you are responding to so I cannot respond
to you accurately.  If I said that the echo was equivalent to blocking
the 10.* address then I erred.

> > That's what I mean about "seeming elegance" that causes inconvenience in
> > reality.  If I'm allowing some or all of the Internet to be able to SSH
> > into some of my (non-Masqueraded) systems, why should I handle the Firewall
> > itself completely separately?  Examples were given above.

> It's seperate precisely because it is a seperate case.  The firewall
> should only accept ssh connections from internal machines, but other
> servers may allow ssh connections from external boxes.  Every box there
> allows HTTP, but not the firewall box.  It keeps the forwarding policy
> seperate from local policy.  They are rarely exactly the same.

Perhaps the way you do Firewall rules they rarely are exactly the same.
The way I do them, which allows more sophisticated detection of attacks
and blocking of them, they do have many that are the same between the
rules for the Firewall itself and forwarded traffic.  I saw no reason
for an arbitrary divide.  In cases where I wanted different rules I
always could separate by "-d FW_IP" verses "-d ! FW_IP".

> > Uh, under Chains "-i" means interface and "-o" means divert the packet to
> > user land for processing.  Under chains the meanings of these flags are
> > decidedly different than this, namely incoming interface vs. outgoing
> > interface.

> Okay, -i is the same, but -o is different.  I toss this into the realm
> of a necessary change, because under iptables, you need to know both the
> input and output interface for packet forwarding, and ipchains doesn't
> care at all about where packets leave.  

You only need to know both input and output for forwarding because of the
arbitrary separation of the handling of forwarding from incoming/outgoing
packets.

> Logically, -i/-o make sense.  But they're different from before.
> They're now more consistent and orthogonal.

See above comments.

> > I'm not aware of any parameter order limitations in IP Chains that are not
> > present in IP Tables.  I'm not picking nits.  Every edit to convert an
> > IP Chains rule to IP Tables because of unnecessary incompatibility is a
> > failure of IP Tables design and a needless waste of the SysAdmin's time.

> Just like the differences between ipfwadm and ipchains are due to the
> "failure" of the ipchains design?

> The whole reason we have iptables at all is because of the
> "failures" of the ipchains design!

No, we have it because of the designer's failure to understand the
importance of upward compatibility.

> Face it; the way iptables works is very different than ipchains.  A
> straight syntatic conversion of ipchains to iptables does not mean the
> same thing, and is sub-optimal, precisely because of the internal
> differences.    

I don't care how iptables works any more than I care how the c compiler
or vi works.  I want new and improved, not new and different.  Vim versus
the original Berkeley vi (of which I had input as to its design) is a
perfect example of the right way to do things.  Vim is vastly different and
has very useful new features such as color hilighting of different elements
of the source of whatever common language that one is using.

However, there was NO learning curve because they were used in the
same way.  Nor has there been in the 25 years or so that I've been
using one or the other.  Ditto for csh versus tcsh or bash verses the
Bourne shell.  Both of those are far more sophisticated and complex than
either IP Chains or IP Tables.

> If you don't want to switch, then you don't have to.  Hell, you can even
> continue to use your ipfwadm rules if you still want to!

Your point?

> > Security is not when things "seem to work"; it's when they are
> > known to be secure (or have a high probability of being secure).
> > Shortening the timeouts for IP Masquerading increases security by
> > shrinking the vulnerable time window for attacking a Masqueraded system.
> > Lengthening it for long idle TCP connections, such as SSH, eases use.
> > Different deployments have different requirements.

> You're missing the point about a stateful firewall!  There's no need for
> a timeout, because the firewall keeps track of every connection;
> CONNECT, ESTABLISHED, FIN_WAIT, FIN_WAIT2, whatever!   The connection is
> closed when the two machines trade the CLOSE handshake, and not before.

Am I?  There are timeouts in IP Tables, such as for UDP pseudo connections.
Under IP Chains I can change these as needed for various types of UDP
services.  The failure to have them be programmable in IP Tables was just
laziness on the part of the developer.

> You no longer have a special "vulnerable window for a masqueraded
> system", you have a "vulnerable window for every connection" -- the
> firewall code does not care, nor does it need to know about what
> connection is for what purpose.

?

> > Regarding helper modules, I don't care about the implementation; it is
> > unimportant.  I'm concerned about how easy it is to use and how well it
> > works.

> Well, fine.  Go ahead and use Windows and Outlook for your e-mail; it
> seems to be easy to use and works just fine for 95% of the people out
> there.  And remember, Outlook never breaks; it's always the mail
> server's fault.

?

> > Five minutes?  Clearly you didn't try to convert a 500 line rule set.

> You're correct.  That five minutes was for a simple masquerade & local
> firewall arrangement.  More evolved configurations will take more time.

Yes.  Far more time to convert than would be necessary if unnecessary changes
were not introduced.

> > When I went from the 2.2 to the 2.4 kernel my 800 line .cshrc file
> > required NO changes.  Nor did my use of vi (vim), c, Perl, etc.  If I
> > wanted to redesign my system every few years because the vendor doesn't
> > understand the concept of upward compatibility then I'd use M$.

> That's because you didn't upgrade vi(m), tcsh, gcc, perl, or whatever.
> You upgraded the kernel.  The Application binary interface did not
> change.   If it did, then it wouldn't be Linux any more.

When I went from the 2.2 to the 2.4 kernel, the only thing I had to change
was firewalling so your distinction between kernel vs. non-kernel changes
is incorrect.  Many other things changed between the 2.2 and 2.4 kernel
but their designers (mostly) knew what they were doing and so I didn't have
to change *existing code* in order for *existing features* to continue to
work.  (This is the meaning of upward compatibility.)

> > > And then you get to pull a few more stunts, like limiting connection
> > > rates and that sort of thing.  State is good for many things.

> > Bandwidth limiting is supported under 2.2 and IP Chains.

> No, not bandwidth limiting.  Connection rate limiting.  "I want to
> limit the number of http requests to no more than 10 a second, and if I
> get too many, icmp redirect them to the backup machine until the rate
> slows down"

My mistake; I misread what you said.  Connection rate limiting is a
useful feature.  Adding a new flag or name to the IP Chains syntax would
be a welcome addition.

>  - Pizza

Bob
transam at cavu.com                       [Bob's ALE Bulk email]
bob at cavu.com                           [Please use for email to me]

---
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.