> (Thanks for uncloaking your identity, by the way. This discussion
> just got infinately more interesting. :))
This mail client is way more reliable, thats all...
Hmpf... sod it... anybody around with a nice disclaimer I can copy paste? ;)
> > Sure, can't argue with that.
> > But all this is based on the assumption that the attacker
> > or trojan is already within your "secured" network.
>
> Hm, no. Just on the other side of a bridging firewall. In the case
> internet --- router --- empty stub network -- firewall -- internal
> this is a non-issue, but as soon as you add DMZs, or have other hosts
> right outside your firewall, or have a router than can be SNMP-
> polled by anyone (view the ARP cache), it becomes an issue.
Many of the former discussed ways of gathering info doesn't work anymore.
Your router is probably going to send ICMP replies since it can't reach
the destination hosts...
With the DMZ in place, yes, you might want to set that up routed to
protect against MAC leaks.
> I'll give you that "open for an additional layer of information
> gathering" doesn't necessarily mean "open for an additional
> avenue of attack", but.. Yeah, I'm paranoid. :)
ROFL
> > [on using ARP to see if several IPs resolve to the same machine]
> > Indeed, and there are many more ways to find out of several
> > machines resolve to the same machine.
>
> Hmm.. Which ones would that be?
> (Sans allowing telnet in to the machine and seeing that you
> get the same hostname banner.)
HTTP? Just check the remote envrionment. for one...
Checking time stamps in various other protocols.
SMTP/POP
But how sure can you realy be?
How about a group of servers sharing a virtual MAC? (load balancing)
You might think they are the same but they are not.
> This is about as easy as it gets, IMHO, since a bridging firewall
> can't make L3/4 decisions on whether an external box gets to
> learn about internal network topology (hey, there's another
> argument! I can see if internal IPs get routed somewhere
> else! :)) -- a bridging firewall needs to pass ARPs to the inside
> network even when the external box isn't allowed to initiate a
> single connection to the inside hosts.
Learn if internal IP's are routed somewhere else? How?
You'll need to have penetrated both sides of teh firewall already.
And still if the firewall already has the MAC of the destination in
its forwarding table (learning bridge) you won't see the ARP.
How would yout proxy-arp solve this?
> > > And, here, have another low blow while I'm at it: proxy ARP
> > > does indeed answer using the firewall's MAC address for all
> > > published boxes. Even if they're down, or temporarily out and
> > > traveling, or has a physical L1 switch moving it back and forth
> > > between separate physical networks once every few minutes.
> > > (Yes, these things do exist :))
> >
> > Ehm... you're attacking your own standpoint now? ;)
>
> Hm, no, I don't think so. "Always answering" versus "seeing of
> the host is not there" is a good thing, I think. Unless you
> assume that the firewall itself can (easily) be attacked.
> I don't. :)
I'd prefer to not answer... its more tarffic efficient.
Why parce packets you are going to drop anyway.
Diederik
_______________________________________________
Firewalls mailing list
[EMAIL PROTECTED]
http://lists.gnac.net/mailman/listinfo/firewalls
