Avira's firewall
in [Firewalls]
|
From: Grant Taylor on 13 Apr 2010 23:01 Ansgar -59cobalt- Wiechers wrote: > 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. I was just using SNMP / RPC as an example. For the sake of discussion, please provide a service that would be needed internally to support line-of-business applications (even in a DMZ) that would not be allowed externally. > 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. I do understand SNMP well enough for this discussion. There is nothing that prevents the compromised server from spoofing any thing. However, I think we can agree on the fact that there is an order of magnitude difference in complexity in mal-ware that is capable of spoofing IP and possibly MAC addresses verses not doing so and relying on the OS IP stack. Likewise, I believe there is quite a bit of difference in the number of each. You can't protect against everything. There is a point of diminishing return with more security. > 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. No. I mean an edge firewall that is (hopefully) only allowing replies from TCP ports 80 and 443 (and possibly some ICMP) as well as only allowing the internal subnet as a source IP range. I am perfectly aware of what a reverse (or forward) proxy is for and can do. I was not bringing them in to this discussion. > As explained above, this won't necessarily work as you expect. Aside from IP spoofing and your opinion that the firewalls present a bigger target, I fail to see how this will not work or at least help prevent (read: slow down / limit attack) internally initiated attacks. > 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. Other than the fact that SSH is a little more intelligent about the application layer, I believe it too is equally susceptible to the IP spoofing that you were referring to above. (Granted, once successfully spoofed, there is a greater hurtle to overcome at the application layer with encryption RSA keys and the likes.) > 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? I will agree that SSH is quite a bit more hardened than most public services, and can probably withstand quite an onslaught. For the sake of discussion, suppose that the server farm that we are talking about is for multiple MS-SQL servers that have to allow inbound connections, at least from the systems behind the edge firewall. > 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. That is a valid opinion that I can't argue with. Nor can I say that it's logically wrong. The only thing that I can say is that mine differs from yours. > 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. I was referring to something specifically meant to remotely manage the configuration of aspects of services in such as you can control what IPs that SSH (or what ever) will talk to. I am referring to a server farm / DMZ of servers for a given task, off by them selves. I.e. a subnet dedicated to web servers or email servers or db servers or ... Or do I mis-understand you in such as you are stating to put each individual server in it's own DMZ away from other servers? Grant. . . .
From: Grant Taylor on 13 Apr 2010 23:02 Ansgar -59cobalt- Wiechers wrote: > True, but besides the point. Repeating myself: even the best employees > are still human and *will* make mistakes here and there. Unnecessarily > raising the complexity of a system will only increase the chances of > this happening. I agree. The human element of a network is (at times) one of it's weakest links. Grant. . . .
From: gufus on 14 Apr 2010 09:40 Hi Grant, 13 Apr 10, Grant Taylor writes to All: >> True, but besides the point. Repeating myself: even the >> best employees are still human and *will* make mistakes > I agree. The human element of a network is (at times) one > of it's weakest links. Hmmmm... sounds like an echo here. <grin> With only basic networking skills, I'm taking notes on you discussion with Ansgar, interesting to-say-the least. gufus -- K Klement Enhance your marketing at http://www.gypsy-designs.com mailto:info(a)gypsy-designs.com Gypsy Designs Fax: (403) 242-3221 .... A man without a religion is like a fish without a bicycle.
From: Ansgar -59cobalt- Wiechers on 14 Apr 2010 17:54 Grant Taylor <gtaylor(a)riverviewtech.net> wrote: > Ansgar -59cobalt- Wiechers wrote: >> 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. > > I was just using SNMP / RPC as an example. > > For the sake of discussion, please provide a service that would be > needed internally to support line-of-business applications (even in a > DMZ) that would not be allowed externally. The only services that come to mind are Remote Desktop and SSH. >> 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. > > I do understand SNMP well enough for this discussion. There is > nothing that prevents the compromised server from spoofing any thing. > > However, I think we can agree on the fact that there is an order of > magnitude difference in complexity in mal-ware that is capable of > spoofing IP and possibly MAC addresses verses not doing so and relying > on the OS IP stack. No, actually we can't agree on that, as it's just plain wrong. Unless you are talking about script-kiddy level, spoofing of addresses (either IP or MAC) is the most basic of the basics. And in case of UDP sending the packet with a fake sender address is all there is to it. It's neither difficult nor complex at all. [...] >> As explained above, this won't necessarily work as you expect. > > Aside from IP spoofing and your opinion that the firewalls present a > bigger target, I fail to see how this will not work or at least help > prevent (read: slow down / limit attack) internally initiated attacks. Because with UDP you don't need to establish a connection. You write the spoofed sender address to the packet, fire and forget. >> 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. > > Other than the fact that SSH is a little more intelligent about the > application layer, I believe it too is equally susceptible to the IP > spoofing that you were referring to above. On top of being a lot more intelligent at the application layer, SSH (unlike SNMP) is also TCP-based. How do you think the compromised host is going to receive TCP response packets when they're not going back to the attacker's IP address? Unlike UDP, TCP is not stateless. > (Granted, once successfully spoofed, there is a greater hurtle to > overcome at the application layer with encryption RSA keys and the > likes.) That (and the user/source restrictions) come on top of the problem of intercepting/spoofing a TCP connection. >> 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? > > I will agree that SSH is quite a bit more hardened than most public > services, and can probably withstand quite an onslaught. > > For the sake of discussion, suppose that the server farm that we are > talking about is for multiple MS-SQL servers that have to allow inbound > connections, at least from the systems behind the edge firewall. Please be more specific about the scenario. By "from the systems behind the edge firewall" you mean connections from within some LAN (management or whatever) to the servers in the DMZ? What kind of connection? Why wouldn't RDP suffice? Why can't the connection be tunneled (e.g. with stunnel) in case RDP does not suffice? >> 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. > > I was referring to something specifically meant to remotely manage the > configuration of aspects of services in such as you can control what > IPs that SSH (or what ever) will talk to. > > I am referring to a server farm / DMZ of servers for a given task, off > by them selves. I.e. a subnet dedicated to web servers or email > servers or db servers or ... In a scenario like that: if an attacker can exploit one server, he can exploit the other (similar) servers just the same. No need at all to take a different route for compromizing them. > Or do I mis-understand you in such as you are stating to put each > individual server in it's own DMZ away from other servers? For a server farm as you described above: no. But as explained above, there's no need to further isolate them anyway. For servers carrying out different tasks it might be an option. 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: Grant Taylor on 14 Apr 2010 19:38
Ansgar -59cobalt- Wiechers wrote: > The only services that come to mind are Remote Desktop and SSH. RDP. > No, actually we can't agree on that, as it's just plain wrong. Unless > you are talking about script-kiddy level, spoofing of addresses > (either IP or MAC) is the most basic of the basics. And in case of > UDP sending the packet with a fake sender address is all there is to > it. It's neither difficult nor complex at all. I was referring to script-kiddy. I'm of the opinion that little will stop a properly motivated skilled attacker. The rest of the chaff is what I'm thinking about protecting against. > On top of being a lot more intelligent at the application layer, SSH > (unlike SNMP) is also TCP-based. How do you think the compromised > host is going to receive TCP response packets when they're not going > back to the attacker's IP address? Unlike UDP, TCP is not stateless. The compromised host would need to be in the return path or local LAN of the spoofed host. > That (and the user/source restrictions) come on top of the problem of > intercepting/spoofing a TCP connection. Agreed. > Please be more specific about the scenario. By "from the systems > behind the edge firewall" you mean connections from within some LAN > (management or whatever) to the servers in the DMZ? What kind of > connection? Why wouldn't RDP suffice? Why can't the connection be > tunneled (e.g. with stunnel) in case RDP does not suffice? Let's say that it's a routed VLAN that is firewalled and using globally routable IPs for the servers in said VLAN. (Said another way, the same broadcast domain.) RDP or SSH should suffice for management. But what about some other service that is used by the server. - I've never messed with it, what ports need to be open for MS Cluster Server to communicate with each other? > In a scenario like that: if an attacker can exploit one server, he > can exploit the other (similar) servers just the same. No need at all > to take a different route for compromizing them. As long as the edge firewall will allow access to the other servers (not doing some sort of load balancing based on source IP that would ensure that one IP would talk to one server) sure. That is also assuming that all the servers are serving the same content. That assumption might not be the case for a web farm that assigns a (vulnerable) web site to some but not all servers. Grant. . . . |