4

Trying to figure out exactly what services should be restarted after patching openssl against Heartbleed. At least one post mentions restarting:

sshd, apache, nginx, postfix, dovecot, courier, pure-ftpd, bind, mysql

  • Is there a command that can be run to see what running services are dependent on openssl?
  • Is there a command to run against apache/nginx to see if the patch is active so the service doesn't need to be restarted?
  • Should we just schedule downtime and reboot every server entirely?

EDIT: This post suggests using: lsof -n | grep ssl | grep DEL to display processes still using the old version of OpenSSL marked for deletion

|improve this question
  • Have you tried it - it certainly showed plenty of binaries using the old version for me on CentOS earlier. – user9517 supports GoFundMonica Apr 8 '14 at 17:46
  • 1
    Re: the lsof trick, it doesn't matter if the version number of the library changed: When the .so file is replaced the old inode becomes unlinked (DELeted, in the lsof list). The file is not rewritten in place by any package manager or install program that I'm aware of. – voretaq7 Apr 8 '14 at 17:48
  • @xref It is possible that there's an upgrade process I'm not aware of that rewrites the file in place (in which case you have a valid concern -- if you're worried about that just leave off the |grep DEL bit and work from the full list) – voretaq7 Apr 8 '14 at 17:51
8

As a general rule when mitigating a major vulnerability in a library which is used by many programs: rebooting your server is the easiest way to ensure you've restarted every affected program, and that nothing is using the old (vulnerable) code.

You should not fear rebooting your systems (you should be doing it pretty regularly when you install patches anyway!) - regularly rebooting your servers means you can be confident they will come back up without a problem, and if you design your environment for proper fault tolerance a reboot does not mean an outage. (For that matter even if your environment ISN'T fault-tolerant, we're talking maybe 10 minutes - a tiny outage considering the scale of the security problem we're talking about with heartbleed...)

If for some reason you can't reboot you can use lsof to determine what programs are running which are using the OpenSSL library: sudo lsof -n | grep ssl

To find ones using the OLD (deleted) library, you can do sudo lsof -n | grep ssl | grep DEL.

Each affected program will need to be restarted using whatever procedure is appropriate for that program.

|improve this answer
  • As an additional note, any program which is statically linked against OpenSSL will need to be recompiled and restarted to address the vulnerability... – voretaq7 Apr 9 '14 at 19:00

Not the answer you're looking for? Browse other questions tagged or ask your own question.