Eliot,
You are absolutely correct .. I interpreted the system as a non-IP (
IPX/SPX) to the internal net and an IP (TCP/IP) connection to the public
internet.
Therefore, Adam's reply apparently addressed a IP tunnel to the internal
net.
Bare in mind, that the above scenario would prohibit any socket activity
from the internal net through the server.
Ed
-------------------------------------------------
Ed Gelb Mailstop 7F-6
Ed Gelb <gelbe @
panasonic .
com
Panasonic Communications & Systems Company
2 Panasonic Way
Secaucus, New Jersey, 07094
Voice: (201)-348-7292
"Attacking must be a forward motion" Ed Gelb
-------------------------------------------------
----------
From: Eliot T. Ware
To: Adam Prato
Cc: Firewall ListServer
Subject: Re: IP/IPX gateways
Date: Friday, March 15, 1996 07:51EDT
Adam Prato wrote:
>
> On Wed, 13 Mar 1996, Jeffry Tank wrote:
>
> > Date: Wed, 13 Mar 1996 07:45:38 -0500
> > From: Jeffry Tank <jtankf @
vsecorp .
com>
> > To: firewalls @
greatcircle .
com
> > Subject: IP/IPX gateways
> >
> > Can anyone tell me if it true that by putting an IP/IPX gateway between
your
> > internal IPX lan and your internet server, you can prevent _all_ attacks
to
> > your system from the outside (the internet)? Seem too simple to me, but
some
> > folks at my company insist that this is true. What about IPX packets
> > wrapped in an IP layer? (assuming this can be done) Then when the IP
layer
> > is stripped off at the gateway couldn't the IPX parkets contain info to
> > inflict damage to the internal network, at say the Novell server?
>
> It's totally *untrue* however, their claim has merit.
>
> Most IP/IPX gateways are probably some sort of router that has access-list
> capability. With these access-lists you can build up an access table that
> is clearly defined by your security policy. The trouble is, building a
table
> that doesn't leave any holes. Thus, its very plausible to just shut
everything
> off........
>
> However, The way TCP/IP functions, is that any connection from a local
client
> to a remote server (be it DNS, Telnet, FTP, HTTP, IRC, just about any
service),
> requires that a local port be opened up, greater than 1024, and its bound
to
> a remote port, at whatever port it is. Thus you have to allow *every port*
> above 1024 for both TCP and UDP to cross, otherwise you will not be able
to
> telnet out (brings back memories of my first cisco access-list
configuration,
> reminiscing). Thus this is one hole that you open up since X (quite
insecure),
> NFS, and YP all use ports > 1024 (however the former are somewhat
protected
> since portmapper would have been blocked at port 111). You would have to
> periodically scan your network from the 'outside' to see what sockets are
> listening to high end port numbers, and make sure that no nasty insecure
> services are listening there. Once you've found them all you would have to
> deny them in your access table.
>
> Another reason *not* to trust this idea is that a while back, many routers
were
> vulnerable to packet fragmentation attacks, where an attacker hides his
attack
> in smaller encapsulated packets. Also, if not configured properly (which
isn't
> hard to do), the router's access-list can easily be bypassed with a
spoofed
> IP header. IMO, there are just too many ifs, buts, and other loose ends
with
> this kind of security. I'm still learning about firewalling, but from my
> perspective, it offers a definite improvement over the 'packet filter'
approach
> to network security.
>
> Adam
> end port numbers, and make sure you turn anything off that is dangerous.
I'm no wizard (or even a novice) in this area but in reading what Adam has
written, doesn't this presuppose the presence of IP on the inside? If there
is no IP on the inside then where is the attacker going?
- Eliot
--
Eliot T. Ware, CNE voice: (202) 622-1302
Global Systems Architect fax: (202) 622-2582
Department of the Treasury (UNIBAND)
preferred: etware @
access .
digex .
net
alternate: eliot .
ware @
treas .
sprint .
com
|
|
