x86 Down?!

[Ersan]

I don't know if you can do it without layer7 analysis, you can try -m string.  I don't use iptables.

Trying to discern the HTTP_HOST header before layer7 is probably impossible, which is why it shouldn't be handled at the network level.  You'd probably have to use -m layer7 if you want to use iptables.

As for defending myself, I decided to ask a few people to read this thread, several of them work for savvis, a couple work at softlayer, one at dreamhost, one at akamai (she did make fun of me for not knowing where mantioba was, though), and one at theplanet (not to mention I myself have more experience dealing with large-scale networks than you, since this is apparently a penis contest now...), all as network technicians, and they all came to the same conclusion, you're the idiot, not me.  Your approach gives no thought whatsoever to performance, and is overly paranoid, but also lacks understanding.  It isn't secure because you have systems on your private LAN and off your private LAN running on the same physical machine, and you trust VMWare implicitly.

Your network is a wonderful playground and all that, and actually can host websites effectively, but not on different servers, even if you had more than one IP it's just dumb.  You run one web server and learn how to chroot and manage permissions, you don't spawn a new virtual machine everytime you want to host a new website, it's a waste.  Database servers were meant to be run as servers for scalability and performance by separating them from the same physical machine as the applications using them, not security, they are all capable of using unix sockets too, you know.

[Sidoh]

How many times has he told you that introducing the structure he's using doesn't affect performance to any noticeable degree?

[Ersan]

Right, running 8 operating systems on one physical system simultaneously doesn't adversely affect performance...  Maybe when pigs fly.

[Sidoh]

Right, running 8 operating systems on one physical system simultaneously doesn't adversely affect performance...  Maybe when pigs fly.

He's not hosting a high traffic website.  I think he (and others) have mentioned that several times as well.

[Ersan]

Which is why I don't care how he runs it, I just don't want other people running theirs the same way.

[iago]

Right, running 8 operating systems on one physical system simultaneously doesn't adversely affect performance...  Maybe when pigs fly.

Let's figure it out. 

8 operating systems, each of which use ~50mb of RAM.  I can verify that when I get home, but it's around there.  That's 400mb RAM.  I have 2gb.  That's safe.

Each of the operating systems use, on average, 0CPU, except when something is going on.  So they might use on average 1% CPU, but probably less than that.  That's 8% CPU usage. 

I have seen no adverse affects from it, other than when they all boot up simultaneously. 

[iago]

As for defending myself, I decided to ask a few people to read this thread, several of them work for savvis, a couple work at softlayer, one at dreamhost, one at akamai (she did make fun of me for not knowing where mantioba was, though), and one at theplanet (not to mention I myself have more experience dealing with large-scale networks than you, since this is apparently a penis contest now...), all as network technicians, and they all came to the same conclusion, you're the idiot, not me.  Your approach gives no thought whatsoever to performance, and is overly paranoid, but also lacks understanding.  It isn't secure because you have systems on your private LAN and off your private LAN running on the same physical machine, and you trust VMWare implicitly.

Your network is a wonderful playground and all that, and actually can host websites effectively, but not on different servers, even if you had more than one IP it's just dumb.  You run one web server and learn how to chroot and manage permissions, you don't spawn a new virtual machine everytime you want to host a new website, it's a waste.  Database servers were meant to be run as servers for scalability and performance by separating them from the same physical machine as the applications using them, not security, they are all capable of using unix sockets too, you know.

You obviously haven't read my reasoning.  And I'd be interested in talking to these people that you invented, they sound interesting.  Are they all out to get you, too?

I lack no understanding.  In fact, I used to run my server exactly how you suggested.  But I wanted to do it differently, for academic reasons and for security reasons.

I should point out that I am NOT doing hosting.  So get that out of your head.

There's no such thing as being too paranoid or too secure, either, as long as it's still usable.  And it is, haven't you noticed?  When have you ever had a problem with server performance (that wasn't caused by network failure)? 

[nslay]

As for defending myself, I decided to ask a few people to read this thread, several of them work for savvis, a couple work at softlayer, one at dreamhost, one at akamai (she did make fun of me for not knowing where mantioba was, though), and one at theplanet (not to mention I myself have more experience dealing with large-scale networks than you, since this is apparently a penis contest now...), all as network technicians, and they all came to the same conclusion, you're the idiot, not me.  Your approach gives no thought whatsoever to performance, and is overly paranoid, but also lacks understanding.  It isn't secure because you have systems on your private LAN and off your private LAN running on the same physical machine, and you trust VMWare implicitly.

Your network is a wonderful playground and all that, and actually can host websites effectively, but not on different servers, even if you had more than one IP it's just dumb.  You run one web server and learn how to chroot and manage permissions, you don't spawn a new virtual machine everytime you want to host a new website, it's a waste.  Database servers were meant to be run as servers for scalability and performance by separating them from the same physical machine as the applications using them, not security, they are all capable of using unix sockets too, you know.

You obviously haven't read my reasoning.  And I'd be interested in talking to these people that you invented, they sound interesting.  Are they all out to get you, too?

I lack no understanding.  In fact, I used to run my server exactly how you suggested.  But I wanted to do it differently, for academic reasons and for security reasons.

I should point out that I am NOT doing hosting.  So get that out of your head.

There's no such thing as being too paranoid or too secure, either, as long as it's still usable.  And it is, haven't you noticed?  When have you ever had a problem with server performance (that wasn't caused by network failure)? 

I'm not trying to defend Ersan ... I haven't even read the entire thread.  You mentioned that you can never be too secure or too paranoid.  If you believe that, then you most certainly shouldn't be hosting with VMWare, but instead with Linux's sandbox or BSD's jail.  These features are open, whereas VMWare is not. You also most certainly should NOT be using Linux.  You should be using OpenBSD or something like VMS.  OpenBSD has a proactive security auditing policy and a secure programming philosophy that Linux and even FreeBSD lack.  As for VMS, VMS was deemed "unhackable" at Defcon 9 and was asked not return to future Defcon conferences.  VMS is the type of system a bank might use and one that is most certainly behind lock and key, if not armed guards.  The problem with VMS is you need to get a license and a VAX, Alpha or Itanium machine to run it (you may also use simh).  The hobbyist license is free but you have to join a bunch of communities and such. 
Digressing, DEC, who made VMS, were the ones that did significant research in OS design and are responsible for things like SMP.  All these "new" features in Linux, BSD and Windows, such as SMP, VMS had 20 years ago.
To all those Microsoft zealots.  Sure Microsoft hired VMS guys to make NT ... but what they didn't tell you was DEC fired those guys.

Links:
http://www.openbsd.org/security.html
http://www.openvms.org/

EDIT:
Corroboration that you should NOT be using Linux.
http://sdf.lonestar.org/index.cgi?faq?MISC?03

03] HAS SDF EVER BEEN COMPROMISED?

     The first time was in 1991 when a person from France dialed in
     to our machine (then running SystemVr3.2 1.0) and was able to get
     root (administrative) access.  He promptly notified us.

     During our short lived stint of attempting to run SDF under 'linux' on
     IBM compatibles the system was compromised a number of times, but the
     individuals who did it were much more secretive and malicious.  For
     each case users were forced to change their passwords and patched
     software was installed (though this of course introduced other bugs
     that could be found later on)

     After dumping linux and x86 in favour of return to real computers, we
     have not had any major security issues.  We are however, just as vigilant
     to be sure that your account here on SDF is safe and that any security
     issues are resolved quickly before public announcements (cert, et cetera)

     Please NOTE, an administrator will NEVER ask you for your password.
     Anyone impersonating an administrator is BREAKING THE LAW.  You can
     report them to your local authorities if you identify them.

SDF runs NetBSD now.

[iago]

I'm not trying to defend Ersan ... I haven't even read the entire thread.  You mentioned that you can never be too secure or too paranoid.  If you believe that, then you most certainly shouldn't be hosting with VMWare, but instead with Linux's sandbox or BSD's jail.  These features are open, whereas VMWare is not. You also most certainly should NOT be using Linux.  You should be using OpenBSD or something like VMS.  OpenBSD has a proactive security auditing policy and a secure programming philosophy that Linux and even FreeBSD lack.  As for VMS, VMS was deemed "unhackable" at Defcon 9 and was asked not return to future Defcon conferences.  VMS is the type of system a bank might use and one that is most certainly behind lock and key, if not armed guards.  The problem with VMS is you need to get a license and a VAX, Alpha or Itanium machine to run it (you may also use simh).  The hobbyist license is free but you have to join a bunch of communities and such. 
Digressing, DEC, who made VMS, were the ones that did significant research in OS design and are responsible for things like SMP.  All these "new" features in Linux, BSD and Windows, such as SMP, VMS had 20 years ago.
To all those Microsoft zealots.  Sure Microsoft hired VMS guys to make NT ... but what they didn't tell you was DEC fired those guys.

Links:
http://www.openbsd.org/security.html
http://www.openvms.org/

EDIT:
Corroboration that you should NOT be using Linux.
http://sdf.lonestar.org/index.cgi?faq?MISC?03

03] HAS SDF EVER BEEN COMPROMISED?

     The first time was in 1991 when a person from France dialed in
     to our machine (then running SystemVr3.2 1.0) and was able to get
     root (administrative) access.  He promptly notified us.

     During our short lived stint of attempting to run SDF under 'linux' on
     IBM compatibles the system was compromised a number of times, but the
     individuals who did it were much more secretive and malicious.  For
     each case users were forced to change their passwords and patched
     software was installed (though this of course introduced other bugs
     that could be found later on)

     After dumping linux and x86 in favour of return to real computers, we
     have not had any major security issues.  We are however, just as vigilant
     to be sure that your account here on SDF is safe and that any security
     issues are resolved quickly before public announcements (cert, et cetera)

     Please NOTE, an administrator will NEVER ask you for your password.
     Anyone impersonating an administrator is BREAKING THE LAW.  You can
     report them to your local authorities if you identify them.

SDF runs NetBSD now.

Well, to answer part of your response: security is relative to the person using a system.  I am much more confident in my ability to administrate Linux and keep it secure than BSD.  I could easily open up a hole in BSD without realizing it, whereas I have a pretty keen understanding about what's going on with Linux.

But you're right -- I don't trust giving people local user accounts on Linux.  I think it's probably quite possible to break out of a user account and gain root.  That's a good argument right there for keeping systems on different virtual machines.

And in terms of VMWare -- I've never heard of an attack that would allow a user to break out of a VMWare session.  It would be a very interesting avenue to research, though, because I bet there's some way.  It'd be at a kernel/driver level, though, so it wouldn't be easy.  I'd be interested in researching that, though.

[nslay]

I'm not trying to defend Ersan ... I haven't even read the entire thread.  You mentioned that you can never be too secure or too paranoid.  If you believe that, then you most certainly shouldn't be hosting with VMWare, but instead with Linux's sandbox or BSD's jail.  These features are open, whereas VMWare is not. You also most certainly should NOT be using Linux.  You should be using OpenBSD or something like VMS.  OpenBSD has a proactive security auditing policy and a secure programming philosophy that Linux and even FreeBSD lack.  As for VMS, VMS was deemed "unhackable" at Defcon 9 and was asked not return to future Defcon conferences.  VMS is the type of system a bank might use and one that is most certainly behind lock and key, if not armed guards.  The problem with VMS is you need to get a license and a VAX, Alpha or Itanium machine to run it (you may also use simh).  The hobbyist license is free but you have to join a bunch of communities and such. 
Digressing, DEC, who made VMS, were the ones that did significant research in OS design and are responsible for things like SMP.  All these "new" features in Linux, BSD and Windows, such as SMP, VMS had 20 years ago.
To all those Microsoft zealots.  Sure Microsoft hired VMS guys to make NT ... but what they didn't tell you was DEC fired those guys.

Links:
http://www.openbsd.org/security.html
http://www.openvms.org/

EDIT:
Corroboration that you should NOT be using Linux.
http://sdf.lonestar.org/index.cgi?faq?MISC?03

03] HAS SDF EVER BEEN COMPROMISED?

     The first time was in 1991 when a person from France dialed in
     to our machine (then running SystemVr3.2 1.0) and was able to get
     root (administrative) access.  He promptly notified us.

     During our short lived stint of attempting to run SDF under 'linux' on
     IBM compatibles the system was compromised a number of times, but the
     individuals who did it were much more secretive and malicious.  For
     each case users were forced to change their passwords and patched
     software was installed (though this of course introduced other bugs
     that could be found later on)

     After dumping linux and x86 in favour of return to real computers, we
     have not had any major security issues.  We are however, just as vigilant
     to be sure that your account here on SDF is safe and that any security
     issues are resolved quickly before public announcements (cert, et cetera)

     Please NOTE, an administrator will NEVER ask you for your password.
     Anyone impersonating an administrator is BREAKING THE LAW.  You can
     report them to your local authorities if you identify them.

SDF runs NetBSD now.

Well, to answer part of your response: security is relative to the person using a system.  I am much more confident in my ability to administrate Linux and keep it secure than BSD.  I could easily open up a hole in BSD without realizing it, whereas I have a pretty keen understanding about what's going on with Linux.

But you're right -- I don't trust giving people local user accounts on Linux.  I think it's probably quite possible to break out of a user account and gain root.  That's a good argument right there for keeping systems on different virtual machines.

And in terms of VMWare -- I've never heard of an attack that would allow a user to break out of a VMWare session.  It would be a very interesting avenue to research, though, because I bet there's some way.  It'd be at a kernel/driver level, though, so it wouldn't be easy.  I'd be interested in researching that, though.

As for BSD.  Yeah, you could easily open up a hole in FreeBSD if you're not careful about what ports you install.  Only a month ago I discovered the utility portaudit which checks the package database for vulnerable software ... and thats 2 years after I started using FreeBSD.  Speaking of security, check out this new feature coming in FreeBSD 6.2: Security Event Auditing
http://www.securityfocus.com/columnists/422
It treats logging as a stream that other software can patch into.  It is customizable to the point where you can pinpoint the exact action of the exact user that did something.  Also disallows root to tamper with the logging.

Yeah, I've always wondered how one might detect if an OS is jailed or not

[Skywing]

And in terms of VMWare -- I've never heard of an attack that would allow a user to break out of a VMWare session.  It would be a very interesting avenue to research, though, because I bet there's some way.  It'd be at a kernel/driver level, though, so it wouldn't be easy.  I'd be interested in researching that, though.

There has actually been some recent research into timing attacks that utilize the fact that processor resources are shared between high and low privileged components.  Specifically, attacks that allow a low privileged component to divine information about what a high privileged component might be doing (such as parts of a signing key for something like an ssh logon attempt).  You might look at this paper for more about that.  I would imagine that at this point the attack is more theoretical than practical, but the basic idea is that you can use the way that branch taken / branch not taken are cached for speculative execution in order to determine (with some margin of error) whether a program is taking or not taking a particular branch.  The authors of the linked paper used this and some knowledge of how OpenSSL works for performing RSA signing operations (actually, a deliberately modified version of OpenSSL's RSA functions for simplicity, but the basic idea is still applicable) to be able to determine which branches a program that signs a hash with an RSA key takes.  This turns out to be significant, because by counting the taken / not taken branches, you can derive a significant portion of the private key bits used to create the signature.

What this boils down to is a theoretical attack whereby someone who gains low privileged access to a single system (say as a limited user) or a shared system (say a VM on a machine that hosts other VMs or services) could attempt to steal cryptographic keys being used for signatures on processes (or VMs) that the malicious user doesn't have direct access to.  Assuming that these keys could be used to perform a logon to a more privileged system, this could be used to eventually escalate privileges after capturing keys that might be used to perform (or take over an existing session) of, say, a remote logon as root / an administrator.

I don't think that I would use this as a reason to declare using VMs for isolation purposes useless for security.  There are a number of practical barriers that I think would in practice make mounting such an attack successfully against a real life system very difficult.  Nonetheless, there are still theoretically ways to break out of things like VMs where access is controlled by some shared secret, and calculations / checking of that secret is performed using the same resources that an attacker might also be able to utilize for their own computations.

[iago]

I've read a little about timing attacks before (mostly in the book "Silence on the Wire" by Zalewski), and they're a neat concept.  It's difficult enough to do it between processes, but doing it between VMWare sessions would be really tricky. 

I hadn't even considered the possibility of using it to glean information from other virtual machines, though, so thanks for bringing it up. It's not a fatal blow, but it's definitely an interesting case.

[Skywing]

I've read a little about timing attacks before (mostly in the book "Silence on the Wire" by Zalewski), and they're a neat concept.  It's difficult enough to do it between processes, but doing it between VMWare sessions would be really tricky. 

I hadn't even considered the possibility of using it to glean information from other virtual machines, though, so thanks for bringing it up. It's not a fatal blow, but it's definitely an interesting case.

It should be noted, however, that the attack the paper proposes is significantly more practical than previous attacks (which have typically been based on timing memory latency to detect accesses that were already stored in the L1/L2 caches or have to go out to system memory) in that it has been successfully used to retrieve much more information about the secret key in question.  Although the circumstances described in the paper aren't exactly ordinary operating circumstances, the author managed to retrieve something on the order of 90% or so of the RSA key used for a signing operation in just a single signing operation being observed - orders of magnitude better than previous "side-channel" timing attacks.

[iago]

Wow, that's impressive.  I'm going to have to read through that paper.