Keep in mind I've played both sides of this game. People who know how attacks work in the wild can usually spot things that might not raise the ire of average sysadmins.
No, I'm saying an attacker would also have to find and destroy the immutable central logging store that all the stuff goes to. They'd also have to reach through the sands of time to get the stuff that's already been blowing up my phone. Get over yourself.
It's worth mentioning that no one is perfectly secure, either. A sufficiently bored, persistent and motivated attacker WILL find some kind of way in. I'll give you that. I've seen it play out enough times. But with centralized logging, transaction shipping for hot-site replication, and sufficient effort placed on separation of duties, an organization can minimize the impact a successful attacker can have, and can ensure that all audit trails remain intact in some way or another.
I am over myself. Note that everything I replied with was a question, and that I haven't had to proceed anything I have said with something like 'Keep in mind I've played both sides of this game'.
Anyway, to go on (keep in mind that I am genuinely interested in what you have to say). Isn't it true though that your IDS is only as good as your signature db? So if there was sshd or ftpd 0day that wasn't generic (generic shellcode etc.) that in theory you could spawn a shell without it ever being logged?
It's true. You could. But that shell and the activities therein would get logged in places that would make it hard for most attackers to cover their tracks. Mandatory Access Control and privilege separated daemons should also severely limit what that shell can do.
I'm not trying to have a pissing contest, but the reason we have defense in depth isn't to get 100% secure. You and I both know it's impossible. It's also there to preserve evidence if the unthinkable occurs. I do genuinely appreciate the forward thinking, so I'm sorry if I was a tad harsh in my reply above. Your responses (and your HN bio) came off a tad skiddie-ish at first blush. Being in infosec, where "Hacker" has a different meaning and stigma than "Hacker" in HN was originally meant to convey, I'm actually glad there are threads where Infosec "hacking" discussions can occur without getting completely buried by haters.
It's ok and thanks, I know I can also come across as terse/dickish sometimes. My profile is intentionally vague just because I prefer being anonymous (this is my 5th or 6th profile on here).
I worked in infosec (on all 3 sides, if you know what I mean) from the mid to late 90s, and then became disillusioned with the entire industry and left for greener pastures. I still attempt to keep on top of things (and have done the odd contract job here and there) but I am not all that up with everything going on.
Wrt the topic, what you are saying is that even with my /bin/sh running in the context of whoever sshd or ftpd are running as, by the time I figure out a local escalation, by then the activity on that shell has already been sent to another machine and onto your phone etc?
That was, of course, hyperbole (about blowing up my phone) however on certain very sensitive systems I do have a kernel module that provides a wrapper to execve() and that goes directly to a remote logging server and gets replicated. Yes, it's fucking noisy, but storage is cheap and databases are searchable.
As you well know, a careful individual can evade it if they know it's there, but the initial prodding would get logged.
Keep in mind I've played both sides of this game. People who know how attacks work in the wild can usually spot things that might not raise the ire of average sysadmins.