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.

Noway2

03-11-2013 11:31 AM

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.

OtagoHarbour

03-11-2013 07:56 PM

Quote:

Originally Posted by Noway2
(Post 4909207)

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.

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.

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.

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:

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.

OtagoHarbour

03-20-2013 09:33 PM

Thanks again and sorry for my slow reply.

Quote:

Originally Posted by Noway2
(Post 4910057)

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.

Noway2

03-21-2013 04:45 PM

Quote:

Originally Posted by OtagoHarbour
(Post 4915607)

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?

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.

OtagoHarbour

03-21-2013 11:13 PM

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.