Firewall cannot prevent ...

[novice 20]

... child process being launched by parent process.

While the firewall will correctly indicate the child process , however you do not know which process is behind as "parent".

This practically bypass the firewall making it useless.

Am I wrong?

 

[Azure Phoenix 11]

Isn't that the job of the HIPS?

[Marcos 5,143]

Exactly, it's HIPS's job. Moreover, this is the ESET NOD32 Antivirus forum so I don't understand the connection with a firewall.

[novice 20]

6 hours ago, Azure Phoenix said:

Isn't that the job of the HIPS?

HIPS in default mode or in Smart mode will not even blink when a "parent" application will connect to the internet through a child.

[Marcos 5,143]

Please clarify what you would like to achieve exactly. Ideally with a concrete example. Are you talking about firewall-enabled products ESET Internet Security and ESET Smart Security Premium?

[novice 20]

For example I allow IE to communicate over internet using TCP/UDP port 80 and 443 (for general browsing of the internet)

At the same time for an undesirable item (let's say "undesirable.exe") I block access to the internet.

However, "undesirable.exe" as a parent application will launch "IE" as a child application and will get out on the internet , even though my intention was to prevent this.

For known "parent" / "child" applications I can create HIPS rules, but they can be in any combination so, without a mechanism which would tell you that a "parent" is trying to use a "child" , you cannot control access to the internet.

[itman 1,707]

4 hours ago, novice said:

For known "parent" / "child" applications I can create HIPS rules, but they can be in any combination so, without a mechanism which would tell you that a "parent" is trying to use a "child" , you cannot control access to the internet.

Appears you have part of the HIPS rules you need already figured out. That is known processes that can launch IE11 when you do so manually via the desktop taskbar. Reviewing that, these processes can be explorer.exe, svchost.exe, ekrn.exe(Eset's BPP), and iexplore.exe - note that IE11 spawns a child process or itself. Rules need to include both IE11 x(64) and x(32) versions. Also IE11 runs differently depending on the OS installed and how it is configured. For example, IE11 on Win 10 x(64) when opened in Private mode will run under svchost.exe control just like Edge - consider this a tip.

Once you have created all your allow HIPS rules for IE11, then create one "ask" rule where the source is blank, the operation is "start new application", and the target is both IE11 x(86) and x(64) executable full path name location. Make sure the rule is set to "Notify user." This way you will get an Eset alert for any IE11 startup by any process for which a corresponding allow rule does not exist.

Also, the only way you will learn what the HIPS can do is through experimentation. 

Edited September 5, 2018 by itman

[novice 20]

52 minutes ago, itman said:

target is both IE11 x(86) and x(64) executable full path name location

That would be easy.

The problem is you never know which "parent" application will launch which "child" application; so the "child' application doesn't have to necessarily be each time IE.

So, how do you make the rules not knowing which "child" application is going to be launched?????

[itman 1,707]

4 hours ago, novice said:

So, how do you make the rules not knowing which "child" application is going to be launched?????

You're "over-thinking" the problem.

I believe you're referring to the grandparent -> parent -> child launch scenario. For example, malware is launched via a malicious explorer.exe shell .exe which in turn launches IE11. Again, the HIPS "ask" rule I stated previously doesn't care how deeply nested the execution of IE11. It will detected whatever the process was that attempted to start IE11. 

Also anything run in debug mode can be a problem for the HIPS. That is because IE11 would be running under the debugger process name. So if you're really paranoid, make sure the IE11 rule specifies that.

Edited September 5, 2018 by itman

[novice 20]

24 minutes ago, itman said:

You're "over-thinking" the problem.

Not really:

Just an example: I have Malwarebytes   and    Mbamservice.exe is supposed to have access to the internet for updates, license check, etc. So I allowed  Mbamservice.exe to connect to various ULS's.

At the same time Malwarebytes Assistant (Assistant.exe) will act as a "parent" application and will launch the same Mbamservice.exe  as "child" to submit telemetry data , which I want to block. In this particular situation I know which one is the "parent" which one is the "child"  so I can create rules in any firewall.

However, in day to day operation is impossible to say which is which and what are they doing (the same is valid for Adobe Acrobat and Adobe Manager) so unless the firewall is telling you that "this application" is trying to connect to the internet  using "that application" , you will never know.

[itman 1,707]

43 minutes ago, novice said:

However, in day to day operation is impossible to say which is which and what are they doing (the same is valid for Adobe Acrobat and Adobe Manager) so unless the firewall is telling you that "this application" is trying to connect to the internet  using "that application" , you will never know.

That is exactly what the HIPS "ask" rule I stated previously will do.

Appears you don't understand how the HIPS rule elements work. When you leave the source application section blank, it means this rule applies to all processes. Also note the precedence in which HIPS rules are applied. Allow rules always execute prior to ask or block rules. The order in which the rules are created and stored; i.e. top to bottom, is immaterial in HIPS rule parsing. Note that such is not the case for Eset firewall rules that are executed in top to bottom order.

[novice 20]

37 minutes ago, itman said:

When you leave the source application section blank, it means this rule applies to all processes

That I understand ! But...

7 hours ago, itman said:

...the operation is "start new application", and the target is both IE11 x(86) and x(64) executable full path name location

the target should be also blank because , as I said  you do not know who the target is (not necessarily IE11 only) .

In my previous example , the target was  Mbamservice.exe  .

[itman 1,707]

1 hour ago, novice said:

the target should be also blank because , as I said  you do not know who the target is (not necessarily IE11 only) .

If both the source and target application areas are blank, you are in effect running the HIPS in interactive mode. This means you will receive an alert for any process for which an existing HIPS rule does not exist for the activity; e.g. start an application, you are monitoring for.

[novice 20]

10 hours ago, itman said:

This means you will receive an alert for any process for which an existing HIPS rule does not exist for the activity; e.g. start an application, you are monitoring for.

Yes, but this would be impractical.

All I want is to receive an alert for <any application>  which is trying to use <any application> in order to <connect to the internet>. Nothing more ,nothing less.

But I am afraid that ESET HIPS cannot do that.

Edited September 6, 2018 by novice

[itman 1,707]

12 hours ago, novice said:

All I want is to receive an alert for <any application>  which is trying to use <any application> in order to <connect to the internet>. Nothing more ,nothing less.

But I am afraid that ESET HIPS cannot do that.

Correct, the Eset HIPS cannot do this. The Eset firewall can if you do the following:

1. Set the Eset firewall to Learning mode for a while. Enough time that it creates rules for all your legit apps that require Internet access.

2. Then switch the firewall to Interactive mode. You will then receive an alert for any app performing network access for which an existing rule for it does not exist.

A side benefit of running the firewall in Interactive mode is Eset will alert you whenever there is a code change in any app monitored by the firewall.

[novice 20]

On ‎9‎/‎6‎/‎2018 at 8:48 AM, itman said:

A side benefit of running the firewall in Interactive mode is Eset will alert you whenever there is a code change in any app monitored by the firewall.

PC Tools Firewall does the same. Plus will alert you if an application will try to connect through a child...

[itman 1,707]

1 hour ago, novice said:

PC Tools Firewall does the same.

Yes, it was a great firewall for Win XP and 7. It hasn't been supported since 2012:

Quote

Windows 7: PC Tools Firewall discontinued.

https://www.sevenforums.com/system-security/257975-pc-tools-firewall-discontinued-looking-replacement.html

When Symantec bought out PC Tools, that was "the kiss of death" for their software.

[novice 20]

8 minutes ago, itman said:

It hasn't been supported since 2012

How exactly is a firewall supported?

I use PCTool Firewall + since 2012 (unsupported), I used Kerio 2.15 for many years (unsupported)  ...

[itman 1,707]

1 hour ago, novice said:

How exactly is a firewall supported?

It means that any OS changes that could adversely effect its firewall processing are not being implemented. Just because the firewall still runs does not mean that it is functioning as it should be with later Win 7 version patches and upgrades.

[itman 1,707]

3 hours ago, novice said:

Plus will alert you if an application will try to connect through a child...

Also, I stated that Eset's firewall running in Interactive mode will detect this. Note that it obviously won't alert for a spawned child process of itself since you've previously allowed the parent instance of it.

[novice 20]

1 hour ago, itman said:

Eset's firewall running in Interactive mode will detect this

No, will not.

If a "parent" application tries to connect through a "child application", you will get an alert about the child, not about the parent.

For example if you allowed internet explorer   TCP/UDP  port 80 & 443 (for general access of internet)  and an application,  let's say   example.exe , will connect to the internet launching internet explorer as "child" you will not get any alert from ESET firewall, even in interactive mode.

[itman 1,707]

14 hours ago, novice said:

No, will not.

If a "parent" application tries to connect through a "child application", you will get an alert about the child, not about the parent.

For example if you allowed internet explorer   TCP/UDP  port 80 & 443 (for general access of internet)  and an application,  let's say   example.exe , will connect to the internet launching internet explorer as "child" you will not get any alert from ESET firewall, even in interactive mode.

We could have saved a lot of time if you posted "specifics" originally.

Correct. The Eset firewall is not capable of this since you have previously created an allow rule for the browser.

Nor is the Eset HIPS capable of doing what you want since it, like most HIPS's, only allow for parent -> child process monitoring. What you need is a product like NoThanks Antivirus  NoVirusThanks EXE Radar Pro that I believe provides for custom grandparent -> parent -> child rule coding. The rule/s specifics would be using IE11 as an example:

any process starting -> explorer.exe or additionally in Win 10, svchost.exe -> starting IE11

Edited September 9, 2018 by itman

[novice 20]

14 minutes ago, itman said:

We could have saved a lot of time if you posted "specifics" originally

I did.

 

[TomFace 539]

On ‎9‎/‎5‎/‎2018 at 2:07 AM, Marcos said:

Exactly, it's HIPS's job. Moreover, this is the ESET NOD32 Antivirus forum so I don't understand the connection with a firewall.

Thank you Marcos. I was wondering when NOD32 grew a firewall.