in which people seemed knowledgable, it raised a question in my mind that I’ve never seen addressed. The question: where in the networking reference model does ZA monitor traffic?
The background, prefaced with a slight digression:
With the proliferation of the latest rounds of MS worms, I’ve seen the use of the built-in XP firewall recommended. However, the guy who maintains our department’s network (I’m a grad student in computer science) pointed out that during boot-up, the firewall isn’t activated until after start-up completes, leaving your computer vulnerable for however long that is. (Granted, not for very long - but it’s still vulnerable. And, of course, this is beyond the fact that the XP firewall doesn’t detect traffic originating with the system.) Which brought the question about ZA back to my mind.
More than a year ago, a fellow grad student and I got into a discussion about firewalls, and he mentioned that he was running ZA on a Windows box he was maintaining. Although I forget the details, he mentioned that he noticed that ZA did not pick up network traffic below the application layer. In other words, the implication is that one could write a program that circumvented ZA’s protection by intercepting communications closer to the hardware layer. (Of course, there’d still be the issue of getting it installed on someone’s computer, but that’s another thing…) Since his research concerns network intrusion, I’m assuming he wasn’t just dicking with me.
Until I switched to Linux, I used ZA on my computer and found it to be more than adequate. I recommend it to anyone I know that uses Windows. But I like to know any weaknesses in my recommendations. Does anyone have any info on this?
You’re saying below the application layer? As in the Presentation or Session layer? My guess is that those items don’t really have anything to “exploit”, as they are not related to the OS and are pretty cut and dried. I mean, let’s look at the layers:
Physical: You would have to send some sort of signal that takes advantage of an exploit or flaw or shortcoming in the Ethernet interface (card) itself.
Data Link: Screwing with the Media Access Control or Logical Link Control is not likely to get you anywhere directly. However, a man at the UC Davis wrote an interesting paper on this subject:
He states that an example of a Data Link exploit is a DOS or “Denial of Service” attack. Which, it is true, ZoneAlarm cannot defend against. Nor, for that matter, can most firewalls really.
Well, I know that this isn’t quite true, although it very well may be true for Windows systems. Which, I suppose is an extension of my question. On Linux systems, the iptables firewall software is part of the kernel, so it intercepts traffic below the application layer. Which allows you to do things like network address translation in software.
Ah, thank you. A clear and concise summary of what I was looking for. Now I just wonder how ZA actually operates…so, I went to the ZA site (duh! Why I didn’t check this originally is beyond me), and found the following:
which leads me to believe that there is some kind of tripwire-like software included (at least with ZA Plus). So, without any actual knowledge of the internals of ZA, I’d say that the basic package does work at the application layer, but does not handle traffic below.
Thanks for the responses, everyone. (And the brief intro on using URL tags in a post.) I’d appreciate any other information regarding ZA specifically.
Zone Alarm would have to work at about the place that inetd does under a Linux system.
inted listens on all ports for incoming packets, and routes them to the required service demon - starting it if neccessary. This is definitely application level stuff.
I don’t think ZA does any kind of tripwire stuff. It simply twigs that a program wants access to the Internet and asks you what to do. If you say “let it through,” then ZA generates a checksum of the program wanting through and hold on to it for future reference. The nect time that same program wants on the net, ZA generates the checksum again and compares it to the value it already has - if they don’t match you get asked again and maybe warned that your program has changed.
Truthfully, there’s not much a firewall can do against a simple DOS attack. If someone floods your connection from the outside, then there will be a point at which none of the data you need will get through for all of the crap coming at you.
There are some DOS attacks that depend on exploiting a bug in the OS to knock the system out rather than just flooding it with crap - and those can be stopped by a firewall.
The iptables firewall software operates below the Data Link layer to prevent DOS? You do realize that means it must operate on the Physical (hardware, aka Ethernet card) level, right? How exactly does it do that?
IIRC, Windows can do NAT via software too. At least XP can, IIRC. But it’s not doing this at the physical layer either.
Yeah, zone alarm operates at the application level. It deals strictly with application access and ports. That’s expected and perfectly functional for the sort of role it performs.
I’m not sure what you/your friend means by “In other words, the implication is that one could write a program that circumvented ZA’s protection by intercepting communications closer to the hardware layer.”
I’m not sure how something would go about “circumventing” the application layer - it’s an integral part of any sort of network communication. As for intercepting communications - perhaps you meant something else as a firewall isn’t used to prevent communications from being intercepted as such.
This was my first thought too. However, I don’t think the OPer’s friend meant the OSI application layer, but instead meant that Zone Alarm is running in Window’s user-mode (where applications run) as opposed to kernel-mode.
I don’t have ZA installed on my machine, so I can’t tell for sure. But I have been meaning to put it on anyway. Until then, my WAG:
There is a ZA kernel-driver that inserts itself into the network driver stack just above the NIC driver. These drivers used to be called LAN miniport drivers - not sure if they still are under WDM. ZA also has a user-mode application that is used to configure and control the kernel-portion.
If this is the case, then ZA gets plumbed into the stack early in the boot process and can start its protection even before some other drivers start. This jives a little with my experience, since I do get ZA messages late in the boot process.
Also if this is the case, it would be hard for an application to bypass ZA since it wouldn’t be able to use the normal network stack. That’s not to say that an application couldn’t re-configure ZA or take advantage of a bug in ZA or Windows itself. I am far from a security expert and I suspect that there are ways for applications to get out. I supose that a malicious app could install a second NIC driver to send stuff out. Not sure how well this would work.
Remember, this is my WAG. I will try installing ZA and see if I can tell for sure either way.
No program you run on your computer -and no hardware you put in your casual-use personal computer- can ever stop a DoS.
If your end of your network connection (‘wire’ or ‘pipe’) is saturated, then so is the other end of that particular pipe. Now nothing you do on your end will keep the other end of the wire from being too congested to allow packets through in a timely fashion. Nothing you run on your computer can block packets before they reach your computer
Admittedly, if you’re running a very underpowered computer which can barely handle incoming packets at your full connection speed, or if you are running a server (especially one that uses heavy database or processing functions vs. just passively serving HTML) then certain software can block any DoS packets it detects, and help you increase the degree to which you bog down. This doens’t apply to most people, and even then, it’s often just a matter of degree, since most DoS’s I see these days are DDoS’s - and therefore can saturate your pipe withthe output of many pipes… taking you back to Square One, above
I’ve thought about this for a while, and I can’t think of anything that will cure a DoS (DoS in this post encompassing DDoSes and any DoS-like attacks). The best you can do is weather it without crashing.
Think of it this way: A DoS attack is a flood of junk information down a specific pipe to a specific machine. Since TCP/IP allows (and must needs allow) unsolicited communications between machines, there’s no way for the victim to `turn it off’. At worst, the pipe is saturated with the attack’s crap and the victim cannot even send a packet out for want of time between incoming packets. The network is worthless, and the best thing the victim can do is to turn off all services until the firewall notices a significant decrease in packet volume. In other words, batten down the hatches until you no longer hear the hailstones battering against the walls. Better, perhaps, would be to turn off even the firewall and kill the connection completely. But that suffers from the notable defect of rendering you unable to resume connectivity in a timely manner once the flood is over.
Will ZA help against a DoS attack? I seriously doubt it. It takes computational effort to even drop a packet, and if packets are coming constantly your CPU will be overwhelmed with the task of dropping them. But that’s a worst-case scenario most desktop users probably won’t have to worry about.
Sorry if I wasn’t clear enough in not saying I wasn’t speaking to DDOS attacks. Of course there’s no way a mere firewall can prevent being DDOS’d - it’s an attack from outside the system, and all you can really do is drop packets as fast as possible. I’m more interested in preventing hacking a box. Whether ZA “sat” in Windows user-mode is exactly what I meant. For instance, if it were possible for a program to “intercept” (for lack of a better term, as there seems to have been an issue with the term) packets before they even reached ZA. Say, based on the IP of the originator (although, of course that’s awfully brittle). More specifically, if a packet came from 192.168.0.0 (yes, I know it’s an invalid internal IP; it’s an example), process the contents of the packet directly without passing it up the layers. If ZA was operating in a layer above this program, it might never receive the packet and therefore would not be triggered.
I didn’t know about the ZA kernel-driver, which sounds like what I was wondering about. Do you happen to know if this is a recent thing or if ZA always operated like this? Perhaps newer versions of ZA handle this whereas older versions didn’t. Alternatively, my friend could’ve just been screwing around with me. Or he could’ve been flat-out wrong. Thank you very much for the responses…
I’m not an expert, but I don’t think a packet can really be “acted” on at the lower levels - everything from physical to session is really organizing the data to be usable to an application. A usable packet would have to be addressed to a specific port, so to “get through” to anything, it would have to pass through zonealarm’s port list. That’s my understanding, anyway.
