LinuxQuestions.org
Go Job Hunting at the LQ Job Marketplace
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Security
User Name
Password
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.

Notices

Reply
 
Search this Thread
Old 03-11-2013, 10:18 AM   #1
OtagoHarbour
Member
 
Registered: Oct 2011
Posts: 291

Rep: Reputation: 3
Testing for Backdoor


I have two systems: one running Ubuntu 11.4 and the other running Ubuntu 11.10.

I have been thinking of installing Tripwire but, having read about it, it seems that it may be closing the gate after the horse has bolted if I do not install it immediately after installing the OS since a hacker may have already installed a back door. As I understand it, Tripwire looks for changes in the system.

I would like to install Trip wire but would prefer no to have to erase the disk and reinstall the OS. Is there a good way to test for backdoors on the system?

Thanks,
Peter.
 
Old 03-11-2013, 10:31 AM   #2
Noway2
Senior Member
 
Registered: Jul 2007
Distribution: Ubuntu 10.10, Slackware 64-current
Posts: 2,124

Rep: Reputation: 776Reputation: 776Reputation: 776Reputation: 776Reputation: 776Reputation: 776Reputation: 776
Quote:
Is there a good way to test for backdoors on the system?
This gets into the realm of forensic analysis, which is something that we help out with here at LQ. The process is roughly based upon the dated CERT Intruder detection check list. The investigation involves looking at the system processes, network connections, and log files for anomalies and other signs of unauthorized access. Additionally, a search is made for hidden files, modified system binary files, unknown user accounts, cron entries, modified web stack items, and executable temporary files.

Using of a tool like tripwire is core part of the security as a process mentality in that it helps you by alerting you to file modifications. While it is best to install it immediately following a system installation for maximum effectiveness, this does not mean that installing it at a later point is without benefit. I would recommend performing some basic checks and audits of your system, such as verify that the system binaries have not been altered (e.g. use RPM verify) and make an examination of other critical areas like cron tabs, passwd, and shadow, verify that there are no unexpected processes, etc. If these things come out clean and you've had sane SSH practices and have kept the machine relatively up to date, etc, then I would go ahead and install tripwire as it should still alert you to unexpected activity.
 
2 members found this post helpful.
Old 03-11-2013, 06:56 PM   #3
OtagoHarbour
Member
 
Registered: Oct 2011
Posts: 291

Original Poster
Rep: Reputation: 3
Quote:
Originally Posted by Noway2 View Post
This gets into the realm of forensic analysis, which is something that we help out with here at LQ. The process is roughly based upon the dated CERT Intruder detection check list. The investigation involves looking at the system processes, network connections, and log files for anomalies and other signs of unauthorized access. Additionally, a search is made for hidden files, modified system binary files, unknown user accounts, cron entries, modified web stack items, and executable temporary files.

Using of a tool like tripwire is core part of the security as a process mentality in that it helps you by alerting you to file modifications. While it is best to install it immediately following a system installation for maximum effectiveness, this does not mean that installing it at a later point is without benefit. I would recommend performing some basic checks and audits of your system, such as verify that the system binaries have not been altered (e.g. use RPM verify) and make an examination of other critical areas like cron tabs, passwd, and shadow, verify that there are no unexpected processes, etc. If these things come out clean and you've had sane SSH practices and have kept the machine relatively up to date, etc, then I would go ahead and install tripwire as it should still alert you to unexpected activity.
Thank you so much for your reply. I did a search for the syslog files and found.
Code:
-rw-r----- 1 syslog adm 104924 2013-03-11 14:17 /var/log/syslog
-rw------- 1 syslog adm 203725 2011-10-30 10:33 /var/log/installer/syslog
/var/log/syslog has several entries just today so I am not sure what to look for. So I entered

Code:
cat /var/log/syslog | grep "DST="
and the destination always seems to be 224.0.0.1. The SRC always seems to be 192.168.1.1.

I then ran

Code:
sudo rpm -Va
and it did not return anything. When I do

Code:
cat /etc/passwd | grep "/home" |cut -d: -f1
I get

Code:
syslog
usbmux
saned
peter
squid
squid was an account I set up to run squid. I ran chkrootkit and got the following.

Code:
The following suspicious files and directories were found:  
/usr/lib/jvm/.java-1.6.0-openjdk.jinfo 
/usr/lib/pymodules/python2.7/.path 
/usr/lib/libreoffice/basis3.4/program/.services.rdb
These look like regular programs that I use. For cron tabs, I did and got

Code:
peter@peter-Inspiron-620:/var/www$ sudo ls -la /var/spool/cron/crontabs
total 8
drwx-wx--T 2 root crontab 4096 2011-01-05 05:22 .
drwxr-xr-x 5 root root    4096 2011-04-25 18:54 ..
Not sure why it said "total 8" but didn't show any files.

Code:
rpm -V passwd
returned

Code:
package passwd is not installed
Likewise

Code:
rpm -V shadow
returned

Code:
package shadow is not installed
Thanks,
Peter.
 
Old 03-12-2013, 11:02 AM   #4
Noway2
Senior Member
 
Registered: Jul 2007
Distribution: Ubuntu 10.10, Slackware 64-current
Posts: 2,124

Rep: Reputation: 776Reputation: 776Reputation: 776Reputation: 776Reputation: 776Reputation: 776Reputation: 776
Examining your syslog is a good start. You should get to know your Linux log files and what they each represent. As with most things Linux, choice rules the day, but syslog is a pretty common general one. Often times, each system application, e.g. Apache web server, name server, etc will have a log file associated with it. In addition there are some standard logs, such as syslog and other ones like cron and wtmp that are going to be pretty standard. There is also some variation amongst what is standard for a particular distribution.

Quote:
the destination always seems to be 224.0.0.1. The SRC always seems to be 192.168.1.1.
Off hand, this looks like an iptables entry, most likely saying that traffic has been blocked. The 192.168 address would be the local LAN address of your machine and 224.0.01 is all-systems.mcast.net, which is part of verisign. The whois and nslookup commands are quite valuable here.

RPM -vA not returning anything can be a good thing. If your using a laptop / desktop system on which you did not modify any of the configuration files in /etc, this could be very normal. Here is a short example from one of my machines, where you can see that I have modified some files. The RPM verify shows what has changed compared to the package maintained version. Here is a link to a decent resource that describes what the codes mean. Of course, it goes without saying that many of these types of commands will need to be run with root privilege.

Code:
S.5....T.  c /etc/rc.d/init.d/postgrey
S.5....T.  c /etc/sysctl.conf
....L....  c /etc/pam.d/fingerprint-auth
.M.......    /root
.....U...    /var/spool/mail
S.5....T.  c /etc/freshclam.conf
missing   c /var/clamav/daily.cvd
Here is my output from the ls for the crontabs, which you can see is similar to yours, except I have two users who actually have crontab entries
Code:
total 16
drwxr-x---  2 root root    4096 Sep 24 15:30 ./
drwxr-x--x 21 root root    4096 Mar  6 16:16 ../
-rw-------  1 root mtflyer   78 May 31  2012 myuser
-rw-------  1 root root    1441 Sep 24 15:29 root
Your other entries with RPM Verify, which utilizes the check package syntax is indicating that these packages are not installed, however, this isn't quite what we're after. The files shadow and passwd are contained in your /etc directory, which is where almost all of the system configuration files go. The passwd file contains a list of the users on the system. Shadow is similar, but it also contains the hashed passwords, which are left out of passwd.

As an example of what to expect:
Code:
root:x:0:0::/root:/bin/bash
bin:x:1:1:bin:/bin:/bin/false
daemon:x:2:2:daemon:/sbin:/bin/false
adm:x:3:4:adm:/var/log:/bin/false
lp:x:4:7:lp:/var/spool/lpd:/bin/false
sync:x:5:0:sync:/sbin:/bin/sync
shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown
halt:x:7:0:halt:/sbin:/sbin/halt
mail:x:8:12:mail:/:/bin/false
news:x:9:13:news:/usr/lib/news:/bin/false
The fields are delimited by the : symbol. Looking at the first entry, root is the user name, X is a placeholder for the passwd, it is user and group 0, there is no comment, the home directory is /root, and the shell is bash. The Linux manual system is well organized and will show you information regarding this structure. To get at it, you need to understand one of the little tricks, that there are several categories to the man pages and how to get at them. In this case, if you enter the command 'man passwd' it will give you the pages for the passwd command, which is not what you are after. If you go to the bottom it should say see also passwd(5), which means that there is also a section in group 5 File Formats and Conventions (list is obtainable via 'man man'). If you then give the command man 5 passwd, you will get the help file regarding the passwd file.

It looks like you off to a good start in the understanding and investigation of your system. One of the things I should have asked, is what is the nature of the system? Is it a desktop/laptop or a server? If it is the former, and especially if you've been behind a firewall router, stayed away from nasty places, and obtained your software via the distribution repositories, your chances of having undesirable "friends" is pretty small, but it is still good to understand your system.

One recommendation I would have for you (borrowing from a post by unSpawn) would be to run the following:
Code:
( \ps axfwwwe 2>&1; lsof -Pwln 2>&1; netstat -antTupe 2>&1; lastlog 2>&1; last 2>&1; who -wa 2>&1; find /tmp /var/tmp /usr/tmp /var/spool/cron -printf "%T@ %A@ %C@ %u %g %m %y \"%p\"\n" 2>&1 ) > /tmp/output.log
This will create a big text file in "/tmp/output.log", which will show you the entire process tree, network connections, and a bunch of other relevant information from your system. It probably won't all make sense at first, but do take a look at the output, read the man pages on the commands to see what the options are doing for you, and ask questions if you don't understand something.
 
2 members found this post helpful.
Old 03-20-2013, 08:33 PM   #5
OtagoHarbour
Member
 
Registered: Oct 2011
Posts: 291

Original Poster
Rep: Reputation: 3
Thanks again and sorry for my slow reply.

Quote:
Originally Posted by Noway2 View Post
Off hand, this looks like an iptables entry, most likely saying that traffic has been blocked. The 192.168 address would be the local LAN address of your machine and 224.0.01 is all-systems.mcast.net, which is part of verisign. The whois and nslookup commands are quite valuable here.
The associated port always seems to be 8612. I looked that up and it seems that it is usually for a Canon printer. However I have no printers attached to the server. Maybe I could just block that port. The source ports are all high numbers (>50,000) but always seem to be different.

I looked at /etc/shadow. Every entry that does not correspond to an account I set up has * or ! in the password field. I read that this means that their user login is disabled. Is this correct?

My system is two desktops connected as a DMZ. Both desktops run Ubuntu and use iptables as a firewall with snort running as well.

Thank you so much for your help,
Peter.
 
Old 03-21-2013, 03:45 PM   #6
Noway2
Senior Member
 
Registered: Jul 2007
Distribution: Ubuntu 10.10, Slackware 64-current
Posts: 2,124

Rep: Reputation: 776Reputation: 776Reputation: 776Reputation: 776Reputation: 776Reputation: 776Reputation: 776
Quote:
Originally Posted by OtagoHarbour View Post
Thanks again and sorry for my slow reply.
No worries. I'm happy to help.

Quote:
I looked at /etc/shadow. Every entry that does not correspond to an account I set up has * or ! in the password field. I read that this means that their user login is disabled. Is this correct?
Correct. See man 5 shadow
Code:
A password field which starts with a exclamation mark means that the password is locked. The remaining characters on the line represent the password field before the password was locked.
If the password field contains some string that is not a valid result of crypt(3), for instance ! or *, the user will not be able to use a unix password to log in (but the user may log in the system by other means).
Quote:
The associated port always seems to be 8612. I looked that up and it seems that it is usually for a Canon printer. However I have no printers attached to the server. Maybe I could just block that port. The source ports are all high numbers (>50,000) but always seem to be different.
This entry is a bit curious. Is this an inbound or outbound rule that is blocking and is the source your machine or some other machine probing you. I should have caught this the first time when you said destination 224.0.0.1 with a 192.168 source. If this is ingress traffic, having nothing listen on the port is safe and having a firewall rule blocking (which it looks like you do) is good. If it is outbound traffic, it can be more difficult to capture but ultimately you need to get it down to a process (PID) and determine if it is legitimate or not.

Quote:
My system is two desktops connected as a DMZ. Both desktops run Ubuntu and use iptables as a firewall with snort running as well.
Sounds like a good setup. The DMZ will still expose the machines to all internet traffic that makes it through the front firewall but with NAT. The address ranges in your DMZ could also be what is confusing me about the iptables entries that I mentioned above.
 
1 members found this post helpful.
Old 03-21-2013, 10:13 PM   #7
OtagoHarbour
Member
 
Registered: Oct 2011
Posts: 291

Original Poster
Rep: Reputation: 3
Quote:
Code:
The associated port always seems to be 8612. I looked that up and it seems that it is usually for a Canon printer. However I have no printers attached to the server. Maybe I could just block that port. The source ports are all high numbers (>50,000) but always seem to be different.
This entry is a bit curious. Is this an inbound or outbound rule that is blocking and is the source your machine or some other machine probing you. I should have caught this the first time when you said destination 224.0.0.1 with a 192.168 source. If this is ingress traffic, having nothing listen on the port is safe and having a firewall rule blocking (which it looks like you do) is good. If it is outbound traffic, it can be more difficult to capture but ultimately you need to get it down to a process (PID) and determine if it is legitimate or not.
In /var/log/syslog, it is given as [UFW BLOCK]. I maily used iptables for filtering but do have an input and output block (the only DENY) in ufw and they are both intended to block a specific IP addres that appeared that it may be trying SQL injection. It may not have been but it ran afoul of requirements for entries into forms on my web site and I had set the system up to alert me when that happened.

Quote:
Sounds like a good setup. The DMZ will still expose the machines to all internet traffic that makes it through the front firewall but with NAT. The address ranges in your DMZ could also be what is confusing me about the iptables entries that I mentioned above.
What I have described so far applies to the application/client server. When I looked on the web/proxy server, there were only three entries but they were all from an external IP address in Chicago. I have just added an iptables rule to drop inputs and outputs from and to that ip address.

Thanks again,
Peter.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
backdoor as CRON jim656 Linux - Security 7 02-16-2006 06:42 AM
Yet another backdoor for IE.... r_jensen11 General 11 06-29-2004 11:31 AM
/home/backdoor glyn_walters Linux - Security 6 05-15-2003 11:29 AM
backdoor im1crazyassmofo Linux - General 3 01-16-2003 06:54 PM
SSH 2 as a backdoor? help me fenris@bu Linux - Security 3 05-24-2001 12:12 PM


All times are GMT -5. The time now is 10:19 AM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration