I wrote this little script as way to stop endless sendmail calls to unknown users on my mail server trying to spam it. I then wrote a SSH brute hacking detector into it as well. Works with iptables and developed on slackware but should run on any linux flavor with very minor tweeking. If you do please let me know if you get it running on a another distro so I can added to the software project.

http://code.google.com/p/cheescloth/

What does this provide that I can't get from other software such as Fail2Ban? Is this something you designed to run on a personal computer or was your software intended for high availability production enterprise class servers? One feature I think might be unique to your software is writing sendmail rules when SSH gets knocked. I'm not sure if Fail2Ban can do that but it might be scriptable.

I actually wrote it up originally wrote it in 2008 and put it up in 2009. I have never heard of fail2ban. I will check that out. I have it running on a few 20 user account mail servers as well as one or two mail servers that have over 200 users on them. That is a cool idea about the sendmail rules.

Sag47: I checked out fail2ban but it does a lot more stuff than my program. My program strickly monitors for ssh and user mining/spam attempts. The other difference I saw between the two programs is that mine seems to be easier to install setup and run. Two entries into cron and your set all though I suggest to go through the one file script that runs ccloth and make sure there is no need for little tweeks.

As far as the idea of adding rules to sendmail. I don't think that would fit in cheescloth because once it catches you everything is cut from that IP until it is rotated out.

- You drop your rules in the filter table INPUT chain. Blocked addresses don't need to use up conntrack resources so they should go in the raw table PREROUTING chain.
- 'cat /var/log/w_messages |sed -n '/invalid user/{p;}'' is an example of a pipeline that probably could be solved differently (more efficiently?).
- You commonly delete files and create reporting in /usr/local/chees/. According to the FSSTND, FHS and all that we hold for true this should be down in /var.
* But most importantly: just because your README says "Every minute that cheescloth runs it scans the maillog file and the message file in /var/log. After the scan the data is both of these files is copied into maillog.1 and messages.1 . Syslogd is then reset. If you have other monitoring software that relys on either of these two file you need to point them to maillog.1 and messages.1" doesn't mean it's not completely wrong. If *you* want log lines to work with (if you can't come up with checkpointing) then *you* copy and use maillog.1 and messages.1 and not the other way around! Until you have fixed this issue I suggest people avoid cheescloth.

Moved: This thread is more suitable in the Programming forum and has been moved accordingly to help your application get the reworking it requires.

Thanks for moving the thread where it needs to be unspawn.

1) Concerning the Block addresses using up the conntrack resources do you think it would make that big of deal? What do you feel would be the correct syntax to use to do it with the raw tables prerouting chain.

2) Concerning the invalid user pipeline I will look at this as well. The file I am greping through is so small I did not think it was that big of deal. That will change though with #4

3) Concerning all the work being done in /usr/local/chees . When I wrote the script for the first time I was copying and pasting console commands in the script that gave the end result I wanted. I agree this should be moved to /var/run. Do you suggest that I just check to see if the directories I want to store data in are there before I run the script and create them if they arent?

4) I am was not happy about the handling of the log files either and figured it would be an issue. Originally just written for myself but I need to correct this. I like your idea about checkpoints in those files and will make this change very shortly.


I appreciate you taking the time to write these suggestions out.

The ideas unSpawn shot past you may seem like small issues for *your* setup. However, not everyone runs a small-midrange setup. Where I currently work we run roughly 1000 servers and over half of them are RedHat Linux. For a very large installation, cheesecloth wouldn't be suitable for the reasons mentioned by unSpawn. Think thousands or tens of thousands of users daily. We also have centralized logging though this may not be too affected by your renaming the logs it is generally bad practice to do so.

This is why I mentioned fail2ban. It may be a bit more complicated but it's battle tested in a wide variety of environments. That's not to say that your program is no good it's just something to strive for (being enterprise ready).

It's the same as you use with the INPUT chain except iptables defaults to using the filter table so the only thing you have to do is change PREROUTING for INPUT and explicitly add "-t raw".


Well it's not about the validity of your approach but if it could be done differently or more efficiently. Output of cat|sed, cat|grep and other such pipes could be gotten with say awk -F ' ' '/search term/ {print $fieldnumber}' /path/to/file if you're looking for fixed field values. That's using one tool only but that doesn't necessarily mean it's quicker. Gotta test different approaches. In some cases the placement of a tools switches or the way you build a regex may matter wrt speed.


If you want to cache data persistently then you could use say /var/cache/cheesecloth, data that doesn't need to survive say a reboot could go in /var/run/cheesecloth and logs and reporting should be in /var/log/cheesecloth.


Not that it would be easy to do. However thanks to TIS / Psionic / Ci$co you're free to use logtail as a dependency and avoid having to be creative ;-p

Thanks again for your advice. I am testing the new version now.

I changed #2 to just run sed instead of cat the file through the pipe.
I put all the tmp files in /var/run/cheescloth and the reports in /var/log/cheescloth. I didnt not change any code for these directories. I only put symbolic links in where the directories use to be in /usr/local/chees. That isn't a problem is it?
The big change is that I no longer mess with the message or the maillog file in the sense of renaming and restarting syslogd. I generate a 25 chr random string now and echo that into those 2 files. cat /dev/urandom| tr -dc '0-9a-zA-Z'|head -c 25 > info/chkpoint . When I go to look the next time at these files I only look at the data from this point down and then inject a new chk point. I gave you kutos in the docs for the idea.

Did you see anything else that might need to be changed or improved before I put this thing out again?

Thanks again