[c-nsp] Help settling an argument :-)

Church, Chuck cchurch at netcogov.com
Thu Sep 8 22:39:22 EDT 2005


Could the proxy/auth function be causing this?  If it's acting as a
transparent proxy, and intercepting web requests like a hotel or hotspot
system, could it be replying to the end user with TCP 80 packets spoofed
as if they're from the destination web server?  Just a thought... 


Chuck Church
Lead Design Engineer
CCIE #8776, MCNE, MCSE
Netco Government Services - Design & Implementation Team
1210 N. Parker Rd.
Greenville, SC 29609
Home office: 864-335-9473
Cell: 864-266-3978
cchurch at netcogov.com
PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x4371A48D 


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Jeff Kell
Sent: Wednesday, September 07, 2005 11:39 PM
To: cisco-nsp
Subject: [c-nsp] Help settling an argument :-)

I've gone around in circles for a week with our Novell administrator on
this one.  I'm fairly certain I'm right but I can't find a good
black-and-white reference to point him to that proves it (or point me to
so I can quitely surrender).  So here is the issue...

We have an IChains server (Novell proxy/auth/SSL thing) that has one
interface on the DMZ that users access directly, and another interface
on an internal network that has the back-end services it is protecting.
Fairly straightforward so far.

The switch handling the subnets is a 4500, which is relevant because it
doesn't support uRPF (at least not on our IOS image).  To compensate, I
have ingress filters that perform the same function, since these are
"leaf" subnets with no other routers, it checks to be sure the source IP
is indeed on the subnet in question.  Exceptions are logged (I want to
see any spoofing).  That filtering is a shop standard.

Now the interesting part.  The Novell server triggers the ingress
filters for certain traffic, trying to send DMZ interface IP sourced
packets out the private network interface, and vice versa.

The Novell box must be doing routing or IP forwarding, no?  I don't want
them routing [for obvious purposes].  He says he isn't.  I say he is.
There you go.

A consistent example of the problem, we have a simple network monitor
that pings each interface periodically to see if it is up.  When it
pings the DMZ interface, the Novell box answers on the private interface
(with a source IP of the DMZ interface).  If you're not routing, aren't
you always supposed to answer on the same interface the traffic came
from?

Bonus points if anyone knows the Novell knob to turn this off :-)

Thanks,

Jeff Kell
ITD Security
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/



More information about the cisco-nsp mailing list