To all:
PLease use caution when reading the following to avoid confusion.
I posted he original statement of "opens up UDP ports 7648 and 7649
BLINDLY to all traffic including attacks" criticizing packet filtering routers.
I also contrasted it with the PIX'es adaptive security.
I hope readers do not mistake this stateless opening of
udp ports applies what the PIX does.
As of today, the current official release of PIX still does not have
Java filtering or any SMAPd type of mail wrappers. But that does not
prevent it from being a stateful firewall being capable of thwarting
spoofing and hijacking.
Going against IP spoofing, The PIX has cut-through proxies authenticating
inbound sessions from trusted hosts to selected internal hosts.
This is user-based authentication. It also randomizes TCP sequence numbers
to further minimize the chance of a successful spoofing.
A packet filtering router exposes internal hosts and is not protocol aware.
To allow ftp clients inside going out you basically have to open up
TCP SRC=20 and DST gt 1023 for everyone in the whole world.
The PIX makes an inside network totally invisible to the outside and
only reveals certain IP addresses to the destination host when connections
go outbound and only allows the requested data coming in.
With due respect, I challenge Mr. Jackson's point saying:
>> > As far as being
>> > 'spoof proof', that is just not correct. If you are talking to
'1.2.3.4', I
>> > can send you a packet appearing as though it is originating from '1.2.3.4'
In the case where the the client starts a connection from SRC port 2345
to 1.2.3.4's port 80 to get a webpage and then ends the connection.
The PIX immediately closes the connection object after that and even if the
hacker
succeeds in impersonating 1.2.3.4 ( the dest. host ) and tries to come in via
SRC=80 dest=2345 with the ACK bit set, the PIX will not let the packets come
through.
( Interested PIX owners can try it themselves)
-Johnson
At 10:35 PM 12/4/96 CST, Jeromie Jackson wrote:
>> On Wed, 4 Dec 1996, Jeromie Jackson wrote:
>>
>> > >
>> > > This opens up UDP ports 7648 and 7649 BLINDLY to all traffic including
>> > > attacks. Also there's that infamous estab statement where someone who
>> > > knows how to doctor the ACK bit can inject TCP packets into the
customers'
>> > > net.
>> >
>> > Hmm, That certainly looks like packet filtering to me.
Yes you are right. It was my example of a packet filter, not the PIX.
>> > Based on header
>> > information, you are making decisions about packet flow. As far as being
>> > 'spoof proof', that is just not correct. If you are talking to
'1.2.3.4', I
>> > can send you a packet appearing as though it is originating from '1.2.3.4',
>> > you would believe me, because there is no authenticion built into IPV4.
I would
>> > agree, that the filtering mentioned above is better than that done w/ a
standard
>> > IP filtering device, although because decisions are being made on
objects that
>> > are not authenticated (header information), ACL's can, and will be
vulerable to
>> > spoofing/hijacking.
>> >
>>
>Ahuger @
secnet .
com wrote:
>
>> ACL's being vulnerable to spoofing/hijacking..... I am not sure if I am
>> reading you clear on this, but what I think I see you saying is that you
>> can still spoof Source IP addresses to a Cisco PIX firewall. Also you
>> state, trusted connections to the firewall can be hijacked. If this is
>> what you are saying, my reply would be such.
>>
>> Your correct in saying IP4 has no built in authentication, the only thing
>> in IPV4, related to security is the Security Field (which denotes how
>> classified a datagram is). This being said, anyone, anywhere can slap
>> and Source Address on a packet and fire it off their wire. *No* Firewall
>> can protect you from this. Cisco PIX or otherwise. If you need to speak
>> the outside world (which if you have a Firewall I assume you do) then you
>> are subject to packets with questionable Source Addresses. I don't see
>> this as a real weakness of any given Firewall, just shortcomings of IPV4.
>>
>
> Agreed. I brought this up, to show the inherent weakness in ACLs.
>Obviously both methanisms, ip filtering devices, and application level
gateways, are vulerable to such data. An IP filtering device uses this as
its primary
>access control mechanism though, whereas an application level gateway would
>also implement things to force RFC conformance of the protocols, most likely
>have data reduction tools, and be able to address issues such as the Mail
>Transport Agent problems. App. gateways also have the capability to do things
>such as Java/Javascript filtering, Mail filtering, whereas strictly IP
filtering
>mechanisms do not have such capabilities.
>
>> As to streams of data (TCP presumably) being open to hijacking. That again
>> is another problem which cannot really be addressed by a Firewall itself.
>> If an attacker has breached a host whom your firewall allows *unencrypted*
>> or even *encrypted* connections from, your had. And it's not your
>> Firewalls fault.
>>
>> Both of these issues are policy issues, Both require a Firewall Admin to
>> ask himself how much of the outside world he/she trusts. In the case of
>> spoofable addresses, Admins must realize that not all packets coming in
>> off the net, are really coming from where they say they are. In respects
>> to TCP hijacking, an Admin has to ask his/herself if they want to allow
>> TCP connections through their firewall.
>>
>
> Agreed.
>
>
>Jeromie Jackson
>Garrison Technologies
>jeromie @
garrison .
com
>
>
Johnson L. Wu
Cisco Systems
2464 Embarcadero Way
415/842-2114 voice
415/843-1111 fax
jlw @
cisco .
com
so long: johnson @
translation .
com
private: johnson @
snoopy .
ORG
|
|
