You're misunderstanding the military strategy of defense in depth. To make a line of defense does not mean "taking measures which are commonly useless against the enemy, but offer additional attack vectors for them".
"Multi layer security" is advertizing nonsense of people who want you to misunderstand that, because they want you to buy their products, which most commonly are useless up to dangerous.
And that is the reason, why you should REMOVE software and SWITCH OFF software instead of adding even more to make your system more secure.
"I'm running out of factual arguments, so I'm switching to ad hominem arguments now. To prevent me from being argued any more (perhaps someone notices the trick with ad hominem) I'm announcing that I will ignore the response."
It's equally ridiculous to expect a so called typical windows user to be able to correctly deal with a PFW (if that was even possible).
Mr. Average shouldn't have to deal with technical stuff at that level. If he doesn't understand how to properly configure his machine, he should get help from someone who understands. I know how to drive my car. But I don't know much about what goes on under the hood - which is why I take it to the local garage now and then.
Windows firewall requires zero configuration (which is about the maximum you can expect from Mr. Average) in order to get started.
It use to be on the ZA forum. I tried to find it, and could not find it. There is a chance I am slightly off a tad. It could of been a vulnerability with the Windows OS, and the firewalls blocked it from the time it was discovered. Maybe I should of looked further before stating that. Sorry folks. I will continue to look for it though. But so far I have not found it.
You're probably talking about W32/Blaster [1], which is a worm not a virus. It exploited a vulnerability in Windows' RPC service. However, aside from filtering access to the service with a firewall, the attack would have been thwarted as well by:
- installing the patch to actually fix the vulnerability, which was released a month before [2,3].
- configuring the system to not run the service on the external interface in the first place [4].
Unfortunately it still could use some fine tuning here and there, though. Like, disallowing UPnP (IIRC that's allowed by default), and allowing some ICMP types.
Have the initial O/S install set the firewall to only allow connections to the "legitimate" website until the computer has been completely brought up-to-date, and then let that website alter the firewall to permit "normal" use.
Require that the company/individual who _delivers_ the computer to the end-user update it completely when the system is delivered, not after.
You know - you are making a good case for not allowing the clueless to have access to a computer until they learn how to use one safely. Unfortunately, you'd loose because it would make things harder for those who think they have a natural legal _right_ to be st00pid.
Please cite _ANY_ creditable source for that fairy-tale statement.
DoS by ICMP usually is an ICMP flood, which means that the attacker is sending so many ICMP packets that they consume the entire bandwidth of your uplink. Dropping ICMP packets on the receiving side doesn't change anything at all about that.
Nonsense. If you need the service to be accessible, the firewall cannot protect it, because blocking access would obviously make the service inaccessible. And if you don't need the service to be accessible: why are you running it in the first place? A service that isn't running cannot be exploitet, no matter how many zero-day vulnerabilities it might have.
Ummm... outside of your private reality there are a lot more services than just HTTP. Which people may or may not need to access depending on their current situation.
Pray tell how you think you can disable a firewall running on a separate device (provided it's configured properly, i.e. UPnP disabled, no default password, firmware up-to-date, etc.).
a) Just because I'm not using a personal firewall doesn't mean I'm not using a firewall. b) Since I'm normally logged in with a normal user account, and I also know how to use Process Explorer, netstat, TCPView, Port Reporter, Wireshark and a variety of other tools, I'm pretty certain that my system is not currently infected.
No, it doesn't. Because in the case of a service that doesn't need to be accessible, you're better off shutting it down than just trying to block access with a packet filter. And in any other case the system is already hosed when the firewall detects the compromisation.
You can doubt that as much as you like. It doesn't change anything about the fact.
Do you believe he'll get suspicious when a program named iexplorer.exe or iexp1ore.exe or ssvchost.exe is trying to access the Internet? Really?
It's neither worse nor better. Insufficient logging is just the same as no logging at all: it doesn't help, because you still lack vital information.
Yeah. Especially when the attacker spoofs the IP addresses of your ISP's name servers (or those of the root name servers). Right. Did you even understand what I'm talking about?
I call bullshit. How do you plan to turn a system into a zombie, when it doesn't have any publicly accessible services, and the users are working with normal user accounts?
*sigh*
You didn't understand the problem at all, did you? Those systems were infected *because* they were running a personal firewall. Had they not been running a personal firewall but instead had their unneeded services disabled, they would not have been affected by this attack (more precisely: not only this attack, but any attack of this kind) at all.
A great deal more than you, obviously. Plus, I have at least some understanding of networking concepts.
You do know that ICMP does a heck of a lot more then echo request/responses, much of which you probably want, at least if you enjoy reliable connectivity.
There is one large exception: A target with asymmetric bandwidth.
If you're attacking a user on a typical consumer grade connection, they'll probably have far more downstream then upstream.
If a user is on a 10Mb/1Mb connection, all you need to do is throw a little over 1Mb/s in IMCP echo requests their way to make their connection annoyingly slow, and any more then 4Mb/s or so will probably cause a decent percentage of their outbound ACKs to get dropped due to their bandwidth being used processing ICMP echo replies.
Now if the target is smart, they'll hopefully rate limit or otherwise deprioritize ICMP echo handling, and it's honestly been a long time since I screwed around with this technique, but having been the recipient of their type of attack, it can be effective in at least some cases.
Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.