Firewall settings questions?

Trying out the new Jetico, so far so good here. A few questions though, do these things need network access?
winnt\sys32\mobsync.exe
winnt\sys32\wbem\winmgmt.exe
" "svchost.exe, winlogon, mstask, spoolsv, lexpps, services, and lsass(all .exe's)?

 

Anyone? security experts have no clue?

 

svchost may need access to the Internet, depending on what it is prompting for. You may be seeing prompts for the others as they may establish listening connections locally on your system, but should not need access to the Internet. Noting protocol, local service/port, remote service/port and remote address in the prompt will help you determine what is going on and what permission/rules will be required.

Regards,

CrazyM

 

Jetico will ask for permission for many things to "access the network", but this doesn't necessarily mean an outbound internet connection of any sort. You can give those programs network access without any problems... in fact they may need this "access" to function properly... You might want to ask Jetico support to explain the difference between "network access" and "internet access" in JPF.

 

I have written a test application to see what event triggers the "access to network" event in Jetico. So far I have found the following API calls: bind, and setsockopt. When a specific application calls one of these, an "access to network" event is generated for the application and for ALL parent processes of it. For example my test application is started from Total Commander, then I get a "access to network" event in these applications: explorer.exe, totalcmd.exe, and test.exe. Because explorer.exe is the parent process of totalcmd.exe, and totalcmd.exe is parent process of my test.exe. As you can see neither totalcmd.exe nor explorer.exe is doing any network activity. As far as I know this design is employed to beat the leaktests, and tricky trojans which start, and abuse a trusted application as a child process. The protection seems good, but imperfect because there seems to be a possibility of starting and abusing trusted applications withouth becoming a parent process for them.
Anyway this is a reason why almost any system application requires the right to "access to network": they are parent processes of other applications doing network access.
-hojtsy-

 

Assuming that the files are genuine Windows components and not trojans named to look like Windows components (see below for how to verify them), the following recommendations should apply:

mobsync.exe
Part of Internet Explorer - used to update webpages stored for offline access. Block this if you don't use IE or don't use this feature.

winmgmt.exe
Windows Management Instrumentation - used by system administrators to create Windows management scripts. Should not require network access on a standalone system.

svchost.exe
Requires access if you use Windows XP since it is used for DNS (domain name to IP address lookups) and DHCP (used to obtain an IP address on startup). Time Synchronisation, Windows Help (via HTTP) and Windows Update are also handled by this process so should be allowed if you use these features. Universal Plug and Play (and SSDP) is another function but UPnP has security issues so is best blocked unless you really need it. This also handles DCOM (Port 135) which must be blocked to avoid infection by RPC/DCOM worms like MSBlast.

A detailed ruleset for svchost.exe is given in section E2 of A Guide to Producing a Secure Configuration for Outpost - it should be straightforward to adapt these to any other rules-based firewall.

For Windows 2000 on a standalone system, this can be blocked (services.exe does DNS and DHCP instead).

winlogon
Handles Windows logins - for a standalone system this has no need for network access so should be blocked.

mstask
The Windows scheduler - for a standalone system this has no need for network access so should be blocked.

spoolsv
Windows Print and Fax service - this should only need access if your printer or fax is accessed via a network.

lexpps
Lexmark Printer Port Scanner - if you have a Lexmark printer on your network then allow this, otherwise block it.

services
For Windows 2000, this needs access for DNS and DHCP.

lsass
Local Security Authority Subsystem Service - handles Windows security and access control. For a standalone system this has no need for network access so should be blocked (indeed, if LSASS is requesting network access, this could be an indication that your system has the Sasser worm or something similar).

Checking that files are genuine
Since a number of trojans do use similar or identical filenames to some of the above processes, it is worth performing further checks before allowing network access. The most likely indication of a malicious file is in its path - the above files, if legitimate, should be held within the Windows \System32 folder.

There are a number of websites providing further details on individual files with Microsoft's DLL Help Database being a key resource. More details (and links) can be found in the 4.0 Resources section of Manny Carvalho's Component Control in Outpost 2.5 FAQ at the Outpost forum.

 

Well, Jetico seems to work a little different from other firewalls. Disabling Lsass etc. from access to network stopped my Firefox from being able to connect to the web

Its all very new, strange and mysterious to me

 

Looking at Hojtsy's post above suggests to me that Jetico's handling of network access could be a problem. If you have to allow lsass.exe access for normal use then you will get no indication (from Jetico at least) if it has been Sasser'ed.

 

By default Jetico has a rule that gives lsass.exe network access. It does not give lsass.exe permission to send or receive on any protocol or port.

 

smss.exe, winlogon.exe, services.exe, svchost.exe are all parent processes of several other processes which will do network communication, so you have to Allow the "access to network" event for them.
But this does not mean a lowered security as suggested by Paranoid2000. The "access to network" event is only the first level of permissions required to actually transmit data. It does not mean that the process has unlimited access withouth further checks. The "access to network" event is generated when the socket is binded, the software in question is not yet communicating. When the data is attempted to be sent with an other system call, a new event is generated "outbound connection". This event goes again through the whole rule chain, and may be allowed or blocked. If it is allowed the data is permitted through to the network layer where a new event will be generated "outgoing packet", which will again go through the whole rule chain. Different events have different parameters which could be used as filters in the rules. For example "outbound connection" event contains the protocol, IP addesses, ports, application name. But "outgoing packet" event contains protocol, IP addreses, ports, TCP flags, packet checksum validity flag, etc. Now since the applications smss.exe, winlogon.exe, services.exe, svchost.exe should only have the absolutely required permissions regarding the "outbound connection" event, even if a trojan would be able to hijack them (defeating the process sandboxing features of Jetico) the trojan would not be able to gain an outbound connection withouth a specific firewall rule matching their communication attempt. Likewise for the inbound connection.

please tell if I was not clear enough,
-hojtsy-

 

Exactly. But I afraid not everybody understands what is mean to be "access to network" by this firewall.
-hojtsy-

 

I'm learning

 

Thanks

 

I run win2k and on my home network too, can I still block this?

 

Thanks for the explanation - but if the "access to network" event does not actually allow the sending or receiving of data, what is the point of it? It would seem an unnecessary extra (and confusing) step.

While the extra filter criteria look interesting, having multiple filter levels would seem to make configuration far more complex than it need be - is Jetico trying to outdo Tiny here?

If it is the "outbound connection" filter that controls network access, why have an "access to network" filter in the first place?

 

Almost certainly yes - but the answer depends ultimately on your PC and network configuration (what services are you running, do you have an Active Directory domain?) so a definitive answer is not possible. Why not try blocking svchost and see what happens?

 

Hold on. The "access to network" may confuse you but it took ten times less effort for me to understand the rule structure and design of Jetico then in the case of Outpost.

You should rather compare it to LnS. Imagine that you leave alone the network rules of LnS, but give steroids to the application rules in LnS, so they become the fully configurable (application) rules you can see in Kerio 2.x. There you have the two levels. It is the very same thing what I have seen some users requesting on the LnS forum.

Let me dive into a lengthy explanation.
Firewall type 1)
They work only on the network level, so they can catch
-packets of non-IP protocols
-packets with invalid/hostile TCP flags, or
-fragmented packets,
-invalid checksums,
-packets not fitting into the actual state of the TCP connection
-packets from/to specific ports/ips

Firewall type 2)
Other firewalls are rather authenticating the API calls made by the applications. These can catch
-packets from/to specific ports/ips
-packets from/to specific local applications

Now modern firewalls try to be both 1) and 2), but they have two choices: either they design, implement and display 1) and 2) as two separate modules (such as LnS and Jetico), or they somehow fuse them together (such as Outpost). In both cases there is one more hole to cover: how to stop untrusted applications from abusing trusted applications to go around the firewall? Ususal solution is that the firewall authenticates each application starting other applicaion, even in the case none of the two applications will do network communcation. (example for this is Kerio 4.x) Some people (notably gkweb) think that this is not the proper way a firewall should handle abuse of trusted applications. Rather the firewall should only spring into action when a communication attempt is made, and authenticate all the applications which took part in triggering the communication. So for example if a trojan attempts to start iexplorer it should be allowed. Only when iexplorer attempts to communicate should the firewall authenticate both iexplorer AND the trojan as an application permitted to "access to network".
You can now see that the "access to network" event mostly replaces the "allowed to start other application" event which is not handled by Jetico.
And I have never heard anybody complaining that the "allowed to start other application" permission is redundant to "outbound connection".
If you are not interested in blocking leaktests, it is very easy to create a single rule to allow the "access to network" event for everybody. It would be simmilar to the two (fully modifiable/ removable) rules in the default ruleset which allow creation of listening sockets for every application.
-hojtsy-