Jetico fw. Access to network requests - from apps that should never need a connection

[birdofprey]

I couldn't replay to this thread (http://www.wilderssecurity.com/showthread.php?t=62970) so I'm quoting from it.
{QUOTE-> Lets consider that you start Internet Explorer after a new install of Jetico Firewall. This chapter will cover what kind of events will be generated, and how will those events be processed by the ruleset.
If your default page in iexplorer is empty, no event will be generated. Then you enter into the address line www.wilderssecurity.com. iexplorer creates and binds a new TCP socket. This results in a chain of "access to network" events, first coming to the parent processes of iexplorer, and then iexplorer itself. If you started iexplorer from the desktop, then it's only parent process is explorer.exe. <-QUOTE}

Why would any parent processes request/need access to network ? :( ???

I'm asking this because I just stopped using my app launcher because I thought it was requesting access to network in order to call home through my browser. It never attempted to send packets directly though. And when I blocked it, my browser couldn't get a connection anymore. So how can I check whether my launcher is really a trojan or not ? Or how can I check whether it tries to pass information to firefox ? I really miss the program.:(

One more question, does this "network" include 127.0.0.1 as well ?

Thank you :)

[Seer]

Hello there :)

This is a HIPS feature, has nothing to do with actual network connections. Basically, "access to network" is a warning on POSSIBILITY of a process to do network connections through a parent process.
Jetico will warn on any subsequent network connections on IP address as well as the port number. There is nothing to worry about, your app launcher is connecting only if there is a warning on "network connections" (network activity table rule).

{QUOTE-> And when I blocked it, my browser couldn't get a connection anymore. <-QUOTE}

I agree that this is not the happiest solution from Jetico developers (a bit too paranoid).

Cheers.

[Stem]

Hi birdofprey,
{QUOTE-> Why would any parent processes request/need access to network <-QUOTE}

{QUOTE-> > "access to network" is network subsystem initialization for current process. Win32 equivalent is WSAStartup() call - socket library initialization. If "access to network" is disabled, application will not be able to create sockets and all communications, including local sockets will be blocked.
Next, JPF recognizes both direct and indirect access to network. Indirect access means that an application forces another application to perform all network-related work. JPF treats both direct and indirect access as "access to network". Thus if application X tries to send data via Internet Explorer and you do not allow application X to perform "access to network", Internet Explorer will fail too. <-QUOTE}

[birdofprey]

{QUOTE-> Basically, "access to network" is a warning on POSSIBILITY of a process to do network connections through a parent process. <-QUOTE}

By definition I'd say... It's a warning on a possibility. But isn't that enough ? I mean if it's possible... some program might do it.

Ok so the launched program will do a connection through the parent app? I thought it was the other way around.

Thanks for the quick answer but I still have no answer on my question: Why would any parent processes request/need access to network ? What's the mechanism behind this ?

{QUOTE-> And when I blocked it, my browser couldn't get a connection anymore. <-QUOTE} {QUOTE-> I agree that this is not the happiest solution from Jetico developers (a bit too paranoid). <-QUOTE} I didn't say I'm dissatisfied with the feature, I only wish I'd understand it completly. And after I closed my app launcher, everything went back to normal... I think...

{QUOTE-> your app launcher is connecting only if there is a warning on "network connections" <-QUOTE} If that's true, and it really can't use a trusted app through this "access to network" thing to broadcast instead of it... then I'll start using the program right away.

[birdofprey]

Hi everybody and thanks !

Stem, you shed some light on things. I still have a few other questions though, cause I simply don't see how that "thus" fits into your post.

{QUOTE-> Thus if application X tries to send data via Internet Explorer and you do not allow application X to perform "access to network", Internet Explorer will fail too. <-QUOTE} Why ? HOW ? What's the mechanism/logic behind this ?

Is x a parent or a sibling ? Does it even matter ?

[Stem]

Hi birdofprey,
{QUOTE-> Why ? HOW ? What's the mechanism/logic behind this ?

Is x a parent or a sibling ? Does it even matter ? <-QUOTE}If for example, the parent of the browser is a "bad" application, then the "bad" application could attempt connections via the browser. Jetico looks at the chain of events, so if you block the "bad" application, it will then block the browser (untill the "bad" app is terminated/out of memory)

[birdofprey]

Oh ! I see. So it's not a system/background thing. It's just Jetico being smart enough to... but wait a minute, what's a bad application ? Those I chose not to allow to gain "access to network", right ? So if they can't access the network, then there is no "chain of events"... and no need to block my browser unless, Jetico is not really able to deny access to the network and has to deal with the problem this way instead. If this is true, then this is really not the happiest solution at all, and have to say I am dissapointed. Is v2 better ?

Btw. In short could somebody tell me how v2 is better than v1 ? After I decided to switch from Sunbelt Kerio, I tried LnS, Comodo, and it seemed to me that I'd be happy with Jetico v1... I hope there aren't any more surprises like this, are there ?

[lucas1985]

{QUOTE-> I hope there aren't any more surprises like this, are there ? <-QUOTE}
In Jetico v1, changes of hashes (i.e. an application is updated) may be a nightmare: new rules are created and the old ones don't disappear. The best solution (IMO)? Build tables for each application.

[birdofprey]

Thanks for the warning lucas1985 and yeah, power to the imagination ! :)

I assume that my speculations in my previous post are correct... :(

Anyhow I slept over things and I realised this morning that I still don't have the whole picture :) {QUOTE-> "access to network" is network subsystem initialization for current process. Win32 equivalent is WSAStartup() call - socket library initialization. If "access to network" is disabled, application will not be able to create sockets and all communications, including local sockets will be blocked. <-QUOTE} ...but only for this current process. The reason behind mass blocking is a Jetico "feature" ;D Right ?

Now, this app launcher of mine, has no auto-update feature so it never asked for any direct connections. So let's focus on indirect connection attempts. I still don't get why the parent process gets involved in this in the first place.

{QUOTE-> This results in a chain of "access to network" events, first coming to the parent processes of iexplorer, and then iexplorer itself. <-QUOTE} If iexplorer is in need of a socket, how does explorer get into the picture? Another Jetico feature ? Or is it the way windows works ?

[birdofprey]

Ok maybe I bored you to death with my endless questions and I appreciate the fast replies from you all but, I'm still here wondering about what's really going on. Maybe someone who understands things better could ask the right questions for me...

[lucas1985]

I'm not bored (if you were referring to me) by your questions :)
I don't know the inner workings of Jetico.
Maybe asking in the official forums (http://www.smokey-services.eu/forum/viewforum.php?f=52&pc_tzo=-10800&pc_d=20070825&pc_t=65974) may help you further.

[kr4ey]

{QUOTE->

One more question, does this "network" include 127.0.0.1 as well ?

<-QUOTE}

Yes. In Jetico your computer is direct and indirect access to network, so anything that needs access to your computer will alert you. If you block it, it won't work.
Direct and indirect access to network is not the same as network activity in Jetico. Network activity is for your outbound and inbound network (Internet).


{QUOTE->
Quote:
> "access to network" is network subsystem initialization for current process. Win32 equivalent is WSAStartup() call - socket library initialization. If "access to network" is disabled, application will not be able to create sockets and all communications, including local sockets will be blocked.
Next, JPF recognizes both direct and indirect access to network. Indirect access means that an application forces another application to perform all network-related work. JPF treats both direct and indirect access as "access to network". Thus if application X tries to send data via Internet Explorer and you do not allow application X to perform "access to network", Internet Explorer will fail too.
<-QUOTE}

Very good explanation.


{QUOTE-> I hope there aren't any more surprises like this, are there ? <-QUOTE}

Been using Jetico for years and I never saw any suprises. Its the way Jetico works.

[birdofprey]

I wasn't refering to anybody actually... :) I guess it's sort of a linguistic barrier thing :)

That forum is a good idea. THANKS!

[birdofprey]

kr4ey, thanks for your effort, but you really don't need to quote a previous post. Yes, Stem's answer was great, and it helped me get further but not far enough. I read it. I got it. I quoted from it my self.

But to you that means probably more than to me... cause you know more about it, and the rest around it, I mean the topic. When you probably look at it, you see something you know by heart, I on the other hand see new information, and something more... that there's something still missing from it. I tried to figure what, hence these questions, but it seems they don't inspire you the right way. I mean, as far as I see, from your point of you, I have all the answers I needed... unfortunately that's not true. Anyhow, again, I apreciate you tried, it's all you can do. I on the other hand will have to dig deeper. Until then, I'll just click allow :)

[ggf31416]

{QUOTE-> Ok maybe I bored you to death with my endless questions and I appreciate the fast replies from you all but, I'm still here wondering about what's really going on. <-QUOTE}

My english is bad, so I hope you understand me

"Access To Network" allows the program to connect to the trusted zone , "use" global rules and connect indirectly. For direct connection attempts the program needs "Access to Network" + a rule allowing inbound/outbound connections from/to the specific Port and Address.

Example:
A) myprogram.exe attempts to connect to www.example.com (123.456.789.1:80)
1) "Access to Network" for myprogram.exe
2) "Outbound connection" to 123.456.789.1, Port 80

B) myprogram.exe calls Internet Explorer to open www.example.com (Indirect attempt)
iexplore.exe www.example.com
1) "Access to Network" for myprogram.exe
2) If you don't have rules for iexplore.exe Jetico will prompt you about "Access to Network" and "Outbound Connection" to 123.456.789.1, Port 80, for iexplore.exe.
However if you use Internet Explorer usually you already have rules allowing access to network and outbound connections to Any IP, Port 80. In that case the only prompt you will get is "Access to Network" for myprogram.exe

[kr4ey]

{QUOTE-> kr4ey, thanks for your effort, but you really don't need to quote a previous post. Yes, Stem's answer was great, and it helped me get further but not far enough. I read it. I got it. I quoted from it my self.

But to you that means probably more than to me... cause you know more about it, and the rest around it, I mean the topic. When you probably look at it, you see something you know by heart, I on the other hand see new information, and something more... that there's something still missing from it. I tried to figure what, hence these questions, but it seems they don't inspire you the right way. I mean, as far as I see, from your point of you, I have all the answers I needed... unfortunately that's not true. Anyhow, again, I apreciate you tried, it's all you can do. I on the other hand will have to dig deeper. Until then, I'll just click allow :) <-QUOTE}

No problem. Just trying to give a easy example to how Jetico works.
When I first started using Jetico it was hard to figure out.
But, IMHO it is one of the best firewalls. And that goes for both versions.

[ggf31416]

I think Jetico attempts to intercept some "OLE Automation" attempts. However the detection is not very reliable and there are some false positives. Comodo 2.3.* had this problem too but it was more frequent and easier to notice as the scared users were receiving constant prompts about an application hijacking another.
Also take into consideration that some attacks may trigger an "Access to Network" prompt.

[birdofprey]

Oh no ggf31416, I got that part already ! :)) I mean your first post said nothing new to me, and I can't do anything with your second one, since you're not sure about it, but again thanks for at least trying.

kr4ey, I used a rule based firewall before trying out Jetico, so I can't complain, and I'm getting used to it. And yes, it seems to be one of the best, I like it... and am not alone. But again, I got what you explained from the previous posts already...

I'm starting to hate to let you down like this. I'll try those forums and fill in the blanks my self, I'm sorry if I'm not clear enough, really.

Again, thank you.

[kr4ey]

OLE/COM communications, process code/memory modifications were
just implemented in newest version of Jetico 2 and I have not seen any
attempts of hijacking or false positives. And no attacks that trigger access to network prompts.

[Stem]

Hi birdofprey,
{QUOTE-> If iexplorer is in need of a socket, how does explorer get into the picture? <-QUOTE}You would need to take time to look into windows sockets (winsock), its extensions and implimentations, (as example, with the winsock extensions, the winsock API is integrated with windows messages). You would also have to look at (one example) thread creation, which could be classed as local sockets, which is all caught up into the windows API.

[wat0114]

{QUOTE->
Example:
A) myprogram.exe attempts to connect to www.example.com (123.456.789.1:80)
1) "Access to Network" for myprogram.exe
2) "Outbound connection" to 123.456.789.1, Port 80

B) myprogram.exe calls Internet Explorer to open www.example.com (Indirect attempt)
iexplore.exe www.example.com
1) "Access to Network" for myprogram.exe
2) If you don't have rules for iexplore.exe Jetico will prompt you about "Access to Network" and "Outbound Connection" to 123.456.789.1, Port 80, for iexplore.exe.
<-QUOTE}

This does not mean myprogram.exe actually connects to 123.456.789.1, port 80 does it? iexplore.exe connects to it, with myprogram.exe somehow influencing iexplore.exe as a parent process, correct? I'm new to this fw so I am still trying to come to grips with how these "access to network" and "indirect access to network" rules work. I know the indirect access to network has been a bone of contention in the official Jetico forum.

[SamSpade]

{QUOTE->

Been using Jetico for years and I never saw any suprises. Its the way Jetico works. <-QUOTE}



Your sig shows you are using Jetico 2. I'm using Jetico 1. Can you cite the advantages for 2 over 1?



....................... (pause) ...........




Yeah, you're right: lazy question. ( :-) )

So I loaded the latest version of Jetico 2 and it seems nice, more robust and thorough than JPF 1. It's clean, simple, no-frills (with commensurately less drag on resources). So far so good.



//

[Vulcan_]

{QUOTE-> Hi birdofprey, <-QUOTE}

Stem, I have some quick questions about JPFv1. Could you confirm this information below and correct any inaccuracies. I think this information would help some people to understand which windows processes can be tamed, without worry of dialing home to Microsoft.

JPFv1 definitions:

"local sockets" = 127.0.0.1/loopback, all local ports that do not attempt an outbound connection to an external IP.

"access to network" = 127.0.0.1/loopback, all local and remote ports including outbound connections to external IP.


Assuming this is accurate, most "system applications" (windows processes) can be configured to "local sockets" in most rules. This would restrict those windows OS processes from outbound connections, but not cause JPFv1 to block traffic of other programs that have dependencies on system processes.

Programs like DU meter should therefore be configured to "local sockets" instead of "access to network".

One other question I had, which I may have missed in the 30 page Jetico thread. Does JPFv1 HIPS correctly scan applications using proxies over 127.0.0.1 such as Tor/Privoxy/Vidalia ?

Vulcan

[Stem]

{QUOTE-> "local sockets" = 127.0.0.1/loopback, all local ports that do not attempt an outbound connection to an external IP. <-QUOTE}I would be interested to see how you can create a rule with such an event.
{QUOTE-> "access to network" = 127.0.0.1/loopback, all local and remote ports including outbound connections to external IP. <-QUOTE}This basically allows access to any open rule within the ruleset (including the trusted zone). Any application attempting direct internet connection (not allowed within the ruleset) would cause a popup.
{QUOTE-> Assuming this is accurate, most "system applications" (windows processes) can be configured to "local sockets" in most rules. <-QUOTE}Please post a screenshot of a rule where the "Event" is "local socket"
{QUOTE-> One other question I had, which I may have missed in the 30 page Jetico thread. Does JPFv1 HIPS correctly scan applications using proxies over 127.0.0.1 such as Tor/Privoxy/Vidalia ? <-QUOTE}I am not completely sure what you mean by this.

With default installation of Jetico the localhost(loopback) is added to the trusted zone, if a localhost proxy is in use then any application with access to network can access the trusted zone, therefore access the localhost. To correctly protect from this, you would need to remove the localhost entry from the trusted zone (and block the jetico configuration wizard (fwsetup.exe) from "access to network", so that this will not be automatically added again). You would then set up rules (or a ruleset) to give access to the applications for the localhost.

[Vulcan_]

{QUOTE-> I would be interested to see how you can create a rule with such an event. <-QUOTE}
I'll probably end up re-installing JPFv1 in a couple of days. When I tried it out JPFv1 a few days ago, I restricted most windows process dependencies required for Mozilla Firefox to "local sockets". I was successful in passing most web browser traffic with that configuration. From what I recall Jetico's documentation for JPFv1 does not explicitly define what are considered "local sockets". This was why I hoped you might have a better understanding of what the firewall allows under that configuration.

{QUOTE->
This basically allows access to any open rule within the ruleset (including the trusted zone). Any application attempting direct internet connection (not allowed within the ruleset) would cause a popup.
Please post a screenshot of a rule where the "Event" is "local socket"
I am not completely sure what you mean by this. <-QUOTE}
"local sockets" is not selectable from "Event" alert messages, but it is a selectable option if you manually configure a rule for an individual process from the Firewall tree.

{QUOTE->
With default installation of Jetico the localhost(loopback) is added to the trusted zone, if a localhost proxy is in use then any application with access to network can access the trusted zone, therefore access the localhost. To correctly protect from this, you would need to remove the localhost entry from the trusted zone (and block the jetico configuration wizard (fwsetup.exe) from "access to network", so that this will not be automatically added again). You would then set up rules (or a ruleset) to give access to the applications for the localhost. <-QUOTE}
Thanks,

I don't have JPFv1 installed at the moment, but hopefully that shed's some light on how to correctly configure JPFv1 rules with Tor/Vidalia/Privoxy.

[Stem]

{QUOTE-> "local sockets" is not selectable from "Event" alert messages, but it is a selectable option if you manually configure a rule for an individual process from the Firewall tree. <-QUOTE}Where?

193141

Are you thinking of "Protocol"?

193142

[Vulcan_]

{QUOTE-> Where?

193141

Are you thinking of "Protocol"?

193142 <-QUOTE}
Yes you are correct I was thinking of "local sockets" under Protocol.


Event: either "any" or "access to network" was selected
Protocol: "local sockets" was selected for certain windows process dependencies needed for Firefox to function


Access to network I assumed allowed access to 127.0.0.1
Protocol set to "local sockets" restricted traffic to local ports?

I didn't independently test with any tools to see what packets were passing, so I'm not sure if only web traffic is actually what the firewall was allowing through with that configuration.

[Stem]

{QUOTE-> Event: either "any" or "access to network" was selected
Protocol: "local sockets" was selected for certain windows process dependencies needed for Firefox to function <-QUOTE}The events~"Any" / "Access to network" will allow that application access to all windows sockets.

{QUOTE-> Access to network I assumed allowed access to 127.0.0.1 <-QUOTE}Only if this address is within the trusted zone
{QUOTE-> Protocol set to "local sockets" restricted traffic to local ports? <-QUOTE}I am not completely sure why this is added as "Protocol", selecting this for "IE" makes it crash. I have not made any tests on this, so unsure at this time.

[Vulcan_]

http://gambasdoc.org/help/doc/network
{QUOTE-> Local or Unix sockets: sometimes we don't need to connect with other computers, but with other programs in the same computer. Using TCP for this is not efficient, and you waste a limited resource as TCP ports are. Unix sockets are local sockets implemented by the operating system to "emulate" TCP sockets into the computer ( oh, well, this is not a technical conference, I simply try to give an idea, you know? ), and data sharing using this method is quite fast and inexpensive. Both ClientSocket? and ServerSocket? can also stablish unix-socket connections. <-QUOTE}


http://www.melikyan.com/ptypes/doc/streams.namedpipe.html
Would seem to confirm my thoughts in principle.

Again, I haven't actually verified that JPFv1 acts by passing traffic in this way.

[Vulcan_]

{QUOTE-> The events~"Any" / "Access to network" will allow that application access to all windows sockets.

Only if this address is within the trusted zone
I am not completely sure why this is added as "Protocol", selecting this for "IE" makes it crash. I have not made any tests on this, so unsure at this time. <-QUOTE}


It would crash if you set IE as local sockets, because IE needs TCP/IP to send outbound traffic.

From my understanding "Local Sockets" would be used on one of the OS system process dependencies like "explorer.exe", potentially "svchost.exe" "lsass.exe" "csrss.exe" processes that only talk to other system processes or applications. or for an application like DU meter, that only needs to read loopback.

[Stem]

{QUOTE-> It would crash if you set IE as local sockets, because IE needs TCP/IP to send outbound traffic. <-QUOTE}It was allowed to connect out, it was during a browse that it crashed.

[Vulcan_]

{QUOTE-> It was allowed to connect out, it was during a browse that it crashed. <-QUOTE}
Well, honestly I'm not sure what Jetico developer's definition of "local sockets" is under protocol. I hoped you might have a better understanding of this, since you shed a lot of light in the 30 page thread. If Jetico's definition of "local sockets" reads similar to any implementations like those expressed in the links above, it would appear that "local sockets" is intended to restrict traffic to communication between processes on a host machine.


Edit: IBM link

http://publib.boulder.ibm.com/infocenter/tpfhelp/current/topic/com.ibm.ztpf-ztpfdf.doc_put.cur/gtpc1/locals.html
{QUOTE-> Local sockets is a form of loopback processing that allows you to test a socket client and server application running in the same z/TPF system without using or needing a real network.

When an IP packet is built by the z/TPF system, the destination IP address in the packet is examined and, if it is a local IP address of this z/TPF host, the packet is placed on the input list to make it look like the packet was received from the network. When this occurs the packet is not added to the IP output queue to be sent to the network.

To use local sockets, you do not need to have any IP routers active or even defined to your z/TPF system.

Local sockets can be used in z/TPF test systems to test new socket applications. Local sockets can also be used in a z/TPF production system environment. For example, if you have a socket client application on your z/TPF system that sends messages to server applications that reside in different locations (one of which is in the same z/TPF system as the client), the client application can use the same socket interface to communicate with remote servers as well as the local server.
<-QUOTE}

[Stem]

As I said, I have not taken to time to look at this fully. But I would of expected this to of been an "event" if indeed it is for the restriction of access to local sockets rather than full access to winsock.

[Vulcan_]

{QUOTE-> As I said, I have not taken to time to look at this fully. But I would of expected this to of been an "event" if indeed it is for the restriction of access to local sockets rather than full access to winsock. <-QUOTE}
I haven't either, hopefully someone poses this question to Jetico Developers. :D

[Stem]

{QUOTE-> I haven't either, hopefully someone poses this question to Jetico Developers. :D <-QUOTE}I will send an e-mail.

I currently have Jetico1 on a VM. I just changed the rule for "Explorer.exe" to "Protocol~ local sockets": "Event~ Any", performed a search and "explorer.exe" then made outbound connection attempt to MS (as it does), there was no alert from Jetico1 due to that rule (It was the host that actually alerted me to the connection attempt)