ESS Warning - Missing Application

See attached images.

It appears a remote computer is attempting to connect to our network.

The ESS dialog box is strange because:
1) the temporarily remember checkbox is greyed-out
2) the (local machine) application name is not indicated
3) the number 41 is not aligned with local port (and is actually nearer to protocol)

Furthermore, when checking the remember action checkbox (and clicking deny), a response states that the rule would be too general.

It is good that ESS confirms "too general" / "are you sure" in this case, rather than immediately creating a rule that would apply virtually universally.

Also, it is possible that the reason temporarily remember is greyed-out is that this is too general a condition (but I believe if a permanent rule is possible, a temporary one should be, too).

We continually deny this inbound traffic, but it is impractical to do so hundreds / thousands of times a day, manually, and we are reluctant to create a general rule to handle it.

Can anyone advise us on:
1) recommended action / steps when encountering this condition
2) how to determine the targeted local application
3) what 41 is, and, if it is local port, how to ID the protocol
4) why temporarily remember is greyed-out

Thanks.







.

 

Is your firewall by any chance set to interactive mode? If so, I would change it to automatic mode or automatic mode with exceptions.

 

It is set to Interactive mode.

We need to adjust rules / exceptions on a regular basis, dynamically, as our environment changes. Automatic mode would not allow us to do this, and Automatic mode with exceptions would work only if we could define all the exceptions, which we cannot. Neither of the latter two modes is appropriate for us; Interactive mode is.

How does the firewall filtering mode affect the issue we are encountering -- aside from the obvious that, in an automatic mode, ESS would allow / deny automatically, and not solicit manual direction?

.

 

Interactive mode is designed to do what you see as a problem. Ask confirmation for every inbound / outbound connection. It's really a mode designed to use when troubleshooting, and not for permanent operation. But keep in mind that automatic mode denies communication mostly if there is a rule to deny that particular traffic. If you want all traffic denied by default and only allow specified traffic you should use the "Policy Based" mode.

 

What is running at the moment of the alert as in what app can possibly accept the connection from that site? And is that site something that you would want to allow

 

dmaasland, the issue we're encountering is not that ESS is asking for allow / deny. As you mention, this is exactly as expected when in Interactive mode. The issues are the 1), 2), and 3) near the top of the initial post.

Although it would be nice to have ESS run in a purely automatic mode, we find that Interactive mode suits us well, as it allows us to build the rules / exceptions as they arise. I agree that Interactive mode can be useful when troubleshooting, but it is also not unduly hobbling once a majority of rules / exceptions are established; if a rule / exception exists, Interactive mode acts according to the rule / exception.

As we understand the filtering modes:
- automatic has ESS deal with all challenges in the ways it "thinks" is best, irrespective of user-established rules / exceptions
- automatic with exceptions has ESS deal with all challenges in the ways it "thinks" is best, unless there is an existing user-established rule / exception, in which case ESS will follow the rule / exception
- policy-based has ESS deal with all challenges by denying connections, by default, and only allowing them if a user-established rule / exception exists to allow the specific connection
- learning has ESS deal with all challenges by following applicable user-established rules / exceptions, and, when none exist, ESS allows the connection and creates a rule
- interactive has ESS deal with all challenges by following applicable user-established rules / exceptions, and, when none exist, ESS will solicit the user for how to proceed, giving the user an opportunity to creat a rule / exception in the process

So, automatic lets ESS make all the decisions, auto with exception lets ESS make all the decisions (except those the user already made), policy only follows already-made decisions (and denies all others), learning follows existing rules or allows & builds a rule, and interactive follows existing rules or asks what should be done (& if a temporary / permanent rule should be created).

Functionally, we want ESS to follow all existing rules, and, if an applicable rule does not exist, we want ESS to defer the allow / deny decision -- if ESS can suggest or recommend an appropriate action, that's good. Interactive mode does exactly what we want: it follows existing rules, it does not automatically make allow / deny decisions, it suggests / recommends (by way of color coding), and it gives us the chance to authorize / reject connections a single time, until the process finishes, or even permanently. No other filtering mode does all this.

Cudni, as to which application is running that could accept the connection, we have many applications that can accept the connection, but we are unable to identify any that are being targeted -- all apps appear to be expected apps and appear to be acting as expected. I would expect ESS to identify the targeted app, which is the reason for "missing application" in the post subject line (and #2 in the issue list).

As to the remote site, it is not one we recognize, and, in fact, it is not one -- as in, the IP address changes -- sometimes sequentially (counting up) and sometimes more dramatically. This supports the idea that it is actually a hack attempt and we would want to reject the connection.

.

 

@ dmaasland, Not sure where you got that info from as "Interactive Mode" used to be the default mode before "Auto Mode" was added AFAIR and its also for full time use.

I do not like the Auto modes as it does not get it right at times and at the times

My FW is Interactive, always has been and always will be !

 

Additional findings:
1) the first 3 octets of the inbound (ESET red) remote IP addresses do not change, and the final octet fluctuates within the low-200s (decimal) -- these IP addresses belong to Microsoft MSN, UK; they could be valid, or could be spoofed
2) along with the inbound alert, ESET occasionally pops up an outbound alert (ESET green; attached) with an anycast (6-to-4) IP address

We still don't know what application(s) is/are involved.

And, we are not sure how to best handle these situations -- do we allow or deny, and do we create an overly-general rule?




.

 

Hello,

Have you tried using the NetStat (filename: NETSTAT.EXE) command on an affected computer to see what connections are occuring, or performed a packet capture to look at the network traffic?

Regards,

Aryeh Goretsky

 

We tried both netstat and Wireshark, and neither sees the connections -- perhaps this is a testament to ESS's firewalling prowess.

The ESS-reported IP addresses are not among either tool's results, and, although it is not clear from the ESS dialog box if port 41 is local or remote (#3 in the initial post issues list), that port, too, is not among the results.

.

 

Bump.

Other thoughts or suggestions?

Application(s) -- Why does the ESS dialog box not show an application &/or path? How can we determine which application(s) or PID(s) is/are involved?

Port(s) -- Why does the ESS dialog box not clearly identify which port(s) is/are being used? How can we determine which port(s) is/are involved?

Action(s) -- Why does the ESS dialog box not allow a temporary rule (when it does allow a permanent rule)? How can we determine the best course(s) of action to follow in this/these case(s)?

.

 

It seems that I'm having the same problem as you, I haven't found a solution though:
https://www.wilderssecurity.com/showthread.php?p=1842332

 

Okay, more strange behavior:

Dealing with the constant warnings has become quite bothersome. If we repeatedly respond to the ESS dialog boxes, it takes us away from what we're doing. Also, as per Murphy's Law, the boxes pop-up at very inopertune moments.

We do not want to create a general rule; this would obviate the firewall.

We tried to move the warning boxes [mostly] off-screen and ignore them. This worked, a bit, except that while ESS awaits our instruction, it does not permit non-ruled communication. Thus, applications fail -- they cannot communicate (TCP/IP) and wrongfully assume there is no connection. For this reason, we have to remember to clear the ESS warning dialog box queue before kicking-off certain applications.

So, lightbulb moment, we decided to create a special ESS rule to handle the specific situation(s) being reported by ESS. See the first attachment. This rule denies all incoming traffic thru whatever ports from an IP address range that includes the majority of the "missing application" IP addresses (as reported by ESS).

Lo and behold, we still get the ESS warnings (second attachment). The rule does not, in fact, automatically deny the incoming traffic.

Taking a look at the rule, there is no "X", check, or question mark in any of the columns for this rule . . . is that as it should be?

Any other thoughts or suggestions? ESS has been a lifesaver more than once, but this present [mis]behavior is choking us to death (or at least to unconsciousness).







.

 

WRAP-UP:

There were several issues being discussed in this thread, and all are now resolved or are no longer important.

First, the dialog box was not showing an application and was not permitting a temporary rule be applied. It appears the internal ESS configuration was corrupt. After re-installing ESS and building settings / rules from scratch (i.e., not importing old settings), the ESS dialog box now shows an application, and the temporary rule checkbox is not greyed-out.

Interestingly, however, the dialog box lists as an application "System", with no path, begging the question what actual system application(s) is/are involved. Separately, the application "svchost.exe" is another of the applications indicated by the dialog box.

The other primary issue was what to do with the dialog boxes, and whether or not to create a [general] rule to handle these situations / conditions.

We determined that the "41" listed next to "Protocol" is, in fact, an IPv6 protocol, and the trapped communications are necessary for IPv6 traffic. We created two (2) custom rules for IPv6. The first allows all protocol 41 traffic, both directions, for application "System", regardless of IP addresses and ports. The second is the same, but for application "svchost.exe" (with path to actual system executable). Attempting to create a similar rule with nothing listed as the application brought up the "this rule is too general; are you sure you want to create it" warning.

Apparently, creating a rule for protocol 41 must be entered as protocol "41" in ESS 4, but for ESS 5 there is an actual "IPv6" entry in the protocol drop-down list when creating a custom rule; this implies Eset knows about this protocol, but hasn't updated ESS 4 to reflect it. Supporting this notion is that, when logging such traffic, the firewall log (in ESS 4) shows the relevant entries as protocol "IPv6", even though the rule being applied states the protocol is "41". Thus, ESS 4 is inconsistent regarding protocol 41 and IPv6, but ESS 5 promises to rectify that.

Note, too, that numerous Eset technicians who were consulted on this were unaware of the protocol 41--IPv6 connection, and did not feel confident in recommending allowing all protocol 41 traffic as a suitable set-up. However, since establishing the "permit" rules, we have noticed no adverse effects, and actually saw some [desired] application traffic increases as a result of being able to avail of IPv6 encapsulations / communication channels.

As no issues (for this original poster) remain outstanding, this thread can be closed.

.

 

So, is there a fix for this?
It's been driving me nuts for the last couple of days. Can't even watch a movie.

Incoming traffic from random ips with no application using protocol 41.

Even after I restored the default firewall settings (3 files in programdata), I still get them.

 

did you try approach AVPro mentions in post above yours?

 

Damn, I missed the part about re-installing the entire thing.
Sigh... this is going to take forever. At least I can upgrade from 4.2.35.0


Edit...
Clean install didn't fix anything. I still get inbound traffic without any process just like the first picture in the thread.
Am I missing something? Doesn't an uninstall clean out old settings (the firewall rules have been reset)?

Do I need to create some custom rules?

 

This issue resurfaced for us.

Not sure why the reinstall seemed to "fix" it, nor what changed to "break" it.

But again we are getting a bunch of pop-ups (dozens per hour), both incoming and outgoing, with no application specified, all using protocol 41, and the "temporary" checkbox greyed-out.

The issue seems to be that ESS cannot ID / does not know what application is responsible for the traffic, and without an application the "temporary" option does not make sense (this option says that as long as the application in question is loaded / running, keep applying the rule; then, once the application is unloaded, discard the rule).

Creating a permanent rule for this traffic -- again, missing the application -- would result in a rule that applies irrespective of application (thus the "too general" warning).

So, why can ESS see the traffic and know that it is protocol 41 (IPv6), but not determine the application / code that is using this traffic? Is this a quirk / difficulty specific to IPv6 traffic? How do other firewalls handle it? Is Eset working on a fix?

.

 

1, according to your screenshot, you created a rule for the TCP/IP protocol but ESS inquires you about communication utilizing protocol 41 (IPv6-tunnel). Hence the rule is not applied.
2, at the NDIS level, drivers only see ethernet packets which do not contain information about the source application. The source application is determined via TDI drivers which works only for TCP/IP communications.

 

True: the screenshot of the rule is for TCP (& UDP), and not for protocol "41". It is correct that this rule should not apply to protocol 41 IPv6 traffic.

However, the reason that rule was created was that the ESS dialog box gives an option to create a custom rule. When we selected that option, then clicked on the 'Protocol' button, it listed TCP (protocol 6), as there was no protocol 41 among the choices [but why should ESS auto-select TCP?]. We tried TCP (& later expanded it to include UDP), thinking that, for some reason, ESS believes this protocol 41 traffic is TCP, so we'd make the rule TCP. As mentioned, the rule was not applied to protocol 41 traffic.

Taking a look at my subsequent post, I pointed out several areas ESS does not deal well with IPv6. Also in that post, I mentioned other rules we created that do use protocol 41. So, while it is true that the screenshot rule should not apply to protocol 41 traffic, a later-mentioned rule would.

If it is possible to determine the application only for TCP/IP traffic, why, then, does ESS pop-up dialog boxes for protocol 41 traffic for "System" and "svchost" applications? The rules mentioned in that subsequent post were created for this traffic.

So, sometimes ESS does know the protocol 41 application, and sometimes ESS does not know the protocol 41 application. For those cases where ESS does know, we created rules, and those rules seem to be followed -- protocol 41 pop-ups have become much less frequent (and never mention "System" or "svchost" applications).

But, when ESS does not know the application, we are stuck either (a) always manually dealing with pop-ups, or (b) creating an overly-generic rule, or (c) letting ESS decide what to do (in non-interactive mode) [what would ESS decide, and why?]

.

 

I have the same problem in Interactive filtering mode. Does anyone know how to fix it?
My Firewall module is 1064, is there a newer version, which would eliminate this problem?

I hope this problem will not be in the new ESS v5


//edit: I forgot to write that I use Win7 SP1 x64 and ESS v4.2.71.2