Okay that makes sense, thanks. FWIW, I no longer block outgoing on Windows Firewall via Windows Firewall Control and create program-specific rules. There is no wildcard option for program paths, so this is a deal breaker for me. I just use Andy Ful's Hard_Configurator firewall hardening option to enforce its built-in rules, such as the Recommended, LOLBins and MS Office. I completely understand @bellgamin's desire to learn about firewalls and networking in general. I used firewalls in Windows and Linux for years because I find it interesting and kind of a hobby that I enjoy. Yes, incorrectly configured rules or lack of certain rules can break things, but then that is where the logs will reveal the problem, you fix the problem based on your findings, and there is some pleasure and satisfaction in achieving that Wanting to learn is essentially what it's all about
Tell me about it, aside from allowing processes per IP ranges, I also block almost all TLDs and to my surprise, Windows downloads certificates from Poland. Either way it helps me to deepen my knowledge how certain aspects work.
maybe it's the nearest CDN for your windows. blocking is easy but then windows is trialing other servers around the world. such blocking only slow down the whole workflow and has no security gain.
@reasonablePrivacy -- I get your point. Windows functioning properly means: my computer is running just fine & continues to be responsive, zippy, and stable.
A good firewall/anti-virus combo should be able to protect the user from such an attack. When an unsolicited packet is received even on a service port, the firewall will automatically block the traffic. The only way the worm attack, in your example, will work is, if either the firewall/anti-virus is configured incorrectly, or is turned off, or the worm has already infected a system service by other means and the anti-virus cannot detect it due to no signature available (0-day attack). If such an infected service was to send a packet out of the service port, the firewall will allow both outbound/inbound traffic. Of course if your system can get infected through other means, then blocking ports will not help as the worm will try all ports and use the one that is open. So this is why I do not think it is necessary to block any port, just let your security software do its thing. This of course greatly depends on the quality of your security software. But I know a lot of network admins want to play it safe and just block all common ports that are not in use on their network. This is fine, as long as they remember that these ports are blocked, otherwise it creates unnecessary headaches to resolve an issue when a legit service fails to work and you cannot figure out why.
If they check the events log, it shouldn't be at all difficult to figure, wot? Also, I think a network admin should want to tighten security to maximum extent, even if doing so sometimes requires him to discover & learn. Tight security can be inconvenient at times. However, the network admin who makes too many compromises so as to enhance the convenience of his net's users can get his net hacked, as has happened even to major nets at places like Ebay, Amazon, & governments. BTW, if the hacker who penetrates a net is unable to connect out, then having that net get infected will be merely an inconvenience -- IF & ONLY IF backups & imaging are frequently done. With frequent backups & images, it's mainly the holes in outgoing that can get a network admin into deep sewage.
I agree that unsolicited packet will be dropped by OS when there is no service listening on a port. I was talking about a scenario when built-in Windows service (or installed 3rd party service) has a vulnerability i.e. 0-day and listening on a TCP/UDP. SMB TCP 445 is an example. In that case packet is received, unless there is signature in some software that checks network traffic. But I think you are overestimating how tight that signature protection is, and probably this protection may not apply to all services/ports. Major businesses, banks were infected while having AVs or next-gen security products on endpoints (laptop, desktop etc) and additionally "blackboxes" such as NIDS/NIPS between them.
windows firewall: by default tcp 445 for smb (any) is limited to the "locale subnet" (private/public, domain is not restricted).
I agree with you but the thing is IT work is mostly done on contract basis. Usually the person who initially blocked the ports to protect the network is long gone from the company when the issue arises. Then the new guys discover that the said great person did not leave any paper work behind on their handy work. So they have to figure out the solution to the problem with limited time, and company's entire executive branch breathing down their necks. It is not a fun experience. Now I know it is easy to figure out if the service's port is blocked, but most of the time the problem is not with the actual service that is having issues, but a dependency of its dependency that cannot connect to internet. So unless you have a person on the team who knows in depth about the service in question, and its various dependencies, it becomes a nightmare for everyone. This was just an example, but I agree with your other points.
You make valid points but to give an example, two well known worms of the last couple of decades that casued a lot of damage, ILOVEYOU and WannaCry were not able to penetrate the firewalls and breach the security software by brute force. In both cases the worms were introduced through other means, mostly by users executing a file and from there the worms exploited an existing vulnerability in well known and trusted services, and used them to spread themselves. Once executed this way, they were then able to breach firewalls and anti-viruses because they were considered a trusted service and were allowed through. ILOVEYOU started by sending itself as an attachment in emails, and counting on the end user to execute it to spread. WannaCry also spread by getting a user to execute it on a system and then it used a known vulnerability in the SMB protocol to spread itself to other computers on the network. So the security software were not technically breached, just fooled. I know this all could have been avoided if the ports were blocked, it would have prevented the worms to spread. But you cannot block all the ports all the time. A worm can use any port as long as it is posing a legitimate and trusted service and you need to have ports open if you want any legitimate work done. So, as I said, you have valid arguments, but I always believed blocking ports was not a solution to prevent malware. A properly configured firewall and a good anti-virus along with policies preventing yahoos from executing unknown files is the way to go.
Well, I don't use Windows shared folders or any other SMB functionality on personal computers, even on that rare occasion of using Windows OS. I work on separate laptop issued by employeer. I don't change almost anything on that laptop. I don't understand what do you mean by not blocking ports and using firewall instead. Isn't firewall used to block ports, is it? Namely we were talking about Windows Firewall.
What I meant was that you can set rules in Firewall to block certain ports. Once these ports are blocked, they are not accessible to any software, even the OS itself, and no traffic can go through them. However when ports are not blocked through rules, they are technically still blocked to unwanted software, but the Firewall will allow legitimate software or OS services that need that port to function to go through on a case-by-case basis.
Are you talking about default deny/ drop policy? This isn't much different from creating blocking rules - actually you should create allow rules in that case instead. And hardening is done by limiting numer of those rules, because Windows has a lot of those allow rules by default.
I would like to raise a more specific question about using a FW to manage ports. I will use Simplewall (SW) as the basis. Why? Because: 1- SW enables user easily to default-deny ALL connections except where user allows them (ergo, ALL ports can be default-closed). 2- SW provides user with a handful of pre-defined port management rules. 3- SW makes it somewhat easy for user to develop his/her own port management rules. 4- HOWEVER, SW works good for every day users, even without user's port rules. That is, the user rules would mainly be helpful to high-risk users. The several rules that SW lists at the User Rules tab are NOT enabled. It is up to the user to decide which (if any) of these rules he wants to enable. Reference Simplewall (SW) GUI, User Rules tab, rule: IMAP/POP3/SMTP. I will refer to this rule as the "Email Rule." The only thing that this rule does is to allow Outbound connections to the following ports: 25 110 143 465 587 993 995 2525. I will call these ports "Email Ports." I decided to enable the Email Rule. I right-clicked the Email Rule & selected Edit. The only editing that I was allowed to do was at the Email Rule's "Apps" tab. That tab had a list of apps that were on my specific computer. My job was to select which apps I wanted the rule to apply to. Because this was the Email Rule, I put a check mark by my computer's one & only email program (PopPeeper). I did not check mark any other app except that one email app. After doing all this, I then enabled the Email Rule. ASSUMPTION: I *assume* that the Email Rule, as edited, will allow NO other apps to connect outbound on the Email Ports, with the single exception of PopPepper, my email app. ==>QUESTION: Is my assumption correct?
Without having used SW, I would say it should work that way. You don't have a second email client, but do you have more than one browser? If so, enable the Browser rule, assuming one exists, edit it for only one of the browsers, then see if the other browser can connect to Internet. It should not be able to.
@wat0114 -- SW only has pre-developed user rules as follows: DNS-Protocol FTP HTTP ICMPv4 ICMPv6 QUIC SSH Telnet & MAP/POP3/SMTP. All are set to allow outbound except the ICMP rules are for both out & in. Per your suggestion, I enabled the HTTP rule for Slimjet browser only. Firefox & TOR were unable to connect out. It seems my assumption is correct. MANY thanks for suggesting this easy test. BTW, I have now enabled Firefox & TOR, my 2 other browsers.
I have just now read an online article about QUIC -- a new internet protocol developed by Google. QUIC is relatively new & still developing. The result is that most -- if not all -- firewalls are not filtering QUIC traffic as deeply as they filter other traffic. =>=>I request that others read the linked article and share your comments.
Every Firewall is slightly different. I am more familiar with SEP Firewall. By default it will block all inbound unsolicited traffic. However, it will allow outbound traffic from installed software and allow these software to receive inbound traffic on the same port, on its default settings. I can set it to permanently block a port or an app if I so choose. This is what I meant.
I have disabled quic in all browsers except for youtube. I am not interested to be able to load some webpages a few ms faster and pay with a compromised security by using UDP vs TCP. Not to mention possible privacy issues.
Good. I disabled UDP on Port 443 by simply enabling a pre-defined "QUIC stopper" rule in Simplewall FW.
i have doubt that you people really know what QUIC is. QUIC is mandatory for http/3 and offers a higher security than simple secured traffic. its the sequel of SPDY.
There is no compromise on security. Better block port TCP 80 instead Frankly I'm tired of QUIC topic on this forum. It was brought up on this forum many times... But I glanced over it. As you can see this article is from 2018... It is old. The guy makes some oversimplifications. He is mostly talkin g about enterprise firewalls and other blackboxes that are deployed in corporate networks. It is nowhere similar to a LAN in a household. The only element that may not have QUIC support is 1 AV module. If you do use and have Web protection enabled in it - consult AV documentation or contact AV support. But I wouldn't lose sleep over it. This part of AV was usually the weakest part of IT anyway. Windows Firewall is not filtering higher layer protocols such as HTTPS regardless if it is QUIC or HTTP/1.1 any different than regular UDP/TCP traffic. QUIC has strong, cryptographics integrity protection built-in. Compare it to TCP protection... Not even close. People telling you that TCP somehow has better "security" than QUIC simply does not know what they are talking about. They probably don't even know the term integrity protection in the first place, which tells a lot. TCP was developed in 70' and 80'. There were no cybersecurity in that era. It was just about some reliability - detection od random bitflips etc
