Hacker News new | past | comments | ask | show | jobs | submit login

Just so I understand fully, this doesn't block attempts, just logs them?



Correct. It will log time, process name/pid, and what's going to be executed.


Why would you prefer this over the LD_PRELOAD workaround provided by redhat?


The LD_PRELOAD workaround is meant to "fix" the shellshock bug, sysdig doesn't do that, it just passively monitors every injection attempt up to the point where the injected function is actually read by a newly spawn bash.

With the LD_PRELOAD trick you can definitely secure your system, but you won't be able to see if there's a new service that is being used as an attack vector (for your own curiosity). With sysdig, you can, and if you capture a trace file you can also follow the exact process chain that caused the propagation of the environment variable.


Why not actually also stop them?


That can get tricky as a general case, but would probably work OK for most people in this specific case. But, then again, hopefully you've patched bash already anyway, so blocking hosts that are scanning for a vulnerability that you've already fixed probably won't accomplish much.

Generally speaking, if you use something like iptables to block abusive hosts, you dive head-first into a very deep rabbit hole. Usually sysadmins don't want hosts blocked forever or iptables with 30k+ lines in them, so now you have to also add some kind of automated ban-clearing feature. Then you want to make sure you don't ban certain networks, so now you have to have some kind of whitelist feature. Then sysadmins will want to be able to tune which networks are trusted and which aren't, so now you have to add some configuration options for it. And so on.

I've written some software for my servers that does this for several different annoyances, and I spend almost as much time tuning the software as I spent dealing with the annoyances in the first place.

If sysadmins really want to auto-ban abusive hosts, you're probably better off letting them do it with something like Fail2Ban, and then all that muckety-muck becomes their problem, and not yours.


I wouldn't use a program B to circumvent a bug of another program A if not in a exceptional case in which patch of program A cannot be created.

This is exactly the case. If bash has a bug. that must be fixed. And it has been done already. Just update bash in major distributions and the bug is gone.

But still you want to have a tool like sysdig to detect if your system has already been compromised previously and it is out of sysadmin control.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: