At 10:20 PM 12/4/96 -0700, Alfred Huger 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. 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.
>>
>
>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.
We also track all tcp flags including tcp seq numbers. We also randomize
each new session through our adaptive security algorithm (stateful). Plus
we support ah/esp.
Matt
>
>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.
>
>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.
>
>
>--------------------------------------------------------------------------
>Alfred Huger ahuger @
secnet .
com
>Secure Networks Inc.
>---------------------------------------------------------------------------
>
>
>
|
|
