On Mon, 15 Apr 2002, Diederik Schouten wrote: > > 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!
Sure, but it's an important one if the bridge mode product does such things. > > 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. I am being realistic, you seem to be missing my point (I'm probably not being clear enough.) If you have a firewall that fixes initial sequence numbers- which a lot of stateful products do- and it's a bridge-mode device, its existance may be detected based on OS fingerprinting. If your bridge-mode firewall doesn't do the same thing for out-of-sequence packets, frags, strange window advertisements, etc. as the host OS, then its existance may be detected. That's even if it simply drops them where the host OS would normally send a reply. > We were talking about how to detect a firewall, which has nothing to do with > what you are describing. Yes, it does- please see above. > I claimed NMAP could not find it since teh firewall will not send anything > back to your probing host. Getting nothing back instead of an expected response is still a potential information channel. > > > 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?? If the firewall is invisible to "internal" client machines, it may be better to have RST or ICMP packets to keep those machines' state consistant than to have the additional traffic of retries, sockets hanging open, etc. > Where does a bank keep the cash? All in the drawers at the counters? Mostly in (mostly bond) markets. > Don't start about banks not needing to have 100% of their customers available > to them in cash... That's how banks work though. > Very far fetched. I've seen it at 2-3 sites/year in general. > Your interface should be able to handle maximum traffic load. Maximum traffic load changes based on what traffic you must handle. > 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? The firewall generally has one interface, if it's on the same segment as 60 clients, and it's in bridged mode, it must look at every packet on the wire- even when that traffic is client<->client rather than client<-through->firewall. > > 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 it's a real bridge, it'll inspect the traffic, look at its ruleset and pass or drop the traffic. > If a machine does not respond to ARP's, where is the switch going to > send the traffic? Default gateway, correct? Same for Switches don't send to gateways- they either send to a specific MAC or to a promiscuous ports, in the case of a (spanned/promiscuos/monitor/trunk...) port (maybe this is what you mena by gateway?), it gets *all* traffic on every switch I've ever used, not just unknown traffic, hence the collision issue. Maybe I'm missing a switch configuration parameter though? > 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) a1..a10 are on a switch with the firewall, the firewall will have to be on a spanned/trunked/promiscuous/whateveryouwanttocallit port. That port will get any traffic on its segement, same for the other interface on network b. > What will happen in the same situation when it would be routed? Or > proxy ARPed? The traffic will go to whichever port the layer 2 address specifies (gateway address or proxy arp host address.) > > Right, the traffic will hit the routed mode firewall anyway. Wrong, the switch will only send unicast traffic destined for the device on that port or broadcast/multicast traffic. On a hub, the answer would be the same for either case, this specifically is an advantage on switched networks. > And, the proxy-ARPing firewall will still proxy-ARP and accept the traffic. > (unless the proxy-ARP is active, and not passive.) I'm not sure what you mean by passive proxy arp, ARP is an active protocol. > > > 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. It depends on the failure mode of the layer two infrastructre as to if it's a DoS or something potentially more evil (like getting the switch to leak packets.) > > > 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 little it's trivial, since the ARP response will be cached after the first lookup in either case. > 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. Sometimes it's better, sometimes not. 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
