Is the Firewall still relevant today?

[codswollip]

I have one request. Give it a try without a firewall and tell us how it went.

+1

 

[enaph]

I have one request. Give it a try without a firewall and tell us how it went.

Results can be posted here: Malware Removal Assistance For Windows

 

[mlnevese]

because the OP keep trying to find a justification to replace the FW by his new favorite software, and people keep repeating the same damn thing...
if it was me, i would lock the thread because the answer was given from the very start... but if i did , people will say im a evil dictator (happened already )


hahaha hacking people is EVIL !!! (but you and me are evil so...)

You know I'm a moderator in another forum and the great truth of moderation is that no matter what you do you're evil BECAUSE you're a moderator

 

[cruelsister]

I haven't read the full 7 pages of this thread (God Forbid), but just wanted to give a few reasons on why an Outbound Firewall can assist in stopping common malware (I’m sure you guys will think of others, but these should be sufficient for the point):

1). Ransomware- although not as common as it once was, a number of ransomware strains must connect to Blackhat Command prior to the encryption process proceeding.
2). Trojan Downloaders- malware that although innocuous in itself will connect to Command to download and run the actual malware vector.
3). Worms- After infecting the local system, it will seek out other computers (by connecting out) on the Network to infect.
4). Botnets- Often a two phase process- once to connect to Command to download and run the actual infective vector, then connecting out to the Internet to spread either spam or malware.
5). Keyloggers and other Info Stealers- Even if the data acquisition phase is allowed to proceed, these badboys MUST connect to Command to transmit the stolen information. If they can't do that successfully they are nothing but pieces of junk.
6). Hollowed Processes- some malware will infect legitimate files (like svchost) and cause them to connect to Command for a variety of nasty purposes. Although a Home user often couldn’t distinguish a good svchost from an infected done, things like TinyWall and Windows Firewall Control will not only block these guys, but will do it without and alerts or user input!

What to do? Easy- even a bottom of the barrel Firewall with outbound alerts will make the user aware that suspicious things are going on, and will be independent of whether the malware is 2 years or two minutes old; it will help by either alerting to or outright blocking the malware.

Now, what about Windows Firewall? Well, at default there is ZERO outbound protection so would be useless in stopping any of the above. Some people will note that Rules can be created to add Outbound protection. But this will presuppose that the User has the knowledge and the time to put these rules in place, as well as ignoring the current trend in malware to add certain scripts that can modify/add any current rules, and may even totally inactivate WF.

Essentially WF can be compared to a Fan- turn it one way it sucks, turn it the other way and it blows.

 

[509322]

There are differing opinions. In this post you see what Fabian Wosar thinks. However, please note that he is not disabling Windows Firewall. And he is referencing a system that is behind a NAT router. I'm pretty sure that he would say if you connect a laptop to public, unsecured Wifi then you might want to c

I haven't read the full 7 pages of this thread (God Forbid), but just wanted to give a few reasons on why an Outbound Firewall can assist in stopping common malware (I’m sure you guys will think of others, but these should be sufficient for the point):

1). Ransomware- although not as common as it once was, a number of ransomware strains must connect to Blackhat Command prior to the encryption process proceeding.
2). Trojan Downloaders- malware that although innocuous in itself will connect to Command to download and run the actual malware vector.
3). Worms- After infecting the local system, it will seek out other computers (by connecting out) on the Network to infect.
4). Botnets- Often a two phase process- once to connect to Command to download and run the actual infective vector, then connecting out to the Internet to spread either spam or malware.
5). Keyloggers and other Info Stealers- Even if the data acquisition phase is allowed to proceed, these badboys MUST connect to Command to transmit the stolen information. If they can't do that successfully they are nothing but pieces of junk.
6). Hollowed Processes- some malware will infect legitimate files (like svchost) and cause them to connect to Command for a variety of nasty purposes. Although a Home user often couldn’t distinguish a good svchost from an infected done, things like TinyWall and Windows Firewall Control will not only block these guys, but will do it without and alerts or user input!

What to do? Easy- even a bottom of the barrel Firewall with outbound alerts will make the user aware that suspicious things are going on, and will be independent of whether the malware is 2 years or two minutes old; it will help by either alerting to or outright blocking the malware.

Now, what about Windows Firewall? Well, at default there is ZERO outbound protection so would be useless in stopping any of the above. Some people will note that Rules can be created to add Outbound protection. But this will presuppose that the User has the knowledge and the time to put these rules in place, as well as ignoring the current trend in malware to add certain scripts that can modify/add any current rules, and may even totally inactivate WF.

Essentially WF can be compared to a Fan- turn it one way it sucks, turn it the other way and it blows.

I just got done testing one of the code injectors in the MT Malware Hub and the only thing that alerted me to its presence and activities on the system were firewall alerts for explorer, svchost, randomly named processes, and TeamViewer. The thing surreptitiously downloads and launches TeamViewer. The random outbound IPs are in Austria, Germany, Italy and Ukraine. TeamViewer connecting to Ukraine = bad ju-ju\red-flag - red-flag.

The firewall protected the Twinkie.

Judge for yourself.

 

[Behold Eck]

FYI, I discussed this issue(without using a FW) with an IT friend of mine running his boss's company today. I gave him some scenarios and he said that it can be done without the use of a FW. He also contributed some knowledge and experience to me as a system admin.

I'm positive it can be done without the use of a FW. I just need to select the RIGHT security layers to do the job.

You seem all set to go anyway HF and good luck to ya!

Just let us know of any developments good or bad.

Regards Eck

 

[AtlBo]

6). Hollowed Processes- some malware will infect legitimate files (like svchost) and cause them to connect to Command for a variety of nasty purposes. Although a Home user often couldn’t distinguish a good svchost from an infected done, things like TinyWall and Windows Firewall Control will not only block these guys, but will do it without and alerts or user input!

@cruelsister if you are around, would you recommend replacing the firewall component of Comodo with WFC? I have a license for it, but it means disabling the Comodo firewall element and then enabling the Windows firewall. If Comodo can distinguish between normal and infected svchost I am not concerned. Thing is I am envisioning an unexpected alert from Comodo for this if it happens. Also I can only see it happening if I were to breeze through the HIPS alerts allowing the change and giving the new svchost trust somehow. Then nothing in Comodo would alert I suppose.

Wouldn't it be nice if Comodo added a new type of alert for Viruscope about "hollowing" and other common malware practices. When these things happen, user could be better empowered to deny a malicious file trust (malicious svchost in your example). Could really ease the burden on users to understand HIPS alerts (who have in on) and ease the minds of users who don't use Comodo's HIPS.

 

[Deleted member 178]

@cruelsister if you are around, would you recommend replacing the firewall component of Comodo with WFC?

Why would you do that, Comodo is a full-fledge FW, WFC just a GUI for WinFW with better made rules.

I have a license for it, but it means disabling the Comodo firewall element and then enabling the Windows firewall.

not a good idea to me. either you remove CFW completely (and use another HIPS and sandbox ) or you keep it;

If Comodo can distinguish between normal and infected svchost I am not concerned. Thing is I am envisioning an unexpected alert from Comodo for this if it happens. Also I can only see it happening if I were to breeze through the HIPS alerts allowing the change and giving the new svchost trust somehow. Then nothing in Comodo would alert I suppose.
CFW would alert about svchost.exe being accessed, WFC won't.

indeed

Wouldn't it be nice if Comodo added a new type of alert for Viruscope about "hollowing" and other common malware practices. When these things happen, user could be better empowered to deny a malicious file trust (malicious svchost in your example). Could really ease the burden on users to understand HIPS alerts (who have in on) and ease the minds of users who don't use Comodo's HIPS.

Comodo's BB has a feature called " block shellcode injection" which is supposed to protect against Proces Hollowing.

 

[AtlBo]

Why would you do that, Comodo is a full-fledge FW, WFC just a GUI for WinFW with better made rules.

As @cruelsister mentioned WFC will block without warning some things associated with hollowing that I could allow (not likely I admit) accidently. I wasn't aware of this.

Comodo's BB has a feature called " block shellcode injection" which is supposed to protect against Proces Hollowing.

Thanks. That more or less answers one of my questions. I do like that WFC might simply auto-block some connection behaviors involving hollowed processes. Not that this is for me the reason to use it for connection control, but it is nice to know. It was the first I had heard of this of the program, so I was interested to hear a little bit more.

 

[509322]

As @cruelsister mentioned WFC will block without warning some things associated with hollowing that I could allow (not likely I admit) accidently. I wasn't aware of this.

WFC doesn't detect process forking and then make a decision to block. That's not how it works.

 

[AtlBo]

WFC doesn't detect process forking and then make a decision to block. That's not how it works.

Maybe you could take this up with @cruelsister. Her statement seems to indicate that WFC detects and can and does block silently connection activity of at least some hollowed Windows processes.

 

[509322]

Maybe you could take this up with @cruelsister. Her statement seems to indicate that WFC detects and can and does block silently connection activity of some hollowed Windows processes.

WFC is just a front-end GUI for Windows Firewall. It doesn't detect the act of hollow process itself because Windows Firewall itself does not detect hollow process. If you have a pre-existing allow rule for explorer.exe, svchost.exe, rundll32.exe, etc and any of those processes get hollowed, then they will be allowed outbound network access. If there is no pre-existing allow rule, then WFC will alert that one of those processes is requesting outbound network access. I've tested it before. You can use Secure Rules or train the firewall and set it to auto-block.

When I tested it sometime in 2013 or 2014 it didn't resolve to the file path of the process that did the hollowing. And sure enough, svchost did a download to the Local\temp folder with nary a peep out of WFC.

@AtlBo ask alexandrud over at Wilders. That's your best bet to get up to date infos since he pushes a new build every two weeks or thereabouts.

 

[Deleted member 178]

@AtlBo what CS meant , is that WFC may block the hollowed process' outbound connection , not the Process Hollowing itself.