--- On Thu, 10/27/11, Eugene <[address removed]> wrote:
> From: Eugene <[address removed]>
> Subject: Re: [linux-5] Moving back to Windows from Linux?
> To: [address removed]
> Date: Thursday, October 27, 2011, 4:38 PM
> On Thu, Oct 27, 2011 at 4:23 PM, kit <[address removed]> wrote:
> Regarding patching, haven't had to look after a server for years, so take this however you want:
> - There were anti-virus IPS products that claimed to do virus/attack vector detection and blocking at the firewall. Theoretically allows you to safely run unpatched systems behind the firewall. Don't know how successful these are, false negative and positive rates, signature update speed. Works with HTTPS too if you install the SSL cert into the security software.
> > It doesn't mitigate insider attacks.
If insider is in the Intranet, then standard network configuration for DMZ will mitigate.
> > - Heard that you can use cluster failover systems to help with patching. Patch the standby system, force a failover to it. If it doesn't run properly, force a failover back to the unpatched system, then restore the problem server from backup.
> Always test updates on UAT machines before deploying the updates on production machines. Why take the risk?
Why not do both? Isn't that even less risky? Can you guarantee that if it works in the UAT machine, it will work in the production machine? Maybe there is a device driver conflict. Does your UAT machine have the exact same hardware? How about number of CPUs or RAM? Unlikely, but a bug could be triggered by some unusual combination of hardware, otherwise the patch writers would have caught it.
> - If you are running hardened server, minimum services, blocked ports, chances of being exploited through an OS vulnerability are low IMHO.
Attack surface is small. Most network exploits are at application or web server level or obscure ports? Not sure. Easier to recover from a badly patched application.
> Not necessary. You are still potentially vulnerable to security issues in the network protocol implementations, network device implementations, etc, i.e. CVE-2008-3276, CVE-2009-0065, CVE-2009-1385, CVE-2009-4536, etc.
Agreed, that's why I said "low" and "small."