> 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.
>
Agreed
> 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)
>
Ok.. Here's the scenario, where you cannot stop the spoof, it it not
because of a flaw in the firewall, but a flaw in IPV4...
1) external user requests an inbound telnet connection.
2) User gets Authenticated.
3) User reaches the destination & logs in
4) Hacker find out what sequence number is being used
5) Hacker sends RSTs to the real user, thus causing his session to close
6) Hacker continues sending packets to the internal machine,
incrementing the sequence number as necessary.
This is obviously a scenario of Hijacking. Your box cannot stop it,
Thus, saying it is 'spoof proof' is just _NOT_ correct.
Jeromie Jackson
Garrison Technologies
jeromie @
garrison .
com
> -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
>
>
|
|
