This shouldn't be an issue for most of us. My DMZ boxes are already as hardened as I can get them, with the firewall ( ingress and egress ), patches, and IP filtering. I would think that most ISP's and corporate networks would be using the same techniques. We gave up relying on M$ and other vendor patches keeping us safe.
Our solution is to block all traffic except that which is explicitly needed by any server. Our DNS/SmarterMail/FTP server only has those ports exposed to the Internet that are absolutely needed. Management from inside to our DMZ is limited to a few workstations by the firewall. If someone needs to work from home, they have to VPN inside, hit a registered workstation/server, and THEN hit our DMZ boxes. Convoluted, yes. PITA at times, sure. But it's pretty damn secure. 5 years and we haven't had a break yet ( crossing fingers ). Karl Drugge -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Reimer Sent: Friday, April 13, 2007 1:29 PM To: [EMAIL PROTECTED] Subject: RE: [Declude.JunkMail] Vulnerability in RPC on Windows DNS Server Could Allow Remote Code Execution While we are on the topic of vulnerabilities I just saw 2 new vulnerabilities found in clamav. Mark Reimer IT System Admin American CareSource 972-308-6887 -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Reimer Sent: Friday, April 13, 2007 12:26 PM To: [EMAIL PROTECTED] Subject: RE: [Declude.JunkMail] Vulnerability in RPC on Windows DNS Server Could Allow Remote Code Execution You could do Microsoft's registry workaround if you are not using the remote management. Mark Reimer IT System Admin American CareSource 972-308-6887 -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt Sent: Friday, April 13, 2007 10:58 AM To: [EMAIL PROTECTED] Subject: Re: [Declude.JunkMail] Vulnerability in RPC on Windows DNS Server Could Allow Remote Code Execution > However, for ISP's that use MS DNS servers and do remote management > from the inside - their customers could potentially exploit them. > I have worked with folks who run services other than mail on their DNS > servers. One example is FTP. With passive ftp high ports 1024+ need > to be open both ways. So if they are using standard ACL's and not a > firewall this could lead to some trouble as well. Stateful firewalls don't need to open these ports for passive FTP. The FTP connection is established on the standard port after which the passive port is shared with the client and the firewall tracks this and allows the connection. As a rule of thumb, RPC should never be exposed to untrusted IP space. It is also odd and possibly grossly incompetent of Microsoft to choose to use ports 1024+ for such purposes, but I'm thinking that they have some weakly justifiable reason to do this as a "feature". Matt --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com. --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com. --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com. --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
