Logwatch and Spamassassin

2007/06/27 09:32:00
Print Friendly

Yesterday I realized that I hadn’t been getting any emails from my web/mail server. It was quite odd.

Looking in my SPAM folder I found all of the system emails that had been tagged and sent there. Every once in a while some legitimate (“HAM”) gets marked as SPAM and put in there.

I wasn’t expecting Logwatch emails to be easily marked as SPAM.

So, I checked out why it was listing them as such, and it led me to this line:

X-Spam-Status: Yes, score=6.4 required=5.0tests=ALL_TRUSTED,URIBL_BLACK,URIBL_JP_SURBL,URIBL_OB_SURBL,WHOIS_DMNBYPROXY,WHOIS_PRIVACYPOST autolearn=no version=3.2.1

As the Logwatch file reports on SPAM and associated information, I can see why it might have tripped the URI Black Lists (URIBL) and maybe the WHOIS rules, but it still didn’t make sense to me.

Usually if something is marked ALL_TRUSTED, no further checking is done, but I realize that in CentOS-5, this no longer appears to be the case. You are expected to set it up.

So, I edited /usr/share/spamassassin/60_shortcircuit.cf and uncommented the following line:

# if you have taken the time to correctly specify your "trusted_networks",# this is another good way to save CPUshortcircuit ALL_TRUSTED on

I think this should work.

Further Security Measures: mod_security

2007/06/25 22:55:00
Print Friendly

I know many of you out there are saying “mod_security’s been around forever and you’re just reading about it now?”

The truth is that I’ve heard of it, but hadn’t had both the time and the reminder to implement it until now.

The module provides Apache with application-level firewalling, protecting it from all manner of web attacks.

It’s relatively easy to use these days.

Download it from: http://www.modsecurity.org/download/index.html
Install it as per the README

Then you have to do some stuff that’s not in the docs I found, hence I’m writing this blog post.

Edit /etc/httpd/conf/httpd.conf

Put the following directives in:

LoadFile /usr/lib/libxml2.so
LoadModule unique_id_module modules/mod_unique_id.so
LoadModule security2_module modules/mod_security2.so

That mod_unique_id isn’t mentioned in the directions. Ergh!

Also, make sure you download the rules too.

You unzip/tar them into your /etc/httpd/conf.d directory (or make your own modsecurity directory and tell Apache to Include it).

Restart Apache.

Now you’ve got an application-level firewall on your web server. It took less than half an hour. Most of that was reading docs.

Changes to the server and site

2007/06/21 01:01:00
Print Friendly

No doubt, you’ll have noted some changes to the web site.

On Monday evening I rented a newer, cheaper, server from Layered Tech, saving myself about $20 a month. I told them to keep the old server online until the end of the billing cycle, figuring I had about a week to pull my data off of the server and make sure this one worked ok.

The end of the billing period was yesterday. I scrambled to get the data off of my server and onto the new server before the folks over there obeyed my direction to “shut it off at the end of the billing cycle”. Yeah. That was smart, so I made some changes while I was at it.

The new server runs CentOS 5, a newer, more up-to-date version of CentOS. It includes all kinds of goodies under the hood that will likely go unnoticed by visitors and bystanders, but it will allow me to do some things that CentOS 4 was holding me back on, mostly with PHP and Ruby on Rails. I like tinkering with my computers, and having the interpreters that work with the software I want to play with helps.

I’ve also got an (almost) fully functional web server. I still need to edit the skin for this site a bit, as well as load all over the old blog posts (that’ll take a bit), but all in all, I’m pretty close to being done for now.

As far as the site is concerned, gone is the ever growing list of projects that I did not have enough time to document with its own set of articles, wiki entries, and blog entries. I realized that I put everything into the blog and can handle it with categories and tags rather than creating an increasingly chaotic wiki.

Let me know what you think. Old blog posts should be back up soon.

Photos may take a while.

Annoyance with SELinux

2007/05/29 14:26:00
Print Friendly

If you don’t know what SELinux is, start here.

I just spent the last hour or two trying to figure out why syslog would not log anything on one of my machines. It turns out I must’ve copied an updated /etc/services file from /tmp to /etc. This would normally be fine, but the file did not contain the correct context. Instead, copying it gave it the context of the /tmp directory.

Hence, syslog would not start. Because syslog is where SELinux logs its errors, I couldn’t see any errors to lead me to figure out what the problem was.

Once I changed SELinux from enforcing to permissive with:

/usr/sbin/setenforcing Permissive

I could see that syslog started fine and was telling me that the context on /etc/services was out of wack.

Ergh…

I wonder if there is some way I can make sure this doesn’t happen again?

I guess I could use the setfiles command frequently to ensure that all of the file contexts are set correctly.

Sheesh.

How was your day? :-)

Centralized Authentication

2007/05/14 00:48:00
Print Friendly

Yip, I’m still alive.

I am a computer geek.

I do computer geek things.

After all of the work on the house for the past few months, I needed to engage in a geeky project, something that would benefit my network. Something that has plagued me since my server rebuild has been the lack of a centralized authentication scheme for my network. LDAP, of course, is the choice I had made, but setting it up and understanding what was going on would take longer than setting it up.

Tonight, I have published a brief article entitled “SSL LDAP Server on CentOS 5” which details how to set up the LDAP server portion of the authentication system. Soon I will include an article on the client end. One will be for CentOS and the final one will be for Windows, which can use pGina to load an LDAP module and authenticate (I found that to be very cool).

It wasn’t enough for me to just have centralized authentication. If that were all I needed, I would have used NIS. I wanted encryption so that any rogue program or user on my small home network would not be able to sniff my passwords off the wire. Paranoid? Yes, yes I am, but not enough to use Kerberos yet. I also wanted something that pGina would work with. Many factors had to be considered for my authentication scheme, including brief experiments with Samba and Microsoft Active Directory.

I also wanted to know how this all worked for work. What good is a security person who doesn’t understand how the technology works? I don’t know. There are too many of those. Maybe I can make things better by trying to be one that does, in some way, know how the tech works. It’s a goal. :-)