Re: Zone Labs Pro question
From: David (davidwnh@adelphia.net)
Date: 03/16/03
- Next message: Duane Arnold: "Re: linksys ftp problem"
- Previous message: Ram Samudrala: "Security issues with regards to wireless networks..."
- In reply to: mhicaoidh: "Re: Zone Labs Pro question"
- Next in thread: mhicaoidh: "Re: Zone Labs Pro question"
- Reply: mhicaoidh: "Re: Zone Labs Pro question"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: "David" <davidwnh@adelphia.net> Date: Sun, 16 Mar 2003 03:38:30 GMT
The problem is that a lot of these components name themselves similar to
normal windows components. So if you don't look at the specific directory
that the component is in someone might be led to believe something is not
what it truly is. Case in point, the particular trojan the OP recently
contracted has a file called explorer.exe which is the mIRC client. You may
think it is always the user "inviting disaster" but this is not necessarily
the type of thing many if not most users are going to catch.
Since the real explorer has internet capabilities built in to it, it seems
to me many people might inadvertently let this one through. So you can
diddle around checking all your application settings which is a good idea in
any case, but if you miss something the first time there is a good chance
you may miss it again. Not everyone has the time or interest to keep abreast
of every new vulnerability that hits the street, so the solution lies in not
putting so much reliance on the user's interaction with the application
control. If someone who doesn't use IRC simply blocks the IRC ports at the
zone level, above and beyond the application control settings, then even if
something socially engineers itself past your application control it still
can't "phone home" if it uses an IRC client to do so. And this applies to
any client-side phone-home malware application in which you don't need to
use the specific destination port that they use. If you explicitly block
ports you have no use for at the zone level your risk level can be
appreciably lowered, and the assumption that all approved applications are
always trusted no longer applies.
When you read the help files you can be somewhat mislead by its statements
about security zones. In all three levels of the security settings most
outbound and inbound solicited traffic is controlled in the same way;
mostly via your application control settings only. The ports and protocols
that are being protected "above and beyond" your application protection
settings are only the ones listed in the custom firewall settings for each
zone. This includes NetBIOS, ICMP, DNS,DHCP, IGMP, and maybe a couple others
I am not currently thinking of. A good example of this is NetBIOS lookups.
The same OS component that does DNS lookups also does NetBIOS lookups. So if
you didn't have the ability to override the application settings you would
not be able to easily allow DNS lookups while at the same time block NetBIOS
lookups if disabling NetBIOS all together is not an option. You could go
into every application setting and specifically deny outgoing traffic to
port 137 for each individual program to be sure, but ZoneLabs has made this
easy by allowing you to select a security level and further allowing you to
adjust specific custom settings so that you can control certain things on a
per zone basis as opposed having to deal with everything on a per
application basis.
The outbound blocked ports setting takes this one step further. It allows
the end user to specify additional ports to block on a zone wide basis,
irrespective of any application settings.
So if you add your own specific ports to the blocked outbound lists in the
custom settings you add control that goes above and beyond what the
application control does and end up blocking things at the zone level as
opposed to relying solely on the application control. For whatever reason
they put the control to block outbound traffic for additional ports under
the medium security heading in the custom settings dialog, but the fact is
when you are dealing with outbound TCP and UDP traffic on ports that are not
specifically addressed with some of the other settings that are there, these
settings apply to all of the default security levels whether it is
high,medium or low.
> Strictly speaking, they are blocked for both inbound and outbound
> traffic by default in a null state. But, as you point out ...
Strictly speaking they are not. Inbound unsolicited traffic is mainly
blocked according to the security level, however, all outbound and
solicited inbound(replies) traffic is mainly controlled by your application
permissions unless there is further restriction imposed by the custom
settings for the specific zone. Some ports are blocked to outbound and
solicited inbound traffic regardless of application settings depending on
the security level, but it is only for the five or so specific protocols
shown in the custom settings(which you are allowed to modify). The rest of
the ports are wide open to freely be use by any approved program unless you
further restrict their use on a zone wide basis in the custom settings. Its
all about adding port filtering at the zone level because the application
control is easily breached. Most good application gateways have port
filters, as does this product but I don't think most people even realize
they exist. And ZA allows you to do it on a per application and/or per zone
basis. Basically the default settings are terrible because they put all the
reliance on the user being able to identify which applications are trusted
from the start, but by using port blocking in both the application settings
and the custom zone settings for the firewall you take some of that reliance
away.
Sure you can engage the internet lock and you can redo your program
permissions. Both good ideas. If you approve something to start with I guess
you have maybe a fifty percent chance of catching it the second time? Maybe
even a better chance than that after reading this NG and others? The odds of
catching a mIRC trojan that is already there or any other that may
inadvertantly get there in the future are much better if you explicitly
block all traffic from using the specific ports all the time if you don't
need them.
All in all nobody "invites" disaster. In some respects and to various
degrees these products are meant to keep all users from creating their own
little disaster. That is why they can filter what goes out as well as what
is trying to get in. So you can take the low road and blame it all on
ignorance or you can take the high road and realize that not everyone has
the time or interest to keep abreast of certain issues, and that the problem
really lies in the fact that these personal firewall's don't fully address
the requirements of their targeted audience. These programs are supposed to
make things easier and less time consuming as well as safer, without
requiring a huge amount of insight as to how they work. And at this stage of
the game most of them don't. So if you take the low road you may never
figure out the not so obvious solutions for yourself, and you may end up on
the other side of the fence with your foot in your mouth.
>
> The best security in the world isn't going to help someone who invites
> disaster. One thing he could do is engage the internet lock, and see if
> anything is communicating on those ports. Additionally, he could go in
and
> remove any program entries he is not absolutely sure about ... causing
them
> to re-apply for permissions.
>
- Next message: Duane Arnold: "Re: linksys ftp problem"
- Previous message: Ram Samudrala: "Security issues with regards to wireless networks..."
- In reply to: mhicaoidh: "Re: Zone Labs Pro question"
- Next in thread: mhicaoidh: "Re: Zone Labs Pro question"
- Reply: mhicaoidh: "Re: Zone Labs Pro question"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
