Remote Syslogd Logging

There are some issues with remote logging using syslogd. By default, anyone can write logs to syslod if it is accepting connections. This can be an issue if someone wants to fill your /var/log with junk.

On a default install of Debian (or just about any distro) you should have all the tools you need already.

On log server edit /etc/default/syslog


iptables -I INPUT -p udp –dport 514 -s CLIENTIP -j ACCEPT
iptables -A INPUT -p tcp -i eth1 –dport 22 -j ACCEPT
iptables -A INPUT -i eth0 -j DROP

You will want these iptables rules to be loaded on statup. How you do this will vary on your distro, but a simple start/stop script in /etc/rc2.d is the easiest way to go on debian.

On log client edit /etc/syslod.conf

auth.alert @server

mail.* @server

The client’s logs will end up in whatever file auth.alert gets logged to on the server.

Debian 4.0 (Etch) LDAP Server

LDAP still gets me from time to time. I’ve set up multiple Debian LDAP servers now, and each time it seems like something new gets me. I’m going to try to put together a set-by-step LDAP guide that is sure to work (with Debian Etch). If you have any problems, please post! This setup has been tested on x86 and amd64 Debian variants.There seem to be some bugs with debian’s default ldap install (missing .so files, config files that don’t work, not remembering settings from the setup screens). However, once everything works it’s rock solid.

apt-get install slapd ldap-utils libnss-ldap libpam-ldap nscd migrationtools

Add your admin password, and accept default ldapi for now. Replace example and net with your domain/hostname (where each “.” is a “dc=”).

libnss-ldap and libpam-ldap are set up the same way, use identical answers (passwords are saved in /etc/*.secret make sure permissions are 600!)

When prompted, replace ‘manager’ with ‘admin’ and example/net with your domain/hostname

Make root local database admin = yes

Database require login = no

Uncomment “rootdn” in /etc/ldap/slapd.conf and make sure all suffix’s are your domain and not a debian default (for example, localdomain or

Place a “rootpw password” entry under rootdn

/etc/nsswitch.conf should look like:

passwd: compat ldap
group: compat ldap
shadow: compat ldap

hosts: files dns
networks: files

protocols: db files
services: db files
ethers: db files
rpc: db files

netgroup: ldap

cd /usr/share/migrationtools

Edit and replace “” with your domain

./ > /tmp/base.ldif

./ /etc/passwd /tmp/passwd.ldif

./ /etc/group /tmp/group.ldif

/etc/init.d/slapd restart

ldapadd -x -W -D 'cn=admin,dc=example,dc=net' < /tmp/base.ldif

ldapadd -x -W -D 'cn=admin,dc=example,dc=net' < /tmp/passwd.ldif

ldapadd -x -W -D 'cn=admin,dc=example,dc=net' < /tmp/group.ldif

cp -p /usr/share/doc/libpam-ldap/examples/pam.d/* /etc/pam.d

apt-get install libpam-cracklib

ln -s /lib/security/ /lib/security/

You may have to remove the first block of text in base.ldif (ldap should already have it)

As far as I can tell, pam_ldap.conf and libnss-ldap.conf are broken by default. Do this to fix them.

echo > /etc/pam_ldap.conf

vim /etc/pam_ldap.conf

base dc=example,dc=net

uri ldap://

ldap_version 3

rootbinddn cn=admin,dc=example,dc=net

port 389

pam_password crypt

cp /etc/pam_ldap.conf /etc/libnss-ldap.conf

/etc/init.d/slapd restart

/etc/init.d/nscd restart

You might want to remove a test user from /etc/passwd and /etc/shadow that has been imported to ldap.

su – username

Is a good test. Check /var/log/auth.log if you have problems. If nothing is there, try

/etc/init.d/slapd stop

slapd -u openldap -g openldap -d 999

That will have slapd run as the users it’s supposed to, and be very verbose.

At this point, everything should be working (if not, don’t go forward yet!). Now we can use encryption, to increase the security of our ldap server.

cd /etc/ldap

mkdir ssl

openssl req -new -x509 -nodes -out ldap.pem -keyout ldap.pem -days 3650

chmod 640 ssl/ldap.pem

chmod 750 ssl

chown -R root:openldap ssl

At the very top of /etc/ldap/slapd.conf put

TLSCACertificateFile /etc/ldap/ssl/ldap.pem
TLSCertificateFile /etc/ldap/ssl/ldap.pem
TLSCertificateKeyFile /etc/ldap/ssl/ldap.pem

SSLVerifyClient none

Find the "access"lines near the bottom of slapd.conf and change them like this

access to attrs=userPassword,shadowLastChange
by tls_ssf=128 ssf=128 dn="cn=admin,dc=example,dc=net" write
by tls_ssf=128 ssf=128 anonymous auth
by tls_ssf=128 ssf=128 self write
by * none


access to *
by tls_ssf=128 ssf=128 dn="cn=admin,dc=example,dc=net" write
by * read

Make sure you restart

/etc/init.d/slapd restart

Assuming all goes well, you should still be able to "su - username" to your ldap-only user with the added benefit of encryption.

Additionally, if you find that SSL isn't working for you, try doing this.

Add the following to /etc/ldap/ldap.conf

TLS_CACERT /etc/ldap/ssl/ldap.pem

Add this to both pam_ldap.conf and libnss-ldap.conf

ssl start_tls

tls_checkpeer no

tls_cacertfile /etc/ldap/ssl/ldap.pem

After further investigation, 'ssl start_tls' is the way to go. Make sure ldap.conf has your SSL stuff in it and restart slapd and nscd.

Connect to a Running X Session Remotely

From the computer you want to view the remote X session:

ssh root@computer2 -L 5900:localhost:5900

If you can only connect to a linux gateway, you can substitute localhost with the internal IP address of the machine you want to vnc to.

ssh root@computer2 -L 5900:

On computer2 do the following.

This does not need to be done as root, but you’ll need to be the actual user running the X session if you log in as a regular user. On ubuntu/debian you can use apt-get install x11vnc.

x11vnc -display :0 -passwd password

If it complains that it cannot connect to :0, try this

x11vnc -auth /var/lib/gdm/:0.Xauth -passwd password

Note that using the :0.Xauth method will work if X is just running at the login screen (so you could connect and log into X as a user).

Now, from computer1, do

vncviewer localhost

This is very useful, but make sure you use a password if port 5900 is open on computer2.

Debian/Ubuntu Apache2 + PHP5 + Mysql + SSL

First let’s grab the packages we need for a basic LAMP setup:

apt-get install apache2 php5-cgi libapache2-mod-php5 mysql-server php5-mysql php5-common apache2.2-common ssl-cert

If using Ubuntu, be sure to install libapache2-mod-auth-mysql

apache2.2-common and ssl-cert are needed to generate a ssl cert

make-ssl-cert /usr/share/ssl-cert/ssleay.cnf apache.crt
mkdir /etc/apache2/ssl
mv apache.crt /etc/apache2/ssl

cd /etc/apache2/mods-enabled
ln -s ../mods-available/ssl.conf ssl.conf
ln -s ../mods-available/ssl.load ssl.load

Make sure /etc/apache2/ports.conf is listening on 443

Listen *:443

In your 000-default file in /etc/apache2/sites-enabled (or where ever your VirtualHosts are managed) Change:

NameVirtualHost *
<VirtualHost *>


NameVirtualHost *:80
NameVirtualHost *:443
<VirtualHost *:80>

Add a site for SSL:

<VirtualHost *:443>
ServerAdmin webmaster@localhost
DocumentRoot /var/wwws
SSLEngine on
SSLCertificateFile /etc/apache2/ssl/apache.crt
<Directory />
Options FollowSymLinks
AllowOverride None
<Directory /var/wwws>
Options Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
allow from all

/etc/init.d/apache2 restart

By default, the User/group is www-data so make sure all your website files are owned by this user/group.

chown -R www-data:www-data /var/wwws/

Will accomplish this

All website files should be located in /var/www and /var/wwws (you can choose different directories, of course, like /home/www but make sure you change the config)

Debian Spamassassin/SquirrelMail

Updated Jan 24, 2008

Try the following crontab entries

0 0 * * * /usr/bin/find /home/*/Maildir/.Spam/cur/ -type f -mtime +7 | xargs rm -f 1> /dev/null
0 1 * * * sa-learn –spam /home/youruser/Maildir/.Spam/cur/* 1>/dev/null

The first line will check for spam older than 7 days and delete it. This is a very useful (and fast!) way to save diskspace.

Change ‘youruser’ to your actual user. Anything put in your spam folder on squirrelmail will be marked as spam.

Thanks to WastedMemory for helping me with this.

This assumes you’ve already set up a functioning MTA and have imap/pop working.

apt-get install spamassassin squrirelmail

Edit /etc/default/spamassassin and set ENABLED=1

Create a file called /etc/procmailrc

| /usr/bin/spamc

* ^X-Spam-Status: Yes

To set up squirrelmail, edit /etc/apache2/sites-enabled/000-default (or whatever site you want to use) and add:

Alias /mail /usr/share/squirrelmail

<Directory /usr/share/squirrelmail>
Options Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
allow from all

Restart apache2, squirrelmail

/etc/init.d/apache2 restart && /etc/init.d/spamassassin restart

As a normal user (su – user), do:

maildirmake (or maildirmake.courier) ~/Maildir

Go to http://your-ip/mail and log in as the user you created Maildir with. Log in, and send a test email to another address.

Back as your user, do:

cd ~/Maildir

cp -rp .Sent .Spam

It might be a good idea to have all new users have this directory created.

cp -r /home/user/Maildir /etc/skel

If you have many users that already exit, you can do this:

for x in `ls /home`; do

cp -r /etc/skel/Maildir /home/$x

chown -R $x /home/$x/Maildir


Spam will now go to their Spam folder. They can check this by subscribing to INBOX.Spam in squirrelmail (Folders)

You can change the sensitivity of Spamassassin by editing /etc/spamassassin/

required_score 1.0

Ban an IP using IP Tables

I’ve been doing this several different ways over the past few years, but I’ve found this works the best for banning an IP address. Remember, if you see a weird domain in netstat you can resolve the IP using traceroute.

A simple script (/usr/bin/ban) that I can use to ban IP addresses quickly and easily.

iptables -I INPUT -s $1 -j DROP
echo $1 was banned

If you wished to make an ‘unban’ script, use the same script and replace -I with -D