On Tue, 16 Apr 2002, Schouten, Diederik (Diederik) wrote: > > 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.
Yep, but it again addresses "either you are detectable, or you are not providing as much protection." > > 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... It depends on how vulnerable the things that are supposed to be protected by the firewall are as it if you want it. In the case of a large enterprise, where control over the clients isn't very good due to network size, you may indeed want it. > 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. But again goes to detectability and level of protection. > > > 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. All of this, of course depends- for instance if one version of your product protected Windows boxes from URG problems, but the previous one didn't, then we might have a good idea. If your ISN generator had a specific pseudo-randomness level, the same, 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. The difference is that you said bridged mode firewalls were not detectable, nobody's claimed that of the other types. > > 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. Depends on what you mean by "Wrong device" I suppose, but getting stack info back consistantly from a proxy really doesn't give you more information about a 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... Lots of reasons, policies that don't allow protocols that people are trying to use, trojans trying to phone home, misconfigured systems... > > Maximum traffic load changes based on what traffic you must handle. > > A 100Mbit segment will never be 100Mbit anyway. Yep, but cutting down on the ammount of traffic you must handle is like having more bandwidth. > > > 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. I mean on a single segment- so that there isn't generally load sharing on say an internal network (not that such sharing is easy to do with a bridge. > > > 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 the one to the firewall is not, then you'd better have a limited number of devices on the far side of the bridge, or your switch is going to start to have issues with the number of MAC addresses it can track for that particular port. > 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. Depends on setup. > > 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. Are you confident that a switch will do that? For 1 device behind the firewall, it's a no-brainer, but what if there are 50? > > 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. Actually, it'll generally be several ARPs, which would have to be tuned on every device, where with a proxy/proxy-ARP device you could tune the number and timing of ARPs once at the gateway and get whatever performance you want (may be important for transactional systems using failover in some scenerios.) In either case, this is only true of the first packet ever, or after an ARP cache timeout. > > > 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. But again, only after an ARP cache timeout is this not what just happens anyway in both cases. > > > 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. Yes, but a bridged product allows such failures to happen through a security boundary (depending on configuration)- others don't. > > > 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... If we've gone to "pick the right type depending on what you need to do," then I'm happy. 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
