regarding Avira Antivir updates...

[tokariu]

We already had an opened issue regarding Avira updates here: #114

the problem was, that Avira randomly generates update.exe in different folders and therefor simplewall always blocks or asks the user for permission, otherwise no updates get installed.

randomly update.exe's are generated in:

C:\ProgramData\Avira\Antivirus\TEMP\SELFUPDATE\********\update.exe

where ****** is completely random.

in previous issue-114 the mentioned solution was to look up the IP addresses of Aviras update server and allow them globally.

This idea is not very good, because Avira deploys their updates via akamai/aws and other CDNs and their IPs change frequently (despite telling differently in their FAQ from the year 2010), rendering global IP whitelistings useless.

The best solution would be to implement wildcards for apps, or create app-rules for all programs within a selected folder.

unfortunately, simplewall doesn't allow the selection of folders or wildcards/patterns when adding apps to the list.

But I found a working solution in a clumsy workaround:
To get Avira updates working without the need of whitelisting global IPs every few days, I added the Folder:

~~C:\ProgramData\Avira\Antivirus\TEMP\SELFUPDATE~~

as an App to the simplewall app-list. However, simplewall doesn't allow adding folders to the applist via it's menues/GUI.
The solution was to export the apps.xml (via File -> Export -> apps.xml), then edit the file with a text editor manually and replace:

<item path="C:\programdata\avira\antivirus\temp\selfupdate\sf6528fsd6\update.exe" timestamp="1478523577" is_silent="false" is_enabled="true" />

with:

<item path="C:\programdata\avira\antivirus\temp\selfupdate" timestamp="1478523577" is_silent="false" is_enabled="true" />

then import the app-list again with: File -> import -> apps.xml

That way, you have a Folder as an App in your simplewall applist and you can apply firewall rules to the Folder and all it's containing programs, even if they are randomly named and generated.

It seems to work for me this way, but maybe someone else can verify that it also works for him/her.

regarding simplewall, I wish we could add wildcards or folders directly from the UI to solve these situations, maybe there is a way to implement that feature?

EDIT:

It turned out that it doesn't work. You can have a folder as an App in your simplewall app-list, but it doesn't work for the containing .exe's.
Therefor we are more than ever in the need of a wildcard/folder-whitelisting solution.

[xEBFE]

I'm glad you brought up this issue as I too was just experiencing this exact same situation when trying to compile and run a Go source file that required network access.

With Go, issuing "go run example.go" produces several temporary folders in the form of:

Z:\Users\xEBFE\AppData\Local\Temp\go-buildXXXXXXXXX\*
Z:\Users\xEBFE\AppData\Local\Temp\go-buildXXXXXXXXX\b001\example.exe

Where XXXXXXXXX is a random number. So every time Go created these temporary folders—one containing the executable which was run—simplewall would work as intended and always notify of me of network activity, however, I could never whitelist the executable as XXXXXXXXX would always change for every run so I ended up having to uninstall simplewall's filters while I was working with Go.

Fortunately for Go there is a workaround but it got me thinking about how to improve simplewall's handling of these types of situations.

The best solution I could come up with would be for simplewall to allow users to add folders as "Allowed apps"/"Blocked apps" and also incorporate the use of a wildcard (*) or Regex.

Some examples:

This would whitelist all files in the immediate folder "Temp":

Z:\Users\xEBFE\AppData\Local\Temp\

This would whitelist all files in the immediate folder "Temp" along with any sub-directory (at any depth) beneath it:

Z:\Users\xEBFE\AppData\Local\Temp\*

This would whitelist any file named "example.exe" in any sub-directory (at any depth) beneath "Temp":

Z:\Users\xEBFE\AppData\Local\Temp\*\example.exe

This would whitelist all files in the immediate folder "go-build*\" (go-build\, go-buildABC\, go-buildXYZ\, ...):

Z:\Users\xEBFE\AppData\Local\Temp\go-build*\

This would whitelist all files in the immediate folder "go-build*\" (go-build\, go-buildABC\, go-buildXYZ\, ...) along with any sub-directory (at any depth) beneath it:

Z:\Users\xEBFE\AppData\Local\Temp\go-build*\*

So for my particular situation, it would've been nice to whitelist something like the following:

Z:\Users\xEBFE\AppData\Local\Temp\go-build*\b001\*.exe

[ltguillaume]

Are you still experiencing issues? I was about to try out allowing the domains listed here for all apps. but then found out that the update process went fine. I currently have all Avira processes, except for avcenter.exe and fact.exe set to allowed.

[tokariu]

nope, these domains listet there are very old and not true (at least for my instance and country). I had to manually check the firewall logs to get the domains that got blocked and then whitelist them globally. avira also makes a difference between manually initiating an update and letting it automatically update. one might work, while the other doesn't.

so, it works that way, but the solution is bad. instead of allowing IPs globally it would be much better to whitelist processes following a pattern or subdirs.

[ltguillaume]

That may be true, but afaik that's a limitation of Windows Filtering Platform and not of simplewall.

[ltguillaume]

Personally I don't know if I'll need them, but I see that you haven't posted the list of domains you have had to whitelist. Perhaps it's useful for more people if you post them here.

[tokariu]

@ltguillaume hm i don't know if WFP is the bottle neck.. maybe @henrypp could tell us.

it doesn't make sense to post static IP addresses here for other users, because:

• they seem to be different depending on the country
• different on client version
• and they use Amazon Web Services and every now and then their IPs changes also.

The only advice i could give atm is, look for yourself: everytime Avast wants to update, simplewall shows one or more popups.. instead of allowing or blocking those, copy the current pending IP address into a global allow rule. if you missed an IP check the Firewall log (enable it if necessary). it seems to be about 5-10 different IPs depending on the update methods (manually or automatically).

[ltguillaume]

You're right, sry, I misunderstood. I thought you used domain names instead of resoped IP's. The way you describe is the way to go then, yeah. I'll try to keep up without global rules, though, see for how long it works.

[henrypp]

Therefor we are more than ever in the need of a wildcard/folder-whitelisting solution.

No wildcards will be in simplewall, ever.

nope, these domains listet there are very old and not true (at least for my instance and country). I had to manually check the firewall logs to get the domains that got blocked and then whitelist them globally. avira also makes a difference between manually initiating an update and letting it automatically update. one might work, while the other doesn't.

IP are different because Avira used CDN and all country are different update IP's. and, oh jesus, you can open simplewall logs and see where updaters connects, then create rules (or do the same from notification window).

[tokariu]

@henrypp why not? if programs demand for features like wildcards, why stick without them? of course it's possible to circumvent the problem by applying global ip rules.
But that is still clumsy and to some extent insecure. Because the IPs change with time, the IP that I whitelisted for Avira could get abused by another program with bad intents sometime later.
That wouldn't be the case if simplewall takes the other approach by whitelisting apps by folders or wildcards.
This is also a question about enhancing a product to be better than it's competitors.

[ltguillaume]

@tokariu AFAIK it's simply not possible with the sort of rules that can be created for the Windows Filtering Platform.

[tokariu]

@ltguillaume idk, if that's the reason, than we probably have to accept it.

[ltguillaume]

Avira's getting slower and slower, the update process upon boot takes ages, and its advertising is annoying as hell (BgPKiller doesn't work anymore). I recently fixed someone's system that was completely riddled with useless software by Avira, because of the aggressive advertising, he couldn't even send e-mails anymore because of an Avira bug and every single click lead to a browser window with some Avira ad page (note: the system was not infected by the know Ame.Avira Redirect Virus). I really recommend Avast! (again, now that it's improved tremendously in terms of bloat, modularity and advertising) or Kaspersky.

[frederikhors]

Fortunately for Go there is a workaround

@xEBFE what workaround, please?

[xEBFE]

@frederikhors, for my particular situation I needed a way to compile/run a *.go file directly from Notepad++. That is where the NppExec plugin came into play. Unfortunately, if there was code within the *.go file that would trigger network activity, I could not use a NppExec script such as the following:

NPP_RUN go run "$(FILE_NAME)"

As that's where it runs into the issue of the temporary build directory and simplewall crying about network activity (as outlined in my previous post). To work around this issue, instead of calling "go run" directly, I would call "go build" directly and (if the build was successful), directly execute the compiled binary. As windows will only execute the command after the "&&" if the first part doesn't fail.

NPP_RUN go build "$(FILE_NAME)" && "$(NAME_PART).exe"

This way, the binary will always be produced in the same directly as "go build" was called in (and not a temporary directory as "go run" does). So, the first time I issue this NppExec script simplewall will cry about network activity, but I can allow (whitelist) the resulting binary, and re-run the script as often as necessary from within Notepad++ as I make changes to the *.go source code without further prompts from simplewall.

[ViRb3]

I have developed a simple utility to aid this problem by automatically parsing your packet log and creating allow rules for all IPs of a given process name (which doesn't need to be a full path 😉). This works wonders with the infamous Visual Studio and Docker updaters. You can find it here: https://github.com/ViRb3/simplewall-utils

[ltguillaume]

I have developed a simple utility to aid this problem by automatically parsing your packet log and creating allow rules for all IPs of a given file name (which doesn't need to be a full path 😉). This works wonders with the infamous Visual Studio and Docker updaters. You can find it here: https://github.com/ViRb3/simplewall-utils

Great initiative! This should be a native feature, though, especially since the same thing happens for Microsoft Defender.

[agiz10]

I have developed a simple utility to aid this problem by automatically parsing your packet log and creating allow rules for all IPs of a given file name (which doesn't need to be a full path 😉). This works wonders with the infamous Visual Studio and Docker updaters. You can find it here: https://github.com/ViRb3/simplewall-utils

Great initiative! This should be a native feature, though, especially since the same thing happens for Microsoft Defender.

Agreed. Would be usefull for all the aplications that change folders with every update to have some sort of wildcard feature available.