[ale] ipchains in 2.4.13

[Chris Fowler]

I've mead the chaing to iptabels.  Can some be so kind and tell me how to
convert this to iptabes?

/sbin/ipchains  -N user_msq
/sbin/ipchains  -A user_msq -s 0/0 -d 0/0 -j MASQ

#forward packets
/sbin/ipchains  -A forward -s 192.168.1.0/24 -d 0/0 -i eth1 -j user_msq


I've allready done: /sbin/iptables -N MASQ


I quess I need to do:/sbin/iptables -A MASq -s 0.0.0.0/0 -d 0.0.0.0/0 -j
MASQ

Will this work:/sbin/iptables -A FORWARD -i eth0 -o eth1 -s
192.168.2.0/24 -d 0/0 -j MASQ

Thanks,
Chris


-----Original Message-----
From: Stuffed Crust [mailto:pizza at shaftnet.org]
To: ale at ale.org
Sent: Friday, January 25, 2002 6:11 PM
To: ale at ale.org
Subject: Re: [ale] ipchains in 2.4.13


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.

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

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

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.

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

> 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.
REJECT != DROP.

The new names accurately represent the actual behaivor.

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.

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

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.

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

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

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

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

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

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

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.

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!

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

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.

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

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

 - Pizza
--
Solomon Peachy                                    pizzaATfucktheusers.org
I ain't broke, but I'm badly bent.                           ICQ# 1318344
Patience comes to those who wait.
    ...It's not "Beanbag Love", it's a "Transanimate Relationship"...


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