[Date Prev][Date Next] [Thread Prev][Thread Next]
Re: Firewall: Please Advise
- From: "jdow" <jdow earthlink net>
- To: <valhalla-list redhat com>
- Subject: Re: Firewall: Please Advise
- Date: Fri, 11 Oct 2002 17:54:52 -0700
From: "Craig White" <craigwhite azapple com>
> On Fri, 2002-10-11 at 06:15, jdow wrote:
> > From: "Michael Schwendt" <rh0210ms arcor de>
> > > On Fri, 11 Oct 2002 04:10:56 -0700, jdow wrote:
> > > > And every one of them said it is basically impossible to pass most
> > > > of the additional protocols that are passed via the ip_masq_xxxx
> > > > protocol modules for IPChains.
> > > So, are you back to kernel 2.2? Because the ipchains
> > > compatibility module in the 2.4 series is limited, isn't it?
> > Both IPTables and IPChains are limited.
> > > Somewhere on the netfilter page (probably in a howto) it reads that
> > > ip_masq_xxxx-like protocol-specific IP masquerading modules are
> > > not needed with iptables, because those protocols just work with
> > > netfilter (due to its architecture being different).
> > Yeah, I saw that. But NOWHERE do they say how to make it work. And
> > I had IPTables setup, which is how I learned, the hard way, that it
> > didn't work. That lead to my reading experience. This is precisely
> > the reason the author of the TrinityOS Project (a very secure Linux)
> > has not moved to IPTables. The IPTables are simply too limited as
> > they exist today.
> > > On one of the netfilter lists (probably netfilter-devel) I've
> > > read about a couple of helper modules for special protocols.
> > > You might want to ask there. Of course, if you are entirely
> > > happy with ipchains, why change? ;)
> > One would expect the Netfilter site, the developers' site, would
> > have word of these modules. I have looked. The only two modules
> > that exist are ftp and icu. There are at least a half dozen modules
> > for IPChains to facilitate such things as the H.232 conferencing
> > protocol and so forth.
> > Believe me, as soon as it is shown IPTables can do at least as much
> > as IPChains I will change. In the meantime IPTables exhibit only a
> > theoretical superiority. Much of their superiority is not needed at
> > this site. The gateway/firewall machine is grossly underloaded. So
> > the time efficiency is not needed. What is needed is security and
> > protocol support.
> at the risk of continuing a thread that is off topic...
> the list of no module support is minimal
> David Ranch's own words...trinityOS...
> The newest 2.4.x kernels are now using both a completely new TCP/IP
> network stack as well as a new NAT sub-system called NetFilter. Within
> this NetFilter suite of tools, we now have a tool called IPTABLES for
> the 2.4.x kernels much like there was IPCHAINS for the 2.2.x kernels and
> IPFWADM for the 2.0.x kernels. The new IPTABLES system is far more
> powerful (combines several functions into one place like true NAT
> functionality), offers better security (stateful inspection), and better
> performance with the new 2.4.x TCP/IP stack.
> I would submit that the modules not supported are not at all meaningful
> because a security conscious administrator wouldn't want inbound game or
> h.323 packets to run rampant on their networks anyway. Connections
> created by networks masq'ed by iptables are totally supported and
> Also, David readily admits that his continued use of ipchains/2.2 is
> because he hasn't had the time to play with iptables.
> In conclusion, your argument that what is needed is better security and
> protocol support falls squarely on the side of iptables.
Keep reading the site, Craig. This is chapter 10.4. Note particularly the
second to last paragraph.
10.4 Differences between Packet and Statefull Firewalls
Now, I want to quickly comment on the use of HIGH TCP/IP ports and what is
the difference between a PACKET firewall and a STATEFULLY INSPECTED
firewall. Though you might let port 23 OUT of your Linux box (TELNET), if
you don't also allow ports 1024-65535 back INTO your Linux box, TELNET won't
Now you might be thinking that letting in ALL high ports back into your
Linux box is a BAD thing. You know what? YOU'RE RIGHT!
Realistically, it would be nice to only allow in only the return HIGH ports
that you need. This is what the "-k" option in IPFWADM or "! -y" is for
IPCHAINS. The problem is, IPFWADM and IPCHAINS aren't smart enough yet to
understand all TCP/IP programs such like TELNET, WWW, SSH, etc. So, some
programs you can lock down the high ports with the "-k" or "! -y" options
while other programs will have to be configured to allow all 1024-65535
Bummer huh? So your next question should be "Do others firewalls have this
problem?" NO! Why? Because they use a technology called "Stateful
Stateful firewalls actually listen to ALL network traffic step-by-step to
make sure that everything is going 100% correctly.
Packet firewall: A packet firewall only checks for source and destination IP
addresses and port numbers. Kinda like a strainer for different colored
marbles (if one exists).
Stateful Firewall: A stateful firewall not only checks for source and
destination IP addresses and port numbers, but it also LISTENS to all TCP/IP
communications to make sure that all of the "communications" are following
all procedures. Think of it as a realtime grammer and spell checker for
"languages" like TELNET, WWW, etc. Hackers try to re-write the "language" to
try to break into it, crash it, etc. A stateful firewall will see a given
TCP/IP connection running a "language" like TELNET doing weird stuff that it
shouldn't be doing and then it simply drops that weird packet. Much better
So your next question should be: "I want a statefully inspected firewall for
Linux and NOT a packet firewall. Where do I get one?!?!"
Well.. it now exists in IPTABLES under the 2.4.x kernels. This is a huge
step for for Linux. Unfortunately, if you also need to use IP Masquerading
(NAT), the MASQ support for some protocols under the 2.4.x kernel isn't on
par with the 2.2.x kernel set. If you don't use IPMASQ, then then IPTABLES
is a great solution. It should also be noted that non-IPMASQ users can still
use their IPCHAINS rulesets under 2.4.x kernels with the aid of the
ipchains.o kernel module.
For now, TrinityOS only covers IPCHAINS and an older IPFWADM ruleset. A
IPTABLES ruleset is under developement but is a slow project as it is an
entire rewrite and will offer far more features.
And this is a further clip from the section you cited - the CONS portion.
Netfilter is an entirely new architechure thus most of the older 2.2.x MASQ
kernel modules written to make non-NAT friendly network applications work
through IPMASQ need to be re-written for the 2.4.x kernels. Because of this,
if you specifically need functionality from some of these modules (see
below), you should stay with a 2.2.x kernel until these modules have been
ported. If you are curious on the porting status of a given module, please
email the author of the module and NOT David or Ambrose. We don't code.. we
just document. :-)
Here is the status of the known IP Masq kernel modules or patches as found
on the IPMASQ WWW site's Application Support Matrix. If you have the time
and knowledge to help in the porting of code, your efforts would be highly
Status = Module name = Description and notes
--------- ----------- ----------------------------------
NotPorted CuSeeme Used for Video conferencing
NotPorted DirectPlay Used for online Microsoft-based games
Ported FTP Used for file transfers
- NOTEs: Built into the kernel and
fully supports PORTFWed FTP
NotPorted H.323 Used for Video conferencing
NotPorted ICQ Used for Instant messaging
Ported Irc Used for Online chat rooms
- NOTEs: Not included in the kernel.
Part of the extra iptables package
NotPorted Quake Used for online Quake games
Beta Avail PPTP Allow for multiple clients to the same server
NotPorted Real Audio Used for Streaming video / audio
NotPorted VDO Live Used for Streaming audio?
Most of them I don't particularly need. However streaming video (which
does not fully support, either) and Real Audio are a necessity. If none of
the unsupported protocols above are not needed then by all means use a
2.4 kernel and IPTables. Otherwise you are basically stuck using 6.2 brought
as up to date as possible. However, do note that Point to Point Tunnel
Protocol is not supported beyond beta code. This is an important security
tool for things like remote administration.
[Date Prev][Date Next] [Thread Prev][Thread Next]