Avira's firewall
in [Firewalls]
|
From: Ansgar -59cobalt- Wiechers on 13 Apr 2010 16:56 Grant Taylor <gtaylor(a)riverviewtech.net> wrote: > Ansgar -59cobalt- Wiechers wrote: >> If you have to do that, you have a server placement issue. Boxes that >> shouldn't be able to access what the server is providing, should not >> be located in the same network segment. > > I think we mis-understand each other. Let me give an example. > > Suppose that a hosting company has multiple IIS web servers behind an > edge ingress filtering firewall that only allows traffic to TCP ports > 80 and 443 through. With in the network the servers also allow SNMP > and / or RPC for remote computer management. > > What prevents a web site on one of these hosts from becoming > compromised and running a local program that starts attacking the > other systems in the local subnet. This local program would have > unfettered access to SNMP and / or RPC to the other servers that are > behind the edge ingress filtering firewall. Sorry, but that's just ridiculous. If you're that concerned about security, you don't allow SNMP or RPC in the first place. Period. Rather than running additional code on the servers, you'd lock them down tight, update them frequently, and monitor them closely. > Conversely if the web servers were running a software based firewall, > they could easily filter SNMP and / or RPC traffic so that only the > management station(s) could access them. There by protecting them > from the program running locally on the compromised server. You don't seem understand how SNMP works. What exactly prevents compromised server A from spoofing the source address of the SNMP packets it sends to victim server B on the same network segment? The protocol is UDP-based after all. >> This is the exact type of thing, that firewall can't protect you from >> (unless you're using a sanitizing reverse proxy or something). > > I'm not sure that I understand what you are trying to say. > > The closest that I can come up with is that the edge firewall is doing > egress filtering. You mean the "sanitizing reverse proxy" thingie? Those are not about egress filtering, but ingress filtering. They sanitize (i.e. rewrite/ canonicalize) the input data stream going from a client to a server, and thus protect a server from malicious user-supplied data. mod_security for Apache is an example of this kind of software. >> Again: any service that should be accessible, cannot be protected by >> a packet filter. Any service that shouldn't be accessible, should not >> be running (or at least not be listening on the external interface) >> in the first place. It really is as simple as that. > > What if you modify my above example of the server farm where one > interface is public and another interface is private (think DMZ / > management network) and the local program starts attacking the > internal network. Again, I believe that the software based firewall > would help protect other servers from the attack. As explained above, this won't necessarily work as you expect. > A perfect example of a service would be to not run SSH on the external > interface, yet run it on the internal interface for remote management. SSH is a perfect example of a service that does not need to be "protected" with a local firewall at all. You disallow password authentication and restrict which user can login from where. If you're referring to exploitable vulnerabilities: trying to "protect" SSH with some kind of personal firewall would just move the problem from sshd to the personal firewall instead of solving it, and I clearly trust SSH more than any personal firewall. IPv6, anyone? >> They can't afford using the tools that come with the operating >> system, but can afford to buy a centrally manageable host-based >> firewall solution? You have to be kidding me. > > I believe you mis-understand what I'm getting at. > > I'm not aware of any utility included in either 2k3 or 2k8 that allows > changes to multiple IIS web servers at one time. I.e. do not process > requests from the w.x.y/24 network. I don't consider the potential gain in security (which may be a lot less than you expect, as explained above) worth the additional complexity and effort in keeping another piece of software up-to-date. >> "sc /?" tells you why you're wrong. > > You are correct that there are ways to administer the operational > state of a service in such as is it started / stopped / etc. That > does little to prevent a service from talking to a given subnet. Of course not, because that's not what management of services is about. I believe I already said that if you want that level of isolation, you're far better off putting the servers in separate DMZs. cu 59cobalt -- "If a software developer ever believes a rootkit is a necessary part of their architecture they should go back and re-architect their solution." --Mark Russinovich
From: Ansgar -59cobalt- Wiechers on 13 Apr 2010 16:58 gufus <stop.nospam.gbbsg(a)shaw.ca> wrote: > 13 Apr 10, Ansgar -59cobalt- Wiechers writes to Gypsy BBS: >> From: usenet-2010(a)planetcobalt.net >>> Employees /need/ to understand the system, >> >> True, but besides the point. Repeating myself: even the best >> employees are still human and *will* make mistakes here and > > Agreed... and you don't have to repeat your self, there will always be > human error in life. Thats life. *sigh* I give up. Apparently I'm unable to explain matters in a way you'd understand. Please do yourself and the world a favor and don't ever touch anything security-related. cu 59cobalt -- "If a software developer ever believes a rootkit is a necessary part of their architecture they should go back and re-architect their solution." --Mark Russinovich
From: Ansgar -59cobalt- Wiechers on 13 Apr 2010 17:00 gufus <stop.nospam.gbbsg(a)shaw.ca> wrote: > 12 Apr 10, Grant Taylor writes to All: >> Conversely if the web servers were running a software based firewall, >> they could easily filter SNMP and / or RPC traffic so that only the >> management station(s) could access them. There by protecting them >> from the program running locally on the compromised server. >> >> These types of side attacks (if you will) are what I'm saying that a >> software based firewall will help prevent. > > I still think your way is more secure. IMHO. That's simply because you entirely failed to understand the implications. cu 59cobalt -- "If a software developer ever believes a rootkit is a necessary part of their architecture they should go back and re-architect their solution." --Mark Russinovich
From: gufus on 13 Apr 2010 17:43 Hello, Ansgar! You wrote on 13 Apr 2010 20:58:45 GMT: AcW> AcW> Please do yourself and the world a favor and don't ever touch anything AcW> security-related. AcW> :-) -- With best regards, gufus. E-mail: stop.nospam.gbbsg(a)shaw.ca
From: gufus on 13 Apr 2010 11:51
Hi Ansgar, 13 Apr 10, Ansgar -59cobalt- Wiechers writes to Gypsy BBS: >> I still think your way is more secure. IMHO. > That's simply because you entirely failed to understand the > implications. Have fun hashing it out with Grant. :) -- K Klement Enhance your marketing at http://www.gypsy-designs.com mailto:info(a)gypsy-designs.com Gypsy Designs Fax: (403) 242-3221 .... Take the bull by the hand and avoid mixed metaphors. |