Just gave TinyWall a try. Downloaded and installed it today. No time to evaluate it because I didn't have the time but tomorrow is another day. Thanks
Since no one came to answer, here is my reply while I know none of the dark hacking stuff. Many applications are limited in using what ports they use to connect. So whitelisting more than what is really needed is not really unsafe with such apps, IMO. Lets consider then browsers. They can use many ports and yes by allowing only some ports, like out TCP 80, 443, you can be safer for sure. And same time crippling your browsing experience, somewhat, like with the dangerous Flash not allowed all. Then when you add more ports to the comma separated list (based on Connections window etc. knowledge) I imagine that "safety" will somehow get lost, and instead allowing just out TCP *, out UDP * will be almost just as fine relatively, IMO. I expect some who know better give some answers. There is in TW an option to use port based malware blocklist, but I don't use it. If it might give some protection when allowing all the ports and hope not braking any functionality in the browser etc. It is a global thing that goes to any app too. Well, keep that flash updated and maybe use some exploit protection tool too. When you allow more ports than 80, 443. And set the that plugin to ask for click to work. And pray for best lol. It becomes convenient to filter then the web content instead with some blockers. uBlock Origin is easy one to use on Medium mode. Works in both Chrome and Firefox. And for paranoid blocking, there is always uMatrix that also works in both browsers. But the most difficult question to answer is what is really safe and what sites are really safe? I certainly can't answer that.
Thank you for you answer. I see that one need to know what ports to open for specific application when using "Allow only specified ports". So ports 80 (HTTP) and 443 (HTTPS) might be quite sufficient for most rank and file apps. Now I don't use TW but when I return to it I'll restrict access only to these ports 80 and 443 and see what happen.
What you wrote is completely correct. I will only add that while 80/443 are the most common ports for browsing the web, they only cover 99% of all cases. Sometimes you stumble upon an FTP-link on the web (and most browsers can download from FTP), or you might have have a corporate proxy that uses 8080, there is also WebSockets from HTML5 that is sometimes implemented on non HTML-ports, and rarely but still even complete websites are hosted on fully custom ports at certain places. It will depend on your typical browsing behavior whether you are affected by these edge-cases. Personally, when *I* whitelist stuff on my personal computer, I do it mostly on an app+direction basis, not app+direction+port. The reason is when I whitelist an app, I have already established that I trust it, and I'd need to whitelist any ports that it uses to make it functional, any other port it won't use anyway, unless it gets infected by some virus. So whether you should restrict an application to only specific ports depends on why you personally want a firewall. If your goal is to prevent malware from spreading, then yes you could define allowed ports in detail, it is more secure and gives a little bit of extra protection, assuming that the malware that infects you would try to inject itself to other otherwise harmless processes AND that it would use a different port than the infected application. If your goal with a firewall is not fighting malware but to prevent some apps from unnecessary chatting (for privacy, or for saving bandwidth etc.) then dealing with ports only complicates things for little added value. So in the end it all comes down to your personal goals, habits, but also technical expertise. For users who aren't sure about the technical stuff or who are not capable and/or willing to debug when stuff breaks, I'd recommend whitelisting only on an app-by-app basis. For some applications even this can be challenging. Experts and techies, and those who want every bit of security can try to additionally specify allowed ports, it makes your computer more secure, but IMHO the added security is comparatively low. In either case, with TinyWall you can do both approaches.
I might consider retesting tinywall again, but it will only be in a virtual machine this time as I have now upgraded most of the machines I had planned to using the new configuration I decided upon. All I can say is I checked many times rules I had configured and UDP 53 was allowed (I even tried with * allowed) but there was connectivity issues with steam. UDP 53 wasnt in tinywall's log as blocked traffic either, it only logged numerous outbound connections to ports in the 27xxx range. Also a big banner in the main UI saying my steam client was compromised. What I cannot remember now is if this also occurred with dns client enabled, since i cannot remember I played it safe and said it only occured with it disabled. With that said, steam is installed on my windows 10 testing machine so I may give it a try on that with dns client on to be sure if its dns lookups related. I do know on windows 10 and 8.1 there is hidden WSH hardening rules that are not presented to the end user designed to harden windows servers and windows apps. e.g. I observed if dns client is disabled then dns lookups on the windows store and windows apps can fail, and are logged as blocked in event viewer even if dns udp 53 is specifically allowed in user rules. But this is unrelated to the steam issue.
Progress Update I've been spending a lot of time lately on TinyWall. I mean, not just regularly working on it, but much more than I should (or than is healthy for the matter). I was really hoping to publish a test with all the internal refactorings this last weekend, but some technical difficulties got in the way (like, DataContracts don't deserialize over a pipe unless the stream is closed on the remote end WTF, for those who know what I am talking about). So a couple of things are still not yet functional, in fact the current state is such a work-in-progress that I can't even start the damn thing up, LOL. Never mind though, it just means I've found yet another good example of why I don't like to promise future release dates. Not that you should be excited over this test, really, as all the cool-new-stuff won't be included at this stage yet, because internally so much has changed that I want (uhm, *need*) to test things separately. So why am I telling you all of this then? Dunno, felt a need to rant.
My external BenQ monitor connected to my laptop died today. Some flashes on the display and strange sounds. On reboot as a try I was in the login screen on W7. But it was registered to my broken display by the VGA cable, so I could do nothing else but to shut down with the power button and what happened was that after starting again TinyWall had lost its rules. First time with the latest versions, but to tell that it can happen! I of course knew that when not able to connect to internet to check for TW rules. And it was easy to import the settings back from the exported file. So this post as a reminder for all to save the settings just in case.
@ Jarmo: Ah, knowing that it happened after an abnormal shutdown gives me a good idea of what could have happened. I'm pretty sure I can avoid such cases in the future. Thx for letting me know. @ dave88, CHEFKOCH: Thanks for your support.
Hello I'd like to thank the developer for maintaining this project for quite a while from what I see. As many of you might probably know windows 10 introduced a whole bunch of spying software integrated into it which seems to be sending my data to microsoft on a constant basis (yeah I tested it with a packet sniffer it did not happen on windows 7) So, my question is: Is this software able to restrict every single communication with microsoft servers? I'm looking for a reliable solution to this problem and because from what I've read tinywall is based on Windows Firewall, my concern is that the windows firewall itself might be whitelisting those connections, or am I wrong? Basically I'm looking for a program which blacklists every outgoing connection by default, even the system ones (that includes windows spying, but also windows updates etc.) and is completely freeware. Am I finally on the right track?
Hi Vlking, Yes you are on the right track, that is exactly how TinyWall works. Though Windows Update is enabled by default on installation, but you can disable it afterwards in the settings. Additionally, you might be interested to checkout https://www.oo-software.com/en/shutup10 . It can be used to disable Windows 10's spying features all from a central location.
Thanks, from my initial tests it does indeed seem to block every single system communication which is very good. I've only allowed DNS client and my web browser to make connections and I really hope it will stay this way Also no more unwanted windows updates! I'm glad I can finally block these since windows does not allow to do it itself. Also, I'm a bit disappointed that tinywall does not show any remote host names such as "any.edge.bing.com" and there is no way of blocking just these individual host names but, still the feature I'm interested the most is blocking the system services and it succeeds in that so I'm happy. Also I can see this TimeWait state under active connections. Does this mean that the connection is actually being blocked?
@Vlking https://support.microsoft.com/en-us/kb/137984 http://www.serverframework.com/asyn...tions-for-protocols-and-scalable-servers.html
In medias res! Code: 2.1.8 - Maintenance release (10.03.2016.) - Fix: Potential GUI crash when whitelisting by window - Fix: GUI crash if copying to clipboard which is in use by another app - Fix: Connections form GUI scaling issue in German localization - Workaround for performance issue in Windows 10 - Atomic file updates to reduce chance of lost settings in case of file system corruptions - Handle some more possible errors on uninstallation - Add Czech localization, and Spanish update Juhuuu, it's a new update! And due to the Windows 10 thingy in there, I strongly recommend you to install it (well, at least if you're on W10 or planning to upgrade to it). Well, I actually recommend you to install 2.1.8 either way As usual, the new version will be available over the automatic update mechanism with a few days delay, but you don't want to wait for it, do you? I've also got some other things to announce, I'll try to keep it short, if I manage that, it'll be totally unlike me. First, I decided I will release a 2.2 that will serve as a migration path to the next TinyWall generation I am working on. That means, you should be able to upgrade to 2.2 and then to whatever comes after that without having to reconfigure your TinyWall. However, a direct upgrade from 2.1 to post-2.2 (skipping 2.2) will not be supported. This is so that I can remove legacy and compatibility code from newer versions. 2.2's purpose will be mainly just that. No big things on the front, just internal changes with only a small number of user-visible effects. There are only a few things left on my todo-list before I can publish a first release, unfortunately recently I haven't been able to spend too much time on TW, but let's hope this does not keep up too long. And now some other thing. I know the topic may sound scary to many of you, but please read my other post in this other thread, and let me know about your thoughts. I need your opinions about the matter exactly to ensure that nothing gets implemented that is bad. But first you wanted to install 2.1.8
Thank you very much! Installed 2.1.8 over 2.1.7. Update wend fine. Can't wait for 2.2! BTW, what is "prompt for exception details" option for? I have it disabled. Maybe you should write a short ( ) help file.
If that is checked as you might have found out already, you will get a prompted at least when 'whitelisting by the window' method, to select what TW will whitelist. If it is not checked TinyWall will allow out and in TCP * and UDP *. Then you can of course edit the rule afterwards.
How does TW handle multiple interfaces and multiple users? Same rules to all interfaces? Same rules for all users? Thanks
A few times I checked to see which apps were blocked by TinyWall, but nothing was listed. I'm guessing that's because TinyWall only shows what was blocked within the last two minutes (if I'm remembering that correctly). I believe that feature would be much more useful if the period were increased to a larger value, perhaps ten or fifteen minutes. Phil
Hi, please look at the 2nd part of this post from earlier: https://www.wilderssecurity.com/threads/beta-testing-tinywall.309739/page-28#post-2252881
