Of course you can't protect sensitive data if it has to travel from you to the user, but it's often not the case that it needs to, in the case i was giving as an example the user data was not sensitive but the program that ran on the server was, so what mattered was to make the actual program unstealable (and thus the actual server unhackable, regardless of if someone can or can not sniff your outgoing data).

In the case of a website there are similar use cases for example, if your users have to enter their CC info once to purchase on your website then this means if your server can't be hacked even if someone manages to find a way to put himself in the middle and "sniff" all data he would never get access to current customers credit card infos, only future ones, this is a pretty major risk reduction for your users and something you can defend against if you're not the party that got hacked but somewhere on the net outside of your control as the blame will transfer too. So this is a good example use case for a website, it allows for example a third party's security being responsible over the wire for a small amount of user CC info loss vs you being fully responsible for 100% of your users CC detail loss. That works for any one way data transmission that you need to store but not necessarily make available again.

Ok, I see your usecase now... but I still think "unhackable" and "unstealable" are a little bit big words for what is only a "harder to hack" target and a "harder to steal" program. As long as there are connections to the outside world (which would in the extreme case include power cords), and the server is not standing in a room deep below earth surface with all entrances to the room sealed, "un-anything" is a gross oversimplification and marketing stunt at best, or a blatant lie at worst.

Hard and maybe even expensive to break in, thus not making sense to even try to do so for anything besides high-profile targets? Yes. Impossible? No.

Then in your second usecase you use the words "risk reduction" and "not fully responsible"... doesn't sound fully hackproof to me.

I second Luckless: if you know how to make servers 100% hackproof, tell us... we would love to know the secret to getting rich, because governments and private companies all over the world would waste billions on such tech!

Better yet, don't tell us, and sell it yourself.

Well i just gave you a website use case as you asked, i never claimed "i" could make that unhackable, but what i'm doing (that is not a website, and doesn't store any sensitive data, even of the type that only comes through the wire once) i'm pretty sure i can.

Also when i use risk reduction i do it on the user side, you're reducing the user's risk, i never claimed you could secure the whole internet, but if someone does a man in the middle attack somewhere on the net, as far as i'm concerned your server didn't "get hacked". Not that there aren't ways to protect against that too however.

In "my" use case however what matters is : program in ram doesn't get stolen, and that only requires no one being able to access that either physically (entering the room) or by software (accessing the server and downloading it). That does quite limit the subset of précautions you need to take.

I do think you can make Something pretty close for a website but in the case of a generic website you have no control over the clients, so you'll never be able to secure everything (the connection and the user side) just your part of it (the server side), that too can be pretty unhackable, but forget about using any of the classical tools and only if you limit your definition of "hack" to getting access to the server (and not just to listening for data on the network).

In "my" use case however what matters is : program in ram doesn't get stolen

Too late - the CPU already "stole" it. It had to make a copy to put it in cache to actually run it. The OS might even make copies and put them on disk to free up physical RAM, so the OS is stealing it too. And if the CPU and OS can copy it... so can someone else.

;)

In "my" use case however what matters is : program in ram doesn't get stolen

Too late - the CPU already "stole" it. It had to make a copy to put it in cache to actually run it. The OS might even make copies and put them on disk to free up physical RAM, so the OS is stealing it too. And if the CPU and OS can copy it... so can someone else.

;)

The cpu definately doesn't "make copies" of your program in any sense you can reasonably give to the word copy. Small chunks may end up in there in cache i guess but that's about it and if the "cpu" steals (weird wording for "runs") my program it certainly doesn't mean it's any less safe than it was in ram, everything else still applies.

And no the OS isn't copying it to disk, there is no swap / all form of caching is disabled (the server is dedicated to a single task, and if it needed to swap for any reason it would crumble anyway considering the ram amounts i'm using, i have 2X as much ram as i have disk space). I considered rolling my own os for this but it isn't worth the effort.

there is no swap / all form of caching is disabled (the server is dedicated to a single task, and if it needed to swap for any reason it would crumble anyway considering the ram amounts i'm using, i have 2X as much ram as i have disk space). I considered rolling my own os for this but it isn't worth the effort.

It might very much be worth the effort, if you want to reach your goal.

Imagine I manage to get a root shell on your machine, what prevents me (assuming a Linux system now) from creating a swapfile and running swapon /a and setting swappiness to 100? Then I'll just upload the file to another machine.

In fact, I could target only the pages that I'm interested in after a look at /proc/pid/maps and I could pipe them onto a socket, removing the need of creating a file on an existing disk...

there is no swap / all form of caching is disabled (the server is dedicated to a single task, and if it needed to swap for any reason it would crumble anyway considering the ram amounts i'm using, i have 2X as much ram as i have disk space). I considered rolling my own os for this but it isn't worth the effort.

It might very much be worth the effort, if you want to reach your goal.

Imagine I manage to get a root shell on your machine, what prevents me (assuming a Linux system now) from creating a swapfile and running swapon /a and setting swappiness to 100? Then I'll just upload the file to another machine.

In fact, I could target only the pages that I'm interested in after a look at /proc/pid/maps and I could pipe them onto a socket, removing the need of creating a file on an existing disk...

Assuming wrongly, running Windows server core in my case, however the whole point is you can't get to the step where you can "run" anything, if you can you don't need to copy anything, you can already read all of the ram as root, the point is you're not going to get access to begin with. There's no "access" to get to begin with, not with a password, not with another method of authentication, it's not meant to be managed and the tradeoff is if something goes wrong i need to go to the Datacenter and fix it there (which is a pain too even if i go).

The only advantage to rolling my own OS is to lower the surface of attack drastically (but it's already pretty low to begin with on new server OSes and since i'm not remotely managing or anything you'd need to find a zero day exploit in http.sys pretty much to get access to anything, which is probably one of the most rewieved piece of code in the world) and to have control of the code myself. It's a certain advantage but the work vs risk ratio isn't there so i'm taking the little risk to avoid the huge cost (that i can't pay for to begin with anyway so it's kind of a moot point :) ). So writing my own server was worth it (little work, huge surface reduction) but my own OS not quite.

If things go well i'll probably do that in a couple years however.

"windows server, no access possible"

Maybe I'm over-pessimizing here, but are you kidding me?

One of the most serious defects in every version of Windows during the last 10 years (the newer the worse!) is that you don't know what's running at what time(1), you don't know what each of the hundred services is doing exactly(2), you don't know who can access the machine, you don't know which services provide intentional or unintentional backdoors, and you don't know what data the machine regularly sends to whomever on its own behalf.

Admittedly, the "server" versions generally appear to be somewhat more sane than the desktop versions, but Windows most definitively is not something you can trust as "unhackable" or "not connecty", or "not chatty".


(1) Yes, you could know, in theory. But in practice, you have no darn clue because there is no way you can even dig through the ten thousand policies and tasks before you are an old man. Your Windows computer regularly runs a lot of stuff triggered on non-obvious events, which even after you google for the name will leave you with a "WTF?!". I have disabled literally dozens of services, hundreds of policies, and thousands of scheduled tasks on my desktop computer, with no visible difference. Visible being the key word.

(2)Yes, each service has a description and a MSDN page. But still you don't know what they are really doing. Some of them do several things, and non-obvious things, too. And most descriptions and help pages cause just as many "WTF?!" as they solve.

"windows server, no access possible"

Maybe I'm over-pessimizing here, but are you kidding me?

One of the most serious defects in every version of Windows during the last 10 years (the newer the worse!) is that you don't know what's running at what time(1), you don't know what each of the hundred services is doing exactly(2), you don't know who can access the machine, you don't know which services provide intentional or unintentional backdoors, and you don't know what data the machine regularly sends to whomever on its own behalf.

Admittedly, the "server" versions generally appear to be somewhat more sane than the desktop versions, but Windows most definitively is not something you can trust as "unhackable" or "not connecty", or "not chatty".


(1) Yes, you could know, in theory. But in practice, you have no darn clue because there is no way you can even dig through the ten thousand policies and tasks before you are an old man. Your Windows computer regularly runs a lot of stuff triggered on non-obvious events, which even after you google for the name will leave you with a "WTF?!". I have disabled literally dozens of services, hundreds of policies, and thousands of scheduled tasks on my desktop computer, with no visible difference. Visible being the key word.

(2)Yes, each service has a description and a MSDN page. But still you don't know what they are really doing. Some of them do several things, and non-obvious things, too. And most descriptions and help pages cause just as many "WTF?!" as they solve.

You have a very 90s view of Windows. And not knowing what you run is all the same un linux unless you compile yourself and review everything yourself, as i said it's a tradeoff here.

You don't need to dig through tens of thouthands of policies anymore you'd need to dig through every config file everywhere on linux, if a service is disabled it's disabled, how it is configured matters quite little if it can't run at all to begin with and Windows server core (and soon nano) runs with a very small set of services and programs to begin with and almost all of them can be disabled for what i do.

thouthands of policies anymore you'd need to dig through every config file everywhere on linux,

If you use server core you'd be OK, but the desktop versions of the server platform come bundled with all kinds of rammel that at best just affect performance and at worse widen the attack footprint.

Linux is very much like windows server core though, that as default you get nothing. No daemons and nothing with a configuration file to need to edit.

It's only when you add and enable features on either os that you need to concern yourself with changing its settings.

A good security philosophy is to only enable what you need and nothing more. You wouldn't install a full graphical environment with XOrg on your Linux server if you didn't need it, any more than you'd install IIS on windows on a server just designed to serve network shares.

Unfortunately up until server core editions of windows you had no choice in the matter as they all have Explorer and an interactive graphical interface and all its issues bundled in... Font rendering in ring 0, anyone? Microsoft do still push this mentality for a lot of windows usage, too. For example if you install small business server you get all the graphical crap, and in all honesty it isn't needed as everything can be administrated with management console on a remote pc...

thouthands of policies anymore you'd need to dig through every config file everywhere on linux,

If you use server core you'd be OK, but the desktop versions of the server platform come bundled with all kinds of rammel that at best just affect performance and at worse widen the attack footprint.

Linux is very much like windows server core though, that as default you get nothing. No daemons and nothing with a configuration file to need to edit.

It's only when you add and enable features on either os that you need to concern yourself with changing its settings.

A good security philosophy is to only enable what you need and nothing more. You wouldn't install a full graphical environment with XOrg on your Linux server if you didn't need it, any more than you'd install IIS on windows on a server just designed to serve network shares.

Unfortunately up until server core editions of windows you had no choice in the matter as they all have Explorer and an interactive graphical interface and all its issues bundled in... Font rendering in ring 0, anyone? Microsoft do still push this mentality for a lot of windows usage, too. For example if you install small business server you get all the graphical crap, and in all honesty it isn't needed as everything can be administrated with management console on a remote pc...

Of course server core is the only windows that makes sense in a security centric decision. And even then i can disable a lot (there really only a handfull of services "really" required to get Windows running a lot of what is enabled on server is still related to running in a group).

So what are you actually going to, you know, do with this 'unhackable' server that doesn't store anything or make any kind of backups?

I have a plate sitting here on the table beside me. Bet you can't hack that! Not really sure what use it might be for a web server, but its pretty damn unhackable...