At 04:52 PM 12/4/96 CST, Jeromie Jackson wrote:
>> At 04:17 PM 12/4/96 CST, Jeromie Jackson wrote:
>> > The exploits of sendmail are not based on the vulerabilities associated
>> >with the sequence number, or the state of the connection. If you are
running
>> >sendmail 4.1 on both machines, looking @ such criteria is not fixing the
>> >problem. Sendmail is still VERY vulerable.
>>
>> MailGuard is an upcoming feature to be released real soon which
>> is designed specifically to protect the inside mailhubs'
>> sendmail daemons. Stay tuned.
>>
>> > For just a bit more money, it appears the user community can get an
>> >application level gateway that would provide more functionality, as well as
>> >better security. If someone is just wanting to do IP filtering & NAT for
>> >their i-net connection, something like a linux box running ipfw would be
>> MUCH cheaper,
>> >and @ T1 speeds, or below, I believe there would be minimal degregation.
>>
>> Speed and Scalability are 2 different things.
>> Degradation on proxy servers occur sharply when there is a large number of
>> client connections it has to "proxy for". With 3 clients pumping ftp data
>> across a proxy server firewall on ethernet you probably won't see a lot of
>> degradation.
>> Try using 100 clients going out to a remote site over a T1, you will
>> probably wonder why
>> your T1 is not saturated if you use a Linux box.
>>
>> > Here's the problem with packet-filtering in a nutshell...
>> >
>> > 1) Packet filtering cannot evaluate data-based attacks.
>> >
>> > 2) Packet filtering bases access control on header information
>> > (src,port,dst,port,flags). As we all know, this data is not
>> > authenticated whatsoever, thus spoofing can subvert the ACLs
>>
>> Not only is the PIX not a packet filter, it is spoof-proof and protocol
aware.
>>
>> Take the example of CuSeeMee, on ORDINARY PACKET FILTERS you'd have to say:
>>
>> access-list 101 permit tcp 0.0.0.0 255.255.255.255 x.x.x.x 0.0.0.255 estab
>> access-list 101 permit udp 0.0.0.0 255.255.255.255 x.x.x.x 0.0.0.255 eq 7648
>> access-list 101 permit udp 0.0.0.0 255.255.255.255 x.x.x.x 0.0.0.255 eq 7649
>> or
>> set fil inet.in 11 per 0.0.0.0/0 x.x.x.0/24 tcp estab
>> set fil inet.in 12 per 0.0.0.0/0 x.x.x.0/24 udp src eq 7648 dst eq 7649
>> set fil inet.in 11 per 0.0.0.0/0 x.x.x.0/24 tcp src eq 7649 dst eq 7648
>>
>> 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.
Do you consider Checkpoint a packet filter?
matt
>
>
>Jeromie Jackson
>Garrison Technologies
>jeromie @
garrison .
com
>
>
Matthew Howard
Product Line Manager mhoward @
cisco .
com
Internet Business Unit 408-526-4720 (voice)
Cisco Systems Inc. 408-527-8122 (fax)
170 West Tasman Drive
Building VM2 (corner of First & Vista Montana)
San Jose, CA 95134
|
|
