[ale] ipchains in 2.4.13

[James P. Kinney III]

To do masquerading in iptables, the event occurs in the mangle table:

/sbin/iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

>From this, any packet going out on ppp0 will be NATed. Notice that the

table is mangle and the chain itself is POSTROUTING.

On Fri, 2002-01-25 at 18:19, Chris Fowler wrote:
> 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]
> 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.
> 
-- 
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