Re: [linux-5] Moving back to Windows from Linux?

From: Wong Boon H.
Sent on: Thursday, October 27, 2011 10:45 PM
Most of our attacks is the result of our end users opening infected email attachments. (fyi, we have migrated our email server to Zimbra (It's free!) running on Ubuntu server. It's really impressive!)

There is zero attack due to unpatch system so far. So I really think the patch issue is over-hype by security companies to boost their products sales. Not to mention quite a few of our downtime is ironically, due to unsuccessful patching. The most risky part is actually insider job. Those who have authority in administrator access need to be trustworthy.

As for identical system, it isn't an issue for me since all our servers are virtualized under vmware ESXi (it's free!) that can be easily cloned. But I have no experience in clustering. Maybe I give it a try when I have the bandwidth. 

Cheers,
Boon Hong

From: kit <[address removed]>
To: [address removed]
Sent: Thursday, 27 October[masked]:22 AM
Subject: Re: [linux-5] Moving back to Windows from Linux?


--- 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[masked], CVE[masked], CVE[masked], CVE[masked], etc.

Agreed, that's why I said "low" and "small."

> Eugene





--
Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ([address removed])
http://www.meetup.com/sg-linux/
This message was sent by kit ([address removed]) from The Singapore Linux Meetup Group.
To learn more about kit, visit his/her member profile: http://www.meetup.com/sg-linux/members/1761/
To unsubscribe or to update your mailing list settings, click here: http://www.meetup.com/sg-linux/settings/
Meetup, PO Box 4668 #37895 New York, New York[masked] | [address removed]



People in this
Meetup are also in:

Sign up

Meetup members, Log in

By clicking "Sign up" or "Sign up using Facebook", you confirm that you accept our Terms of Service & Privacy Policy