Hi everyone, There is a feature that BLOCKs malware by PORTS or DOMAINS. Is there more INFO about this feature? If YES, please load WHERE can I find It? Regards... Tim
This feature works transparently and you don't have to do anything special to use it. This feature makes it possible to whitelist applications even if they are located on a network share. In earlier versions of TinyWall 3.0, you had to copy applications from a network to the local harddrive before executing them or else you couldn't unblock them. Now the apps can also be located on a network share or drive and you unblock them just like you would any local file (using any of the available methods).
I unblocked one just for testing purposes right from connections window, on ver. 3.0.6. so why is listed as a new feature on ver. 3.0.7?
Unblocking from the Connections window was the only place it already worked before, because the path for the blocked application already came from the kernel, so supplying the same path back to Windows just happened to work purely by luck. But there are many other ways to unblock apps in TinyWall (browse for executable, by process, or by window), and they all need to bi-directionally translate between UNC and NT filepath formats to support network shares. Only the new 3.0.7 release can do this. Furthermore, network shares mapped to a drive letter must be recognized as a network drive to work correctly, and handled differently than true local drive letters, this is also something only the new release can do.
My recommendation is to use auto-learn for only as long as necessary. If you want it to learn a specific application, use the application once, then exit auto-learn. If setting up a freshly installed computer, use auto-learn for a couple of days at most until you have used all applications on the computer. Other reminders about auto-learn: - Auto-learn mode is automatically exited when you restart the computer. This is intentional. - To inspect the results of auto-learn in the Manage window, you must exit auto-learn first. - Do not use auto-learn if you suspect your computer might be infected.
Whitelisted programs are automatically allowed unrestricted in and out traffic, is it really safe in browsers and other programs i trust? I'm no expert but usually only outgoing traffic is automatically allowed in most firewalls.
This might become configurable in v3.1. For now this is so because whitelisting an application is basically expressing an intent by the users that they trust that application. Thus for less technical users it would be very unintuitive to whitelist an application and find that it still doesn't work (if it needs to open ports). However with the current solution, more technical users can still change the created rule to allow only outbound connections, in TinyWall it only takes three clicks (after the new rule is created, 1. click on the Windows notification, 2. select "Outgoing UDP and TCP", and 3. click OK). Furthermore, my personal technical opinion is that there is little-to-no security to be gained by only allowing outbound connections once an application is whitelisted. If the appplication needs inbound connections then it just won't work. And if it doesn't open ports anyway, then still denying it won't worsen improve your security, unless the process is infected or malicious, but then outgoing ports are just as bad so it doesn't matter.
First of all, I'd like to thank you for developing this little and simple, yet surprisingly powerful and effective piece of work. I don't imagine how could I use my computer without it! I recommend it to everyone. However there's problem that I encounter since the very beginning. TinyWall's set to Normal protection and to allow Windows Update, Defender, Time Sync, SmartScreen (C:\Windows\System32\smartscreen.exe). None of them can connect to the internet. When the mode is set to Allow outgoing applications works correctly. Windows 10 Enterprise LTSC. TinyWall version 3.0.7.
Strange that not even the built-in rules work on your computer. Some permission issue maybe? Or a conflicting security software? If there are any files under C:\ProgramData\TinyWall\logs, please send them to me.
The system has been installed on an empty HDD that has been populated with files later and only one Administrator account is used, so there should be no problems with permissions. I don't use any other security software other than TinyWall and Windows Defender. There was one file in the folder you've mentioned. I've send it to the email address wrote down on your official website.
Hi, thanks, got the file, but there doesn't seem to be anything wrong in there. As for permission issues, you don't need to run TinyWall under the admin account, that's not what I meant. Sometimes users tinker with software to try to harden their system and push the wrong buttons, I just wanted to make sure that nothing of that sort happened. 1) When you put TinyWall in Normal mode and try to use an app that should be working but is not, what do you see under the blocked connections in the Connections window immediately after that? Can you take a screenshot for me that shows your test program wrongfully blocked even though you've whitelisted it? 2) What about the other built-in exceptions? For example, when TinyWall is set to Normal mode and you reboot Windows, does your computer get an IP address and does your network state switch to connected state within 30secs after boot?
1. I've send you few screenshots. Windows Defender creates an .exe file dynamically (in different folders) which then it uses to update itself. I guess that's some method of strengthening system security. 2. I connect to a router with a cable. After a reboot I have immediate access to the internet, even though the system reports as not being connected to the internet even up to few minutes after a reboot (the internet access icon in the system tray has a yellow mark on it). I have DNS service disabled. I've tweaked the system with WinAero Tweaker and O&O ShutUp10, but only or mostly to adjust the appearance of the system and to disable built-in ads and tracking. Do you want me to check settings of those programs or send you screenshots of their settings?
Hi, thanks, everything received. Based on the screenshots it seems that all these apps fail for a single common reason: DNS resolution. One thing you can try is to go into the Manage window, and create a new rule that whitelists port 53 for both UDP and TCP, for all applications (though to be honest, if the apps themselves are whitelisted, this shouldn't be necessary Correction: we are talking about built-in rules which are very specific and not user-created rules, so this is normal). If that's not working, check your other security software and Windows Firewall (TinyWall lists blocked connections in its Connections window even if another application is responsible for the block). You mentioned you disabled the DNS service - might that be the problem? One thing's for sure: TinyWall's built-in DNS rules only apply for the DNS service, not for any other DNS traffic in general.
Hah! Whitelisting port 53 for TCP and UDP fixed the problem! I've modified the rule so it only applies to applications and services that I had problems with. I can thank you right now, for the help and fast replies. But I wonder if you'd like me to enable DNS service back and see if it will affect the situation in any way?
For me it doesn't really matter, but it should be more secure for you to delete this rule and use the DNS service instead. This is because with this rule all applications have now network access over port 53 (and they're not required to send DNS queries, they could use this port for absolutely anything). (In theory there is also a third solution, which is disabling the DNS service and setting up DNS-only rules for these specific Windows features one-by-one, instead of globally for all apps. This would give you the same security as the standard solution with the DNS service, but it's way too complicated to set up. EDIT: oh, sry, I missed that you actually did exactly this already - then it's up to you. I'd still go with the DNS service simply because it's simpler).