Thanks for the explanation. The weird thing is that the .exe in my installation does not appear to be signed. If I run this command in a powershell window: PS C:\Program Files\DB Browser for SQLite> Get-AuthenticodeSignature -FilePath '.\DB Browser for SQLite.exe' I get the status "NotSigned". Right-clicking on the .exe and checking the properties also does not show a "Digital signatures tab", so it really appears to be unsigned. Very odd indeed, because if my computer lacked some root certificates I guess it should still say the file was signed? And if it really is unsigned, why does TinyWall show it as "possibly compromised"? Edit: I figured it out, and it seems it's a packaging problem when they created the installers. I used the 64-bit MSI installer, but I now checked the files in the .zip-version, and in that package the files are actually signed. So I just replaced the exe in my installation with the one from the zip, and now TW recognizes it and gives the green banner. Still doesn't explain the red banner in TW with the unsigned files, though. It should have been blue, I think, as per your explanation.
A newbe has two questions... How to set a rule to only allow an app to send/receive through FTP but deny both UDF + HTTP protocls (in and out)? How to only allow both in and out for an I.P. address range for HTTP or UDF for a selected app. And a big thank-you Károly Pados for making TinyWall freely available.
This happens on some Win7 machines (Win10 seems unaffected) for an unknown reason. The issue is relatively old but I never could reproduce it (neither on real nor in virtual machines) or solve it simply through experiments, although I've tried. I'd need a willing and affected user to let me remote log into their computer and debug the issue while it is happening, but so far nobody stepped up.
You need to click Apply in the Manage window for any changes (not just exceptions) to take effect. Of course, when making multiple changes or multiple exceptions, you need to Apply only once at the end.
Ok, now I've got it. I downloaded and installed the .msi instead of the .zip, and now I also get the red banner. For some reason the code manages to extract a certificate issued by "justin" at DBHub.io, but then correctly determines it is not valid on our computers. So the question is, is this .exe really signed or not? Cross-checking it with SignTool says it isn't. Hmmm... I need to dig deeper, but it seems you might have found a bug in TinyWall.
Hi geckosstick, By UDF I assume you meant UDP? Anyway, you select "Allow only specified ports" and then enter your comma-delimited list of ports into the TCP fields for FTP and HTTP. To make this work effectively without having to open up most local ports, you need to set up FTP for passive mode instead of active mode (this is important, and is true not only for TinyWall but for all end-user firewalls). You need to consult the docs of your FTP client and server about how to do that. But! A far better solution would be ditch FTP altogether and use SFTP or SCP instead. These provide much higher security by default (FTP's practically deprecated and nobody should be using it anymore), while also being easier to set up in the firewall as they only need a single outgoing port. You cannot define IP address ranges in TinyWall.
Many thanks fpr ypur answer, with 2.99 version it does not happen. For make debugging we will wait ...
Hi ultim, thank you for your answer. Yes I did mean to say UDP! I will look into setting SFTP for the app and only allowing the port 22. OK, so in that case can I set a scope rule in windows firewall to only allow through a range of IP's and setup TinyWall to allow the app. I mean can TinyWall run alongside with windows firewall - would that work?
That wouldn't work. If you run TinyWall in parallel with Windows Firewall, you'll only be able to use Windows Firewall to add blocking rules, allow-rules in Windows Firewall will not have any effect.
Yoohooo, finally I've got my new certificate on Friday. And you know what that means... that's right, a new TinyWall release! Okay, there is actually not much exciting about this release, it's just a bunch of quality and stability fixes. But that also means it's a safe version and all users are recommended to upgrade. Changelog follows: Code: 3.0.8 - Maintenance release (27.09.2020.) - Add workaround for "grey icon on Win7" issue Note: On affected systems icon will appear with considerable delay after boot. This is expected and does not affect start of firewall protection. - Fix WMI leak when mountpoints change - Fix GUI crash if mountpoints change after changing the GUI language - Fix service crash if pipe command results in uncaught exception - Fix windows are potentially invisible if virtual desktop size changes - Fix text placement in pt-BR localization - Make dependency on eventlog service optional - Updated Italian localization - Updated application database
I have the Windows Security service disabled as I want 0 nags from it for example if I temporarily disable my AV Now, is it ok to disable the Windows built in firewall completely including its service? Would TinyWall still do its job just fine? Also, why did TinyWall v3.08 install itself in the Program Files (x86) folder rather than Program Files since it is 64-Bit?
As this is a pretty long thread, it not easy to prowl through for answers. How do i block or allow different services using svchost? Please do let me
Completely fine. There is no effect on TinyWall if you disable Windows Firewall, it will work without limitations. The Windows Security Center would falsely nag you about a missing firewall but you've solved that already by disabling it. Because even if TinyWall is 64-bits, it is still installed by a 32-bit installer, and Windows enforces that 32-bit installers can only install apps to Program Files (x86) (when they want to install to Program Files). I assume this begs the question why the installer is 32-bits? So that I can distribute both 32-bit and 64-bit versions with the same installer. Otherwise I would have to create and release two different installers and provide two separate downloads.
In TinyWall's Normal operating mode, they are blocked by default so you only need to create allow-rules. Go into the Manage window, in the Application Exceptions tab select Add. Then click "Choose a service...". https://malwaretips.com/attachments/service-jpg.235579/
Got it! Thanks a lot for this awesome firewall! I feel my internet webpage loading is snappier now, probably because there is no telemetry and other crap calling home. Cheers
Is it the certificate for the driver? I'm asking because I see that the developer of Sandboxie Plus couldn't get one, he needs money for this. BTW, aren't you interested in developing a fork of Sandboxie? But anyway, thanks for the new TinyWall, I will soon upgrade.
TinyWall doesn't have a driver, and its certificate is not suitable for signing drivers. I did think of getting one for that (then the first step would be to get an EV certificate), but just like David said, it is prohibitively expensive unless there are enough donations. Since the additional benefits for TinyWall would have been marginal (it could be used to register with Windows' Security Center) and there are not nearly enough donations for it (currently only 51% of an EV certificate is covered), I opted for a "traditional" one. I don't see a reason for me to fork SB+. I think David is doing well and is being active both as a developer and also on the forums to support his users. At this point I don't think SB+ should be forked at all. Users who want to contribute should do so by sending David pull requests to concentrate the efforts. IMHO the only real problem now with SB+ is the missing certificate for its driver (which, unlike for TinyWall, is vital for SB+). I think a supporting company should step in and donate a certificate for SB+. [rant start] Another interesting option could be for multiple projects to band together and finance a "collective" certificate that all of them can use. Something like Sandboxie + Peerblock (maybe even TinyWall). But this obviously needs people to trust each other very well, and might not even be practical due to the hardware token requirement of an EV certificate (this needs more research). Though if something like this would come to fruition, I could imagine an even tighter "alliance" down the road with a partially shared infrastructure, distribution and "marketing". Theoretically the synergy could be great, as all these projects are related security-wise, yet all of them provide solutions for different tasks but have to put up with similar problems. But this is just my own fantasy going wild, I have absolutely no idea how the others see this.[/rant end]
Yes, this is the first item in the changelog. Although 3.0.8 is just collection of fixes and improvements, I was quite hyped for 3.0.8 exactly because of this fix. It is nice to get further confirmation that the remedy is really working, thanks!
OK, my bad. I think you already explained this, but I keep forgetting that a third party firewall like TW doesn't need to use a driver. I guess it simply interacts with the Windows Filtering Platform? I also think it's weird that you actually have to buy a code signing certificate for Windows 64 bit, this will stop small time developers from developing advanced security tools. Perhaps Windows should go for a similar model as macOS which has now switched to "system extensions" which replace kernel extensions. I'm not sure if you have to pay anything though. About Sandboxie, the problem is that there aren't enough developers to develop it. I was thinking, you could charge a yearly fee, I believe there are still plenty of Sandboxie supporters to make it worthwhile. https://developer.apple.com/system-extensions/
TinyWall v3.0.8 (September 27, 2020) Download (or: https://tinywall.pados.hu/ccount/click.php?id=4) Changelog: #1986
Hi mroek, This is now fixed in my sources and the fix will be released as part of 3.0.9 (the next version).
