JeremyNicoll

New to EIS and don't understand why an app is being blocked

Recommended Posts

For several years, until today I was using EAM and OA, but I finally decided to uninstall those and change to EIS.

I'm using a 64-bit W8.1 system.

 

As far as I could tell I cleanly uninstalled both EAM and OA, rebooted several times, then installed EIS from my 

admin user, offline, allowed it to update, and things looked ok.

 

I've always run this laptop as if it was on a punlic network, even though so far it's always been used at home. But

I have friends who use the LAN and I don't police what they do, so "public" seemed like a good idea.  I hope it also

means that if I ever do use the machine in a genuinely public place I'll already be used to being careful...

 

When I first started EIS, still under my admin id, it was soon clear that a network time updater tool I use was no

longer functioning - it just times out unable to get time info.

 

I had expected to find some information in the EIS logs showing that it was being blocked... but nothing seems to be

logged.

 

I noticed that both ping & tracert fail with "General failure" replies.

 

Somehow I realised that this might be a consequence of the machine thinking it was on a public network, found my way

to "Manage networks" and changed my current setting to "private network".   Immediately I was able to use tracert & ping

in a command window, and - without stopping & restarting the network time app - it was now able to update the machine

time.

 

I looked at EIS and I think that I was that an application rule had been added (but not by me) for nettime.exe, with "Custom"

shown (I think) for both its Behaviour Blocker and Firewall permissions.

 

I was curious about the implications of "Custom" and poked around in the settings without learning anything, so I decided to

try this again.

 

I deleted the application rule, and all references to the app in the behaviour blocker and firewall logs.

 

Then I prodded the still-running nettime app to get it to try to update the time again.  I expected that whatever had automatically

added the rule(s) last time would do so again, but that didn't happen.  The nettime app timed-out after 30 seconds.

 

There were no new rules added and nothing at all new in the logs.

 

Even more weirdly, ping & tracert now fail again, even though "Manage Networks" still shows I'm on a private network.

I signed-out, did a complete shutdown (ie power off), rebooted, signed-in, this time as an ordinary user.

I'm still, EIS says, using a private network.

 

I tried again to get nettime to update the time, and again it timed-out.  There's still no new rules and nothing in the logs.

 

I just don't understand under what circumstances EIS would create a rule for me.

 

And, if I have to create rules myself, with no information at all in the logs about what has been blocked, I don't see how I would

find out what I need to put in such a rule (I mean: protocol, ports etc).

 

Share this post


Link to post
Share on other sites

tracert and ping are purposefully blocked in EIS when the network is configured as Public. You can tweak the rules, however please be sure that any custom firewall rules are above the line for Traffic handled by application rules otherwise they will be ignored.

Application Rules are created automatically when an application performs a behavior that is automatically allowed or blocked, or when you select to allow or block a behavior in an alert. Custom is the default setting, as custom monitoring is automatically configured to a small extent as things are allowed/blocked either automatically or via the options in alerts.

If you trust the application, then I recommend creating an Application Rule with it set to All allowed.

For the ping issue, I recommend resetting the global firewall rules to defaults. You can use the settings export feature to make a backup of your firewall settings if you have modified them. Here's how to reset the global firewall rules (settings export/import functions are right next to the option for factory defaults, and these functions allow for exporting/resetting only specific types of settings or everything if you want):

  • Open Emsisoft Internet Security.
  • Click on Settings in the menu at the top.
  • Click on the Factory defaults button near the upper-right.
  • Make sure that only the option labeled Global firewall rules is selected.
  • Click the OK button to apply the changes.
As for firewall logs, if you need more advanced firewall logs for troubleshooting, the only way to get them would be to enable debug logging and then look in %AllUsersProfile%\Emsisoft\Logs (which is usually "C:\ProgramData\Emsisoft\Logs", but you can just paste the shortcut I posted in bold right in front of this into the Run dialog to get there quickly) for logs with names that start with "firewall". Please note that debug logging can cause performance issues and they will eat up disk space quickly, so we don't recommend leaving them on for very long (unless absolutely necessary). We've changed how to enable/disable debug logs recently in EIS 11, so here's how to do it now:
  • Open Emsisoft Anti-Malware/Emsisoft Internet Security from the icon on your desktop.
  • In the 4 little gray boxes at the bottom, move your mouse into the one that says Support, and click anywhere in that gray box.
  • At the bottom, turn on the option that says Enable advanced debug logging.

Share this post


Link to post
Share on other sites

Thanks for your reply.   I'm struggling (healthwise) to find the energy to pursue this..

 

I understood your first point about ping & tracert not being meant to work in public networks, but my experience was that

they didn't work - not even after a reboot - in a private network, after I'd deleted app rules for the nettime program.

 

However, still without having changed anything else, and with the network still configured as a private one, I found that

nettime redefined itself (and worked ok) and ping & tracert both started working again after a reboot after EIS updated

itself to v11.5.0.6191.   I did wonder if that might help (because of the reference in that update's list of things changed),     
to a fix for a problem that affected rule deletion.   Maybe when I deleted the rule for nettime, the list of rules got damaged

and those further down the global list meant to allow ping/tracert to work couldn't be found any longer? 

 

I'm contemplating resetting to default rules and then trying to replicate the situation that seemed to cause the problem;

I might do that tomorrow.   Though if the latest version did fix it, replicating it mightn't be possible...

 

 

I'm puzzled though by your statement: 

                                                           
   "be sure that any custom firewall rules are above the line for 'Traffic               
    handled by application rules' otherwise they will be ignored."                       

 

because the help page for firewall rules says that rules are tried one at a time starting at the top of the list, and the first

matching one is used.  So surely the order is

                                                                             
   1) Windows Services (TCP)                                                             
   2) Windows Services (UDP)                                                             
   3) all the application rules                                                          
   4) then the other general rules                                                       

 

so - provided there's no application rule for ping or tracert, which there seems not to be according to the 'application

rules' page - a new rule for them could go in the bottom part of the list.  Surely all that's essential is that such a new

rule is above the default entries for ping & tracert further down the list?    If not, why not?  

 

 

I'm also puzzled, in a different way, about what it is about ping & tracert replies, that makes receiving them on a public

network a bad idea.  Is there something about them that makes it impossible for the firewall to distinguish between

such replies coming in to the machine and responses to other people's pings or tracerts targeting the machine being

sent out?

Share this post


Link to post
Share on other sites

I understood your first point about ping & tracert not being meant to work in public networks, but my experience was that

they didn't work - not even after a reboot - in a private network, after I'd deleted app rules for the nettime program.

Did you change the network adapter to Private, or did you change the category for new connections? Here's a screenshot showing which line is the network adapter in the "Manage networks" dialog:

post-18745-0-74469700-1457150490_thumb.p
Download Image

If you change the setting there, then EIS should reflect the change. It is possible that a computer restart may be necessary before you notice the change.

 

I'm puzzled though by your statement: 

                                                           

   "be sure that any custom firewall rules are above the line for 'Traffic               

    handled by application rules' otherwise they will be ignored."                       

 

because the help page for firewall rules says that rules are tried one at a time starting at the top of the list, and the first

matching one is used. ...

It's a general statement I make when telling people about customizing the rules. It's just important to keep in mind that if you put a rule in the global firewall rules below the one for processing Application Rules, it can be superseded by the Application Rules, and this often causes issues with rules not being processed in cases where they were intended to apply to all programs. If you want the rule to be superseded by the Application Rules, then obviously it would be best to put it below the line for Application Rules.

Technically, all you should have to do is edit the rule for Trusted network traffic (ICMP) and change the Addresses from Private to All, and that should resolve the ping issue. You can, of course, create a more specific rule to allow specific ICMP types. Wikipedia has a list of the ICMP types (aka "control messages") with some basic explanations of that they mean, however I'm thinking that all you'll need to allow is Echo (there are already rules to allow EchoReply and TimeExceeded).

 

I'm also puzzled, in a different way, about what it is about ping & tracert replies, that makes receiving them on a public

network a bad idea.  Is there something about them that makes it impossible for the firewall to distinguish between

such replies coming in to the machine and responses to other people's pings or tracerts targeting the machine being

sent out?

Some people believe that if a computer/router/etc. replies to a probe over the Internet, that it is essentially saying "something exists at this address" and inviting someone to continue probing the address, and thus the best course of action is for no reply to be send at all (allow a timeout) so that no one knows that something exists at that address and they will move on assuming nothing is there. It is true that this would deter anyone who is simply doing a port scan, however (if I am not mistaken) there should be other ways of proving that there is indeed a device at the address being probed. Preventing the computer from replying really just takes away the easy way to get information, and doesn't actually prevent an attack or stop people from probing your IP address to see if they can figure out what is there. There is an advantage to dropping ICMP packets, it's just that it isn't going to stop someone who is determined and knows what they are doing.

Share this post


Link to post
Share on other sites

You said: "Did you change the network adapter to Private, or did you change the category for new connections?"

 

I did say at the start that immediately after making that change (whichever it was) that tracert and ping started working.  They then failed after I'd

deleted an app rule for nettime.

 

 

You said: "It's a general statement I make when telling people about customizing the rules...."

OK, got it.  The rule order works the way I expect, but you're used to advising people who don't think about the consequences of whatever is

defined inside the app rules section...

 

 

You said: "Technically, all you should have to do is edit the rule for Trusted network traffic (ICMP)..."

Yes, I know... but the problem I reported wasn't "how do I edit a rule to make tracert/ping work", but instead the fact that they suddenly ceased to

work when (as I think it must have been) deleting an unrelated app rule screwed up the list of rules.   And remember that I also said that without

me changing anything (certainly not any rules) the new version of EIS fixed the problem.   I was hoping for someone who knows precisely what

changed in the new version's fix for 'problems deleting rules' to say whether it's likely that that DID fix the problem, or whether there is some 

other issue underlying this.

 

 

You said: "Some people believe that if a computer/router/etc. replies to a probe..."

OK; I think the precise answer to my question might be that the default global rules group all the public network ICMP stuff together into one blocking

rule, because for many people that's a good idea.   I can't see any reason why it would be a bad idea for me to be able to send ping/tracert requests

outbound on any kind of network, nor why it would be a bad idea for me to receive the replies from those requests that I initiated.  As far as I can see

neither of those scenarios have anything to do with the probe 'issue'.   Or have I misunderstood?   

Share this post


Link to post
Share on other sites

I did say at the start that immediately after making that change (whichever it was) that tracert and ping started working.  They then failed after I'd

deleted an app rule for nettime.

I assume you're just pinging from the Command Prompt? Or are you using another tool?

... And remember that I also said that without me changing anything (certainly not any rules) the new version of EIS fixed the problem. ...

I'm sorry, I must have missed that.

... I was hoping for someone who knows precisely what changed in the new version's fix for 'problems deleting rules' to say whether it's likely that that DID fix the problem, or whether there is some other issue underlying this.

Usually only the developer who made the change knows exactly what was changed.

... I can't see any reason why it would be a bad idea for me to be able to send ping/tracert requests outbound on any kind of network, nor why it would be a bad idea for me to receive the replies from those requests that I initiated.  As far as I can see neither of those scenarios have anything to do with the probe 'issue'.   Or have I misunderstood?

I think this may be the answer.

Share this post


Link to post
Share on other sites

PIngs etc: yes, from command prompt.

 

Your link made interesting reading, though the concerns discussed there are mainly regarding firewalling public servers.

There are also somewhat different concerns on large (corporate) networks where there's a higher chance of a compromised

machine sending fake ICMP traffic outbound... that is something that looks to a firewall like an outbound ping or tracert

request, but carries some other data with it.  That (as some of the posters say) could be as simple as a piece of malware

telling its command & control server that it's alive and running on your own PC.

 

But - as other people pointed out - malware can hijack any protocol to do that....  For example it could send a fake DNS request

to its C&C server... and no-one's likely to block outbound DNS requests, unless they run their own DNS server on their own

internal network. 

 

I found this page: http://security.stackexchange.com/questions/16882/is-there-any-risk-in-allowing-ping-packets-out-through-a-firewall?lq=1

interesting too.

 

I remain unconvinced that for a single personal machine, even on a public network, that sending ping / tracert requests outbound is

dangerous.  Or at least, that when I choose to send a ping/tracert request, that that's dangerous.  Yes, I can see that a ping/tracert or 

any other request that something bad is sending, is a problem.  I just have to hope that the other parts of EIS can stop that happening!

Share this post


Link to post
Share on other sites

I should add: I did do some testing, deleting rules for nettime and allowing EIS to recreate them, and experimenting with ping & tracert at various

stages, and was not able to recreate the problem.  Maybe that also means that the newer version of EIS fixed the issue.

Share this post


Link to post
Share on other sites

I remain unconvinced that ... when I choose to send a ping/tracert request, that that's dangerous. ...

Yes, that is correct, as far as I am aware. You could try adding rules for C:\Windows\System32\PING.EXE to allow it to send ICMP echo requests and receive ICMP echo replies, and that should take care of that issue at least, since the global rule for ICMP traffic is below the rule to process Application Rules and should be superseded by it.

Share this post


Link to post
Share on other sites

I've had another occurrence of things suddenly ceasing to work, amongst them ping...   I had been using my laptop

in one part of the house (where the laptop's connected via a pair of 'powerline' adapters to a netgear router and that 

to a cable modem), then moved the laptop and adapter to another part of the house, where the laptop is then connected

to a small network switch which is connected via the powerline adapters to the netgear router & cable modem.

 

Suddenly neither the nettime application nor, as I found out when I widened the scope of tests, ping, worked, ping

in particular reporting a 'general failure'.

 

I looked at the firewall 'manage networks' setting and discovered it had changed from private to public - which completely

explains the failures (as I've not yet changed rules to allow ping etc to work in the way we discussed above). 

 

But what does surprise me is that the network suddenly changed its classification.  What's that based on?  Is it just whether

or not EIS/Windows has seen a network accessed through the next device out's MAC before? 

 

My first reaction is that the laptop's been used with both configurations many times, but ... maybe this is the first time that

EIS (rather than OA/EAM, or WIndows) has seen the laptop-switch-powerlines... option.    Is there any way to tell when each

network was first seen?

 

Also, if Windows/EIS is changing from one type of network to another should there not be some sort of alert, or user choice?

Share this post


Link to post
Share on other sites

Are the networks configured as Public or Private networks in your Windows networking configuration? The Network and Sharing Center in Windows should tell you if the network is Public, Home (Private), or Work (Private).

Share this post


Link to post
Share on other sites

As far as I know I've only ever had one network (anything connected to the laptop's ethernet socket)

defined there   And it currently says Public, which is what I configured it as when I first set it up.    But

inside EIS, I've had Private set since the initial difficulties described upthread.

 

Windows has only ever asked me once what the network type should be, which doesn't
really make sense if something about the difference in what I'm plugged into (a
network switch connected to an Asus router at my house; a network switch, powerline
adapters and a netgear router upstairs at my mum's house; just powerline adapters &
the netgear router at downstairs at mum's house) is significant.  Although at both
houses the different types of cable modem are plugged into the smae cable-TV company's
network I'm pretty sure they're connected to different servers at the cable company.

[i've noted previously, but not looked closely recently, that tracerts from mum's or
my house pass through differently named bits of equipment in the cable company's
network, and also that the ip address assigned to me differs according to which
house I'm at.  The ip address changes even at a single house, from time to time -
it's not a static address, jst a rarely changing one.]

So, does EIS do its own detection of 'a different network', or rely on Windows to tell
it? 

Share this post


Link to post
Share on other sites

The laptop's been 'asleep' since last night and I just noticed that the nettime
tool is showing loss of connectivity... and ping's getting "General failure."
again.  I've not changed network settings since last night's change in EIS from
the unexpected Public setting back to Private. And in EIS, Manage Networks still
says Private.  If it's EIS that's blocking nettime's and ping traffic, there's
nothing in the FW log that says so.

I then used: Overview -> Support -> Enable debug logging

and told nettime to try to update
and after that announced its failure did a ping:

C:\>ping ntp.blueyonder.co.uk

Pinging ntp.blueyonder.co.uk [194.117.152.85] with 32 bytes of data:
General failure.
General failure.
General failure.
General failure.

Ping statistics for 194.117.152.85:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

C:\>

then turned off debug logging.   I'll pm the debug logs to you.

Share this post


Link to post
Share on other sites

If the network is configured as Public in Windows, and EIS is configured to "Use Windows settings for new connections", then it is probably just using the Windows settings every time you connect the network adapter. Could you try turning that option off, and set the "Category for new connections" to "Private network" to see if the issue continues to happen?

Share this post


Link to post
Share on other sites

Yesterday, I returned to my own house, with the laptop having been completely
powered off during its journey back.  The EIS 'Manage Networks' display
continues to show that it thinks I'm on a private network, as it did when I was
last here, when ping etc worked ok.  But now they don't.

I exported all settings to 'C:\Users\...\Desktop\EIS\20160317 before unplug'.

Then unplugged LAN connection

Then unticked Manage Networks' "use Windows setting...".   The 'Category for new
connections' remains set to Private.   The Manage Networks display correctly
shows there's no network connection at the moment

Plugged LAN cable back in ... and now it shows
        Network 3    Private

I should have screen-shotted the old display, I've a feeling it might have said
"Network 4".



Is it EIS or the OS that's numbering network definitions?  How do I see what they
all are?  (I see on Control Panel - Network and Sharing Center - that 'Network 3'
is liste, so presumably it's the OS.)

If I click on "Network 3" in EIS I see:
   192.168.1.21; [80FE:0000:0000:0000:5124:2BA9:0000:0000]

which shares some (see **) values (endianness apart) with one line in the ethernet
adaptor's display from an: ipconfig /all:

Ethernet adapter Ethernet 2:

   Link-local IPv6 Address . . . . . : fe80::2451:a92b:d83c:627%3(Preferred)
**                                     ^^^^  ^^^^ ^^^^


Ping and the nettime utility now work.


I exported all settings again, to 'C:\Users\...\Desktop\EIS\20160317 later on'.
When I compared these with those exported earlier I was surprised to see nothing
much changed & in particular no sign of a changed setting for "Manage Networks"'s
"Use Windows settings".


I've said before that it's my intention to run always with the OS and EIS set to
'Public' so that there's no surprises when I really do use a genuinely public
network, so in a way my current difficulties using Private are irrelevant.


But even though I think you might say this is all working as intended, I think
there's a problem.  Even if EIS had previously silently used the "Windows setting"
and decided (both when I went to mum's house and when I came back here) that the
network in each place was a Public one... the Manage Networks display shows EIS
thinks it is Private, which led me to think that it was applying the FW rules that
are appropriate for such a network.  If it had actually said Public, I could have
fixed that.


I tried this again.  I re-ticked "Use Windows settings" and unplugged & replugged
the LAN cable.  As soon as I plugged it back in I went back to a command window
and tried ping again:

C:\>ping www.bbc.co.uk

Pinging www.bbc.net.uk [212.58.244.66] with 32 bytes of data:
General failure.
General failure.
Reply from 212.58.244.66: bytes=32 time=39ms TTL=51
Reply from 212.58.244.66: bytes=32 time=30ms TTL=51

Ping statistics for 212.58.244.66:
    Packets: Sent = 4, Received = 2, Lost = 2 (50% loss),
Approximate round trip times in milli-seconds:
    Minimum = 30ms, Maximum = 39ms, Average = 34ms

C:\>

What?  That worked?  (Assuming that the first two 'General failure.' messages were
just caused by a not-yet initialised connection...)

And now "Manage Networks" says I'm on a Private Network.


Hmm, maybe after I reticked "Use Windows Settings" and disconnected & reconnected
the LAN cable, I didn't exit from that dialog. Let's try again...

   - closed GUI windows
   - systray icon - Security Overview
   - Protection - Firewall - Manage Networks
     currently showing: Private network
                        Category for new: Private
                        TICKED Use Windows Settings
     Clicked OK to close dialog.
     Clicked X to close GUI window.

   - unplug LAN cable, and wait 15 seconds

   - replug cable, and wait 30 seconds

   - try a ping... which works

   - systray icon - Security Overview
   - Protection - Firewall - Manage Networks
     still shows: Private network
                  Category for new: Private
                  TICKED Use Windows Settings

   - This time it seems to have ignored "Use Windows settings" and given me a
     private network, even though a hour ago it seemed certain that it was
     using the Windows settings and giving me a Public network, despite saying
     Private in this display.

     I really don't understand this.

     Control Panel - Network and Sharing Center - still says I'm on a Public
     network.


I've used another firewall product in the past that too-often in my view told me
that a new network had been detected and asked what I wanted to choose.  The
product never differentiated between 'completely new' and 'new connection to a
previously seen network' although it allowed me to attach a nickname to a
connection (that is, if I nicknamed one connection "mum's house", it never seemed
to recognise that it had been there before).  It was very annoying, especially as
there was no way to see why it thought a network was new.

Either it (and EIS) can recognise that they have seen a particular network before
(maybe from the MAC of the next device out?) or they can't.  If they can recognise
I think they should say "We've been here before, and last time you wanted the
connection classed as Private, do you still that want that?".  If they can't they
should say "We don't think we've seen this network before, what level of trust do
you want?".

Share this post


Link to post
Share on other sites

Is it EIS or the OS that's numbering network definitions?  How do I see what they all are?  (I see on Control Panel - Network and Sharing Center - that 'Network 3' is liste, so presumably it's the OS.)

To my knowledge, it's Windows that is numbering them like that. If you use the Win+R keyboard shortcut to open the Run dialog, and then type in control netconnections then you can see Windows shows the "Network 3" under the name of your currently connected network adapter (or at least it should show the same thing EIS does when you check).

You can get a list of these numbered networks by doing the following, however the information displayed isn't really useful unless you want to delete networks or merge them together:

  • Open the Network and Sharing Center.
  • Under View your active networks click on the icon for the type of network (house for a Home network, glass tower for a Work network, park bench for a Public network) to open the Set Network Properties wizard.
  • At the bottom of the Set Network Properties wizard, click on Merge or delete network locations.
As you more than likely saw, you can rename your network if you skip the last step, which may make it easier to identify your networks as you configure things.

But even though I think you might say this is all working as intended, I think there's a problem.  Even if EIS had previously silently used the "Windows setting" and decided (both when I went to mum's house and when I came back here) that the network in each place was a Public one... the Manage Networks display shows EIS thinks it is Private, which led me to think that it was applying the FW rules that are appropriate for such a network.  If it had actually said Public, I could have fixed that.

If it's showing one network type, but applying the rules as if is a different network type, then that is more than likely a bug. It sounds like it may be a slightly intermittent one though.

This is what was covered in the debug logs you sent me, correct?

Either it (and EIS) can recognise that they have seen a particular network before (maybe from the MAC of the next device out?) or they can't.  If they can recognise I think they should say "We've been here before, and last time you wanted the connection classed as Private, do you still that want that?".  If they can't they should say "We don't think we've seen this network before, what level of trust do you want?".

I don't think EIS saves that information anywhere. By default it is intended to just use the Windows configuration, and thus rely on Windows to remember if a network is public or private. I can ask our developers about it.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    No registered users viewing this page.