> > And there's the big IF! > > Sure, but it's an important one if the bridge mode product does such > things.
Sure but that counts for any type of firewall. > 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. Sure but that counts for any type of firewall. > 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. I wouldn't realy want my firewall to fix all this would I? Especialy when you are not changing the media... If any of these should be handled differently than the OS is doing, this should be done by all firewall types, shouldn't it? So this is not bridged mode specific. > That's even if it simply drops them where the host OS would > normally send a reply. Indeed, so you will find out that although you know a host is running a certain OS, it does not respond as it should. So something is blocking traffic. Or some services have been disabled, or the host is running a personallised kernel... but you still don't know where the firewall is, what the vendor is, what the version is... etc. > > 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. Don't see the difference for routed/proxy-arping or bridged mode firewalls. > Getting nothing back instead of an expected response is still > a potential information channel. Getting information back from the wrong device gives you more information regarding the network. > > 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. Then enable it for internal and certain services that might cause all this additional traffic, and disable it for extrenal. But why are the internal device trying to connect to a service that is not supposed to be on the network anyway? I'm not talking about temporarily not available... > > 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. Damn... I know... but it's still worth robbing a bank from time to time. > > Your interface should be able to handle maximum traffic load. > > Maximum traffic load changes based on what traffic you must handle. A 100Mbit segment will never be 100Mbit anyway. > 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'll answer that later... it's not true though. > > 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. How to look at traffic you are not receiving? Or are all your switchports configured as monitporing ports? > > 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 Hmm... did I write this? damn... what was I thinking, sorry. > 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? Nope you're not missing a thing. My point was just that a bridged firewall is not a stupid bridge, and should only bridge traffic that has to go through it, not everything. And in a switched environment this is exactly what happens anyway. > 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. No it doesn't have to be. The switch port will learn the MAC addresses of the devices behind the firewall. > > 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. hostA --> router --> hostB if hostA sends traffic to hostB, whil hostB is down, hostA arps for its gateway to hostB since they are in different networks, which in this case is the router(firewall). hostA sends a packet for hostB, the router receives it and arps for hostB, hostB does not respond, router will send ICMP to hostA to tell host or service is not available. But, your first packet has already hit the router(firewall)! Same for proxy arping devices. Since in a bridged mode you do not have the ARP response, no traffic will flow, at least not through the firewall, except for the ARP. > > 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. Sorry, didn't have a better way to describe it. With active I mean if the firewall first checks if the destination it should proxy arp for is alive, before proxy arping. > 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.) That's a switch failure, not a firewall failure. > > I don't see why proxy-ARPing would be better than bridging, > > both look equally valid to me. > > Sometimes it's better, sometimes not. Exactly... _______________________________________________ Firewalls mailing list [EMAIL PROTECTED] http://lists.gnac.net/mailman/listinfo/firewalls
