If a small number of physical servers are used to run an OS and reverse proxy purely in RAM and have no storage, and they are rebooted/re-initiated in relay every X minutes - so that changes to the system while in RAM are wiped - does this provide a real security benefit over more standard always...
a) And where does the data come from, when it is loaded into RAM? Right. b) If it got compromised one time, why not another time? c) Cleaning the system a few minutes after an attacker got in is too late to say "it's secure", the damage is already done.
@deviantfan a) a physically read only usb stick b) they can of course get back in, but it hampers the effort because they only have a small time window to do anything (is my suggestion) c) I'm asking of the proposal is more secure than standard always on servers... assuming both have been compromised
@dandavis if the system had been compromised then any changes made would be reverted on every reboot.
@dandavis I'm suggesting yes, let's say they get root access on the proxy. Then they work out the only available access is to the Web server on port 80 on a different OS. I assume at this point one would install and run exploit toolkits. That's a lot of work to get through in a short window.... compared to an always on server. I'm suggesting it makes things more difficult should access be gained.
@Jonno I agree with dandavis here. That's a lot of work to get through in a short window. No, that's the problem. During some reboot cycles, the attacker will first gather information manually, prepare the actual exploit etc., and then everything runs automatically within few seconds (after each reboot).
it could also make an attack easier; if all the bad guy can do is write files (not alter ram), then your next scheduled reboot runs his code for him. Whereas, if a node.js process is running, it's very difficult to alter the in-ram code without potentially noticeable side-effects.
@deviantfan would you agree, at least, the search for an exploit to go from the proxy to the Web server would be delayed but not prevented compared to a standard server were the search for the next exploit would proceed uninterrupted?
@Jonno Does it matter if the attacker needs to make a cronjob or not? That's trivial. (btw. there are enough people who don't "search" for exploits, instead they write custom ones for each target)
@dandavis based on the bios suggestion, in your disaster recovery approach after a machine is compromised, do you renew the bios and flash the network card?
(The Bios comment was mine), my answer: In a situation where I need to worry about BIOS malware, a compromised device is compromised and won't be used again. Including hardware.
@dandavis seriously... I never thought of that. I'm not suggesting one invites people in, what I'm asking about is reducing risk in the event a breach occurs.
... to repeat my first comment here: the damage is already done. If the attacker has something in his brain, it's to late to reduce any risk. Because as soon as you know that you're attacked, he's done with everything he wanted to do.
several of us have opined, repeatedly in fact, but you seem unperceptive to other's opinions, so why bother even soliciting them? If your mind is made up it's made up, but don't expect everyone to agree. The rest of us chalk it up to "obscurity", don't RYO, etc, it's just not a practice that has obvious benefits to us. You know more about your setup, so don't blame us for not jumping aboard something you know in your heart is safe.
@deviantfan nope, I got a silly lesson about prevention is better than mitigation, not an answer if the proposed would be more secure than equivalent always on servers.
@dandavis I blame nobody for disagreement rather the useless lesson on prevention is better than a cure.
Discussion on question by Jonno: Does…
Discussion on question by Jonno: Does…