On Mon, 15 Apr 2002, Diederik Schouten wrote: > > > I'm not talking about blocking a protocol. > > > When the firewall is not a hop, it doesn't show up. > > > > s/doesn't show up/sometimes doesn't show up/ > > s/sometimes doesn't show up/most often doesn't show up/ > > remember, only for management traffic. > If that is on a management interface, on a separate network it will > NOT show up unless the intruder is already active on your management > LAN. > > If you use remote management depending if it has been setup as > pass-through management or strictly routed, it shows up from time > to time in routed mode only.
Once again, if the bridge mode product does any protections that aren't silent, it will potentially be detectable on non-management networks. > 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... > 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. > > > How to protect a banks money when the fire has started within the safe? > > > > FM-200 suppression system in the safe, if banks kept more than trivial > > ammounts of money in safes anymore. > > 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.) > > > 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. > The BRICK will not just accept all packets and copy them in its packet > processing process unless sombody sticks to using wildcards in the > config :) 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. > > You have to expose the MAC address of anything beyond the firewall, that's > > sometimes a worse evil, especially if there are several things in the > > network immediately on the other side of the firewall. > > Don't see why you should not, the MAC is needed for communicating > anyway, if there are devices that should not be reachable from the > outside, then the ARP's do not need to be bridged unless the session > is established from the inside. Again, it depends on implementation. Sometimes there's more exposure to letting the target host MACs get around than just the firewall's MAC. > 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. > > If you wanted to add some complexity, you could always have the proxy ARPing > > firewall ARP with the "real" MAC address from the other side and listen on > > that MAC on the near interface. I'm not sure the gain is worth the > > additional code, but it's not precluded by architectural impossibility. > > 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.) Paul ----------------------------------------------------------------------------- Paul D. Robertson "My statements in this message are personal opinions [EMAIL PROTECTED] which may have no basis whatsoever in fact." _______________________________________________ Firewalls mailing list [EMAIL PROTECTED] http://lists.gnac.net/mailman/listinfo/firewalls
