How do you whitelist files for chkrootkit
 

I ran chkrootkit and got
I still get it after editing /etc/chkrootkit.conf and adding

Thx,
OH.

As far as I'm aware Chkrootkit doesn't come with a "/etc/chkrootkit.conf" so this must be functionality either you or your distribution has added. Apart from that Chkrootkit hasn't been updated in ages.

...and it doesn't come with a 'man page' either. What it does have is a 'README' file in, eg, /usr/share/doc/packages/chkrootkit, and that has, for example

as the last recorded change (other distros will probably differ slightly in their latest version, but, probably around that kind of date is the last time that there was much progress).

Just as an example, something like 'rkthunter' has, on the same distro, a last update date of 28 Jan 2013, so there is quite a difference.

I don't get any alerts with rkhunter. Maybe white listing isn't such a good idea anyway. If a particular file has a reputation for false positives, an attacker may replace it with malware knowing that file name is likely white listed.

Thanks,
OH.

Maybe it's time to step back and first review the security posture of your machine as a whole?
Like in what services do you run?
What risks do you (think you) run?
How do you protect the machine, users and data?

Something for a new thread?..

Hi unSpawn,

I run a web site using a Linux-based DMZ where the web server runs Ubuntu 11.4 and the app. server runs Debian 7.0. I aim to limit my ports to 80 and 443. Both servers are protected by maldet, iptables, rkhunter and chkrootkit. On the app server I also have Snort, WireShark and Samhain. The sort of things I wish to prevent are spyware, root kits, DOS attacks and hackers reverse engineering my executables.

Thanks,
OH.

Sounds OK though it's not as much as what OS you run (as long as its up to date and properly hardened of course) but more what runs on top of it like a CMS, photo gallery, shopping cart, etc, etc including themes, plugins and add-ons that'll be targeted first...


Wireshark should not be on a server simply because a server should not run a GUI. (Though rawshark, tshark or dupcap could.) With respect to auditing and post-op verification LMD and Samhain are good choices (I said before Chkrootkit was updated last in 2009) but I'd put Snort on the router providing the DMZ if possible (better placement) and I'd minimally add fail2ban and Logwatch for early warnings. Again all of this asserts both machines, their user accounts and services are properly hardened.


While Linux as a platform is certainly capable of running unwanted processes there essentially is no "spyware for Linux" (there is malware though) and the threat of rootkits has been replaced by anything that can run in the web stack. Defending against DoS and DDoS attacks is not as much a case of end point protection as it is a case of good filtering from your upstream provider. Finally "reverse engineering executables" is kind of ambiguous as it can mean both attacking Intellectual Property or substituting trojaned versions of applications. Apart from (D)DoS all require gaining a foothold be it through a SSH account that's "protected" by only a weak password, a remote site editor running a tainted OS (cred grabbing) or say a vulnerable piece of web site software. Those require network connections which can be logged, reported and alerted upon (Logwatch, fail2ban). Often files need to be dropped on the file system and that too is an event that can be watched for (audit service, Samhain using inotify). Finally accessing a resource and executing a process can be watched for too (audit service, TOMOYO, GRSecurity Trusted Path Execution).

Long story short: a gill of preventive measures is worth more than a pint of cure.

Thank you for the great suggestions. The web server is an old computer running Ubuntu 11.4 which is not longer supported. The hardware cannot handle newer versions of Ubuntu. I'm not sure if it is due to lightdm replacing gdm in newer versions. I could try installing Debian 7.0 instead but may have the same problem since Debian is also adopting lightdm as I understand it. I don't use any plug ins on my web site, except for InAFlash (for file uploads) which no longer seems to be supported and uses FlashPlayer which seems to be on the way out. I am thinking of replecing it with standard PHP calls. Everything else is standard PHP, HTML, JavaScript, HTML and CSS.

I didn't realize that was a problem. I mainly use WireShark on the app server to monitor packets. I inspect the packets it captures, block ip addresses I don't like with iptables and set a filter on the ip addresses I consider harmless so they are ignored. What would be the best option for that?

I had some issues with that that I discussed here. I haven't managed to revolve that yet.


I installed logwatch from the tar ball and edited the .conf file so that it emails me the results with low details. So far, it has not emailed me anything although it appears to be running a a daemon.

I also set up fail2ban from the tar ball. It runs with some error messages.

So it looks like it is running as a daemon but could not start the server. I did a search for fail2ban.sock, before trying to run the program and it does not exist anywhere on my system.

How do I ensure that is the case?

Do you mean add-ons on the web site that I host?

Would that be my ISP?

I was mainly thinking of the former but the latter could also be a concern.

I have ssh between the two servers but I have not consciously set it up for the outside world.

Thank you so much for your very helpful information,
OH

A web server shouldn't run a Desktop Environment in the first place. If you want to stay with Ubuntu please check out the LTS release and do not install Xorg, Desktop Environment or any graphical tools that could draw in Xorg / DE as a depencency.


Simply put any software exposed to world that is no longer maintained, supported is a potential risk.


Automate it ;-p


First install Ubuntu LTS or any other distribution of choice. If you can't get it to work afterwards let me know.


As far as I know Logwatch usually runs via a daily cron job.


What you're seeing is the 'grep' process itself and that's one of the reasons why people shouldn't use grep (see those %{deities}-awful 'doSomething|grep something|grep -v grep' constructs) in the first place but use 'pgrep' instead.


Try removing the /var/run/fail2ban/fail2ban.sock file.


First of all if you've installed these servers you should know (I tend to keep an admin log) if you hardened them. If you can't remember then see the Ubuntu Wiki, the "Securing Debian", OWASP and Cisecurity.org web sites and run GNU/Tiger for an initial audit.


Anything ranging from outdated versions of net-facing daemons to interpreters to CMSes and web logs to add-ons and plugins, yes.


It would except that you should first check if their AUP permits you to run a server. No use in talking to them otherwise.


Replacing system binaries with trojaned versions still occurs but for that to happen the perp needs a way in. That's why it's good to invest time and effort preventing it.


No matter what you do just keep the SSH best practices in mind, OK?

Sorry about my slow reply. I have been working on the issues that you mentioned. There is one question I have about something I am working on just now.

What I have been doing is to do a Google search for the ip address that is recorded by WireShark. If it is associated with an innocuous site, I add it to the capture filter so that WireShark will ignore it. If I see a discussion where someone is saying that the ip address has been associated with an attempt to hack their system I block it with iptables. I could try to formulate an algorithm to automate this but did not want to reinvent the wheel. Can you suggest a good starting point?

Thanks,
OH.

First of all you'll realize this will be an atrociously slow process, that the intent of posts can only be analyzed by a human user understanding the context in which comments are made and that this process should be made unnecessary by preventive measures and early warnings, right? IIRC there's a RBL-like extension for iptables called "packetbl", might look into that. (EDIT: as in method because of the nfnetlink_queue / libnetfilter_queue stuff it uses.)

sorry delete this message

I did find this paper which uses libnetfilter_queue for queuing selected packets to user space. Overall, they use anomaly detection to assign a score to packets based upon vector-based outlier detection. Would that be the way to go? Perhaps this could be used to reduce the number of URLs that need to be manually inspected?

Thanks,
OH.

In short I suggest you deploy mod_security and Snort with the Emerging Threats rule set. If you do that in addition to what I wrote about before you already have fail2ban pick up issues from the logs (make it use ipset to block access) and Logwatch to alert you about remaining issues you should deal with manually and on a day to day basis. Run that for a week and evaluate the next week if this covers your needs. If it doesn't let us know.

I added the Emerging Threats rule set to Snort, on the app server, today and I have already started getting the following alert.

Thanks,
OH.