and remove any affected code from your server, you add a rule for mod_security that you found on an Internet forum and hope that it is sufficient to detect and prevent traffic relating to the backdoor.
It is my hope that providing examples of proactive and reactive tactics will allow you to arm yourself with knowledge that can be used to help protect your Internet business.
What other proactive things can be done? 1. Keep your software up to date, especially your kernel.
2. Use a grsec kernel.
3. Learn a programming language. Perl is excellent for systems administration tasks.
4. Use RSS feeds for security sites such as
exploit-db.com,
inj3ct0r.com,
reddit.com/r/netsec,
seclists.org (Bugtraq, Full Disclosure, Daily Dave, Open Source Security),
packetstormsecurity.org, etc. Knowing the threats you are up against will help you prepare for dealing with them.
5. Learn how to create your own modsecurity rules. 6. Consider mounting /home nosuid (but not noexec).
7. Run sshd on a different port. Note that sshd should be run on privileged ports only. While this action alone does not increase server security, it can be helpful for avoiding automated brute force password based attacks, as well as automated exploits that scan large network blocks for port 22 and execute attacks indiscriminately (worms, for example).
Here are some ideas for reactive approaches: 1. Monitor world writeable locations such as /tmp for suspicious data as often as possible (e.g., every few seconds, or in real time as new files and directories are created). What can be defined as "suspicious"?
files or directories that start with a dot
files or directories that start with a space, or consist entirely of spaces
files with the following extensions: .c, .cpp, .pl, .tar, .gz, .tgz, .out, .py
filenames commonly associated with malicious scripts, such as r0nin, psybnc,
udp.pl, bindz, cmdtmp
files that contain one of the following on the first line: bin/*sh, bin/perl, bin/env, bin/python, bin/ruby, #include, use Socket, ELF, #
files or directories that consists of very short names (e.g., /tmp/1, or /tmp/zz) suid or sgid files executable files
directories named as session files, such as a directory at /tmp/sess_ef1337ea49087504010af9a64a2447db
This approach is inherently flawed since it is signature based. It is trivial to disguise malicious data in a manner that evades detection of each of the above. However, there are many unskilled, lazy, or inexperienced attackers on the Internet, and they are likely to be caught by signature based detection.
How many suspicious things can you find in the output below?
[root@host /tmp]# /bin/ls -al total 136 drwxr-xr-x 2 root root
drwxrwxrwt 5 root root 114688 May 3 23:54 . drwxr-xr-x 23 root root drwxr-xr-x 2 root root drwxr-xr-x 2 root root
4096 May 3 23:53 4096 May 2 21:51 ..
4096 May 3 23:54 .. 4096 May 3 23:53 ...
srwxrwxrwx 1 mysql mysql -rw-r--r-- 1 root root
0 Apr 30 04:52
mysql.sock 0 May 3 22:49 sess_
bbf6c7766c1bee31d086364f6f80f53c srwxrwxrwx 1 postgres postgres 0 May 3 23:49
.s.PGSQL.5432 -rw------- 1 postgres postgres 25 May 3 23:49
.s.PGSQL.5432.lock
061
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44 |
Page 45 |
Page 46 |
Page 47 |
Page 48 |
Page 49 |
Page 50 |
Page 51 |
Page 52 |
Page 53 |
Page 54 |
Page 55 |
Page 56 |
Page 57 |
Page 58 |
Page 59 |
Page 60 |
Page 61 |
Page 62 |
Page 63 |
Page 64 |
Page 65 |
Page 66 |
Page 67 |
Page 68