> Once again, if the bridge mode product does any protections that aren't
> lent, it will potentially be detectable on non-management networks.
And there's the big IF!
And that depends on the implementation of the firewall, both for routed and
bridged mode. For the lucent BRICK I know it protects silently unless the
admin chooses to allow ICMP reply's to be generated.
> > Why is a device that simply drops or accepts packet les protective?
>
> It doesn't protect machines with predictable sequence numbers, it doesn't
> necessarily do the right thing for out of sequence frags...
C'mon, I'm not talking about a straight forward filter, let's be realistic.
A firewall without Statefull Inspection is no firewall. And again that has
nothing to do with bridged or routed.
We were talking about how to detect a firewall, which has nothing to do with
what you are describing.
I claimed NMAP could not find it since teh firewall will not send anything
back to your probing host.
> > Don't tell me you are happy with a firewall creating ICMP replies for all
> > connections that are not allowed through?
>
> Depends on the application, quality of internal hosts, etc.
Sorry, why reply for services that are not allowed anyway??
For services that are needed, indeed you will in some cases want ICMP to work.
> > Exactly my point.
> > Next to a firewall you need intrusion detection etc. etc.
>
> The point is though that that's not where banks keep their money (just
> like the firewall isn't generally the target itself.)
Where does a bank keep the cash? All in the drawers at the counters?
Don't start about banks not needing to have 100% of their customers available
to them in cash...
I never said the firewall is the target of the attack... but it is a hindrance
that needs to be overcome. How to get out of the bank if all the doors are closed.
> > > > I'm not sure if your firewall is doing proxy arp, but I suppose so, I prefer
> > > > layer2 bridging over proxy arp any time.
> > >
> > > A layer 2 bridge has to look at a lot more packets (all of them) than a
> > > proxy ARPing firewall.
> >
> > This is true depending on the implementation. You can still tell a
> > bridged firewall what IP addresses it should pass the ARP's for. There
> > is no need to just accept all packets and pass them through you
> > rulesets on all interfaces.
>
> Sure, but you still have to look at them all- that can be a performance
> degradation from collisions in some circumstances.
Very far fetched.
Your interface should be able to handle maximum traffic load.
Deciding what traffic needs to pass through the firewall engine is a small
process there are many ways to limit the overhead anyway.
What do collisions have to do with this?
> I should have been more clear- "look at" means inspect the packet, not
> pass it- if the switch has a set of MACs, it'll only forward those packets
> and broad/multicast, where as if you're in real bridge mode, you get every
> packet on the segment.
Actually no.
hosts A1..10 --> bridged firewall --> switch --> hosts B1..10
When A1 arps for B1, B1 will answer, updating the switch MAC table.
etc.
If a machine does not respond to ARP's, where is the switch going to send the traffic?
Default gateway, correct? Same for routed/bridged/proxy-arped
Now, when hosts A1..A10 are down for whatever reason, no traffic will be send to
through
the firewall in full bridged mode. (no arp response = no traffic)
What will happen in the same situation when it would be routed? Or proxy ARPed?
Right, the traffic will hit the routed mode firewall anyway.
And, the proxy-ARPing firewall will still proxy-ARP and accept the traffic.
(unless the proxy-ARP is active, and not passive.)
> Again, it depends on implementation. Sometimes there's more exposure to
> letting the target host MACs get around than just the firewall's MAC.
I can't disagree withthe truth :)
> > But again, that means the intruder is on you local LAN. What does he
> > want to do with the MAC info? confuse a switch? Worse case the
> > firewall will notice this and ignore the spoofed MAC.
>
> Try to play ARP games with machines that are "protected" by the firewall
> perhaps.
What is the fun about ARP games when you still can't change the traffic flow.
You might be able to DOS the network, great. But you can do that anyway, with
or without the firewall.
> > If the device where you are proxy-arping for is down, your firewall
> > might still proxy arp for it, a bridge won't since the ARP is
> > generated by the host itself.
>
> The firewall can act as both an ARP requestor and an ARP answerer, so this
> really isn't an issue (ARP externally, then answer.)
Hmmm... buzword needed... ah: Won't that add to the latency?
So all you do is hide the MAC's of other hosts, this can be easily found out
when your LAN is penetrated already, a trojan can still find out who you are
doing the proxy-ARP for, and MAC address tables can be messed up just as easily.
I don't see why proxy-ARPing would be better than bridging, both look equally
valid to me.
Greetings,
Diederik
_______________________________________________
Firewalls mailing list
[EMAIL PROTECTED]
http://lists.gnac.net/mailman/listinfo/firewalls
