Re: dirty packet tricks?

[Dana Nowell <DanaNowell () cornerstonesoftware com>]

Marcus,
  What about subnet issues, switches, VLANS, ICMP errors, and assorted
other unfriendly things in the way.  OK some like subnet issues you can
solve via promiscuously sucking up packets.  But it seems like a further
restriction that your 'sideways' proxy box is it will have to be on a hub
with the 'inside' firewall interface, no switches or VLANs allowed.  

The firewall will have to suppress all ICMP errors to the internal network
if and only if that particular connect was to be routed via the transparent
proxy.  In the simple case where there is only a single logical segment
behind the 'wall this is easy but what if multiple segments exist.  Do you
take packets based on source address in the 'sideways' proxy but ignore all
other 'not mine' packets, if so how do you suppress the correct errors at
the 'wall?  Or I guess you can proxy all packets on the internal segment
that are destined for the firewall, including spoofed ones, and then the
firewall can ignore all errors routed to the internal interface not
destined to the 'sideways' proxy.  Or, hopefully, you can get more creative
then the two minutes of thought I applied to the problem.

OK, now we add an internal IDS where the internal end user box requests a
restricted service.  The IDS sends a reset to the end user box to suppress
the connection attempt.  However, the 'sideways' proxy gets the initial
connection attempt and attempts to build an outbound connection.  Does it
'see' the reset and drop the attempt, or does it complete the connect and
hang about waiting for a timeout (link this with the spoofed packet issue
above and spell easy internal DoS via bug or nasty internal idiot)?

Isn't it easier to put yourself inline by 'corrupting' the local ARP tables
(or static ARP) and 'pretending' to be the firewall :-)?  Hmmmm, I was
joking when I typed it but would that REALLY work?


OK, I'll stop now, my head hurts.


On  Thu, 11 Jul 2002 01:45:12 -0400 Marcus J. Ranum caused the following
mayhem:
Barney Wolff wrote:
> Maybe I'm not understanding the problem correctly, but why can't a
> box with the standard (for FreeBSD) ipfw/natd combo do what you
> want?

Hmm... if I am able to put myself in the routing path then
it's a straightforward problem to solve using the ancient
techniques of the firewall transparency masters. ;) What
I was thinking of doing was basically implementing the same
thing as proxy transparency _without_ having to alter the
routing topology of the network or place myself in the
routing path as a bridge or whatever. It occurred to me
the other day that this might be possible, which is why
I am pursuing it at this moment. It'd be kind of cool: you
could just tell your firewall "block all packets to XXX"
and have this mystery box pick the traffic up, and then
application-level proxy it without the end user being
able to notice a thing. There are many fun applications
for such a capability. ;)

One correspondant pointed out to me that the firewall
would have to be told not to send reset or unreachables
to client machines or my scheme falls over right away.
I'd forgotten about that. :(

> If you can't control the inside routing,
> how could you ever force packets to come to your box in the first
> place?

That's really the meat of my question. I was thinking that I
could suck 'em up promiscuously!! :)

(Thanks to all who have responded directly to me on this thread.
I'm having a blast trying to solve this problem and, while nobody
has yet handed me an answer on a plate, I'm getting lots of good
ideas for how to proceed!)

mjr.
---
Marcus J. Ranum                         http://www.ranum.com
Computer and Communications Security    mjr () ranum com



Dana Nowell     Cornerstone Software Inc.
Voice: (603) 595-7480 Fax: (603) 882-7313
mailto:DanaNowell () CornerstoneSoftware com

_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards