Ubuntu 8.10 LDAP Server with TLS

This should also work with Ubuntu 9.04

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

Much like Debian, we must perform an extra step to make our changes permanent.

dpkg-reconfigure slapd

Omit OpenLDAP server configuration? No
DNS domain name: your-server
Organization name: whatever
Database backend to use: HDB
Do you want the database to be removed when slapd is purged? No
Move old database? Yes
Admin password: <password>
Confirm: <password>
Allow LDAPv2 protocol: No

Now we will populate LDAP. You should probably add a temporary LDAP user for testing. After we populate LDAP we’ll remove it.

adduser test
cd /usr/share/migrationtools

Edit migrate_common.ph and replace “padl.com” with your domain and dc=padl,dc=com with dc=YOUR,dc=DOMAIN

./migrate_base.pl > /tmp/base.ldif

./migrate_passwd.pl /etc/passwd /tmp/passwd.ldif

./migrate_group.pl /etc/group /tmp/group.ldif

Remove the top section of /tmp/base.ldif

dn: dc=dev
dc: dev
objectClass: top
objectClass: domain

Restart LDAP and add our information to LDAP

/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

To enable PAM I suggest

cd /tmp
wget http://st0rage.org/files/pam.d.tar
tar xf pam.d.tar -C /etc

Alternativly, you can try the following Ubuntu specific method:

auth-client-config -t nss -p lac_ldap
pam-auth-update ldap

Please note that I was unable to change user passwords with ‘passwd’ using this method.

Remove the test user

userdel test

Set up TLS Certificate

mkdir /etc/ldap/ssl
cd /etc/ldap/ssl

openssl req -new -nodes -out req.pem -keyout key.pem
#No challenge password, leave empty
openssl rsa -in key.pem -out new.key.pem
openssl x509 -in req.pem -out ca-cert -req -signkey new.key.pem -days 9999
mv new.key.pem server.pem
cat ca-cert >> server.pem

Enable TLS on server

ldapmodify -x -D cn=admin,cn=config -W

Paste in the following:

dn: cn=config
add: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/ldap/ssl/server.pem
add: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ldap/ssl/server.pem
add: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ldap/ssl/server.pem

Press ENTER a few times to finish modifying and then Control+C when you see:

modifying entry "cn=config"

Edit /etc/default/slapd and add

SLAPD_SERVICES="ldap:/// ldaps:/// ldapi:///"

Restart slapd

/etc/init.d/slapd restart

If it fails, try:

chown -R openldap /etc/ldap/ssl
/etc/init.d/slapd restart

Client configuration

vi /etc/ldap.conf

uri ldaps://server
port 636
ssl start_tls
ssl on
tls_checkpeer no
tls_cacertfile /etc/ldap/ssl/server.pem

vi /etc/nsswitch.conf

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

Now test! Make sure to stop nscd if you’re using it

/etc/init.d/nscd stop


$ id test
uid=1001(test) gid=1001(test) groups=1001(test)

Remember to keep an eye on /var/log/auth.log if you run into any problems

Enable network virtio (Gigabit) in libvirt/kvm Virtual Machine Ubuntu 8.10

If you create a domain with virt-manager, it does not always add the appropriate ‘virtio’ entry to the xml file for your VM.

If this is the case, you will notice that network speeds on the VM will not break 10/100 speeds.

To fix this, edit the xml file

vi /etc/libvirt/qemu/vm.xml

Make sure your network block looks like this (keep your MAC address the same)

<interface type='network'>
<mac address='00:16:36:0b:4c:9c'/>
<source network='default'/>
<model type='virtio'/>

Shut down the VM and confirm it’s shut down

virsh shutdown vm

# virsh list
Connecting to uri: qemu:///system
Id Name                 State

If you do not see your vm “running” you can proceed. If it’s still running you need to shut it down another way.

Update the xml definition

virsh define /etc/libvirt/qemu/vm.xml

Start the domain

virsh start vm

Log into the VM and test with a 1GB file

dd if=/dev/zero of=/tmp/test bs=1M count=1000
scp /tmp/test [email protected]:/tmp

You should see transfer speeds above 11-12 megabytes/second.

Easy Ubuntu Traffic Shaping

I manage a Linux router that provides internet access to tenants in an apartment building. From time to time, a user will do something that will ruin the connection.

It can be Limewire, BitTorrent or just Skype… but the end result is a latency of more than 400ms!

Recently I came across a simple way to do this on Debian/Ubuntu.

apt-get install wondershaper

The usage is simple

wondershaper eth0 4600 490

This would limit you to 4600 kbits download and 490 kbits upload.

Before you limit your speed, make sure your connection is not being heavily used and ping google.com (and a few other servers). Get a good idea of your latency (Mine is 15ms at night, and 25ms during the day).

You should find out your actual speed; I suggest speedtest.net for testing. You should also do this across several days at different times!

Let’s say you find out that you have 5800 down and 600 up. If you ping google while you’re testing your connection you are going to notice that your latency goes up.

Since you probably want to avoid this, try different values for wondershaper until your latency is a low value even when you are using all avaible bandwidth. I find that 80% of your max speed is a good value to shoot for.

I find that I can use bittorrent on multiple computers and use speedtest.net and still have a latency of around 30ms limiting a 6000/600 connection to 5000/500.

If you come across any errors when running this script (Debian has this problem for me), just comment out the line causing the error. Everything will still work.

Apache2 Bandwidth Limiting in Ubuntu Hardy 8.04

Unfortunately there is no libapache2-mod-bw for Ubuntu, so limiting bandwidth used by apache isn’t possible by default. Follow these steps to enable it.

wget http://ivn.cl/files/source/mod_bw-0.8.tgz

tar xvzf mod_bw-0.8.tgz

cd mod_bw

apxs2 -i -a -c mod_bw.c

You will probably get this error

apxs:Error: Activation failed for custom /etc/apache2/httpd.conf file..
apxs:Error: At least one `LoadModule’ directive already has to exist..

It’s safe to ignore this.

vi /etc/apache2/mods-available/mod-bw.load

LoadModule bw_module /usr/lib/apache2/modules/mod_bw.so

vi /etc/apache2/mods-available/mod-bw.conf

BandWidthModule On
BandWidth all 40000
MinBandWidth all 10000
ForceBandWidthModule On

Set permissions

chown www-data /etc/apache2/mods-available/mod-bw*

Activate the module

a2enmod mod-bw

(To deactivate use: a2dismod mod-bw)

Restart apache2

/etc/init.d/apache2 force-reload

Download a file (I suggest doing it remotely to test it), and you should be limited to around 40 kilobytes/second total, with each user guaranteed 10 kilobytes/second. Change this number accordingly.

Universal Plug and Play (uPnP) in Debian

Before I begin, uPnP does have some security implications. Users that can send uPnP requests can open any port to any other computer. Please read the comments below for more details.

If you are currently using a Linux router on a home network, you should consider uPnP. uPnP allows computers to request ports be opened for them, so applications that require open ports can work without work of the owner of the Linux router.

apt-get install libupnp0 linux-igd

Edit /etc/default/upnpd and specify your external and internal interfacecs; upnp does not support multiple interfaces but I suspect multiple instances of this program could accomplish this; just replace the /etc/init.d/upnpd file with a custom one like this


case $1 in


upnpd eth0 eth1

upnpd eth0 eth2



killall upnpd



Restart the daemon, and you should see clients requesting ports in /var/log/syslog (grep for upnp).

If you do not, make sure that you see the following line in “route”       *            U     0      0        0 eth3

Where eth3 is your internal interface. If not, add it with

route add -net netmask eth3

Also, if you are blocking any ports with your firewall configuration, you may have to do the following to allow your clients request to reach the server.

iptables -A INPUT -s -p tcp --dport 2869 -j ACCEPT
iptables -A INPUT -s -p udp --dport 1900 -j ACCEPT

Where is your internal network.

A good way to test to make sure this is working is using the Azureus bittorrent client’s NAT checking tool.

Below is a two network firewall script that I am currently using with uPnP; I can’t make any guarantees to how secure it is but it works quite well.

/sbin/ip addr add dev eth0 $IP2
/sbin/ip addr add dev eth0 $IP3
/sbin/depmod -a
/sbin/modprobe ip_tables
/sbin/modprobe ip_conntrack
/sbin/modprobe ip_conntrack_ftp
/sbin/modprobe ip_conntrack_irc
/sbin/modprobe iptable_nat
/sbin/modprobe ip_nat_ftp
/sbin/modprobe ip_nat_irc
echo "1" > /proc/sys/net/ipv4/ip_forward
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
echo "65535" > /proc/sys/net/ipv4/ip_conntrack_max
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
echo "1" > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
echo "1" > /proc/sys/net/ipv4/conf/all/accept_redirects
echo "0" > /proc/sys/net/ipv4/conf/all/log_martians
echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout
echo 9000 > /proc/sys/net/ipv4/tcp_keepalive_time
echo 1 > /proc/sys/net/ipv4/tcp_window_scaling
echo 0 > /proc/sys/net/ipv4/tcp_sack
echo 3000 > /proc/sys/net/ipv4/tcp_max_syn_backlog
$IPT -A DROPLOG -j ULOG -m limit --limit 2/hour --ulog-nlgroup 1 --ulog-qthreshold 20
$IPT -t nat -A POSTROUTING -s -o eth0 -j SNAT --to-source $IP2
$IPT -t nat -A POSTROUTING -s -o eth0 -j SNAT --to-source $IP3
$IPT -t nat -A POSTROUTING -s -o eth0 -j MASQUERADE
$IPT -t nat -A POSTROUTING -s -o eth0 -j MASQUERADE
$IPT -t nat -A POSTROUTING -s -d -j ACCEPT
$IPT -t nat -A POSTROUTING -s -d -j ACCEPT
$IPT -t nat -A POSTROUTING -s -d -j ACCEPT
$IPT -t nat -A POSTROUTING -s -d -j ACCEPT
$IPT -t nat -A POSTROUTING -s -d -j ACCEPT
$IPT -A INPUT -p tcp --dport 22 -j ACCEPT
$IPT -A INPUT -p tcp --dport 80 -j ACCEPT
#Allow uPnP from internal clients
$IPT -A INPUT -s -p tcp --dport 2869 -j ACCEPT
$IPT -A INPUT -s -p udp --dport 1900 -j ACCEPT
$IPT -A INPUT -s -p tcp --dport 2869 -j ACCEPT
$IPT -A INPUT -s -p udp --dport 1900 -j ACCEPT
$IPT -A INPUT -i eth2 -j ACCEPT
$IPT -A INPUT -i eth3 -j ACCEPT
$IPT -A INPUT -p tcp -s --dport 3128 -j ACCEPT
$IPT -A INPUT -p tcp -s --dport 3128 -j ACCEPT
$IPT -t nat -A PREROUTING -i eth1 -p tcp --dport 80 -j DNAT --to
$IPT -t nat -A PREROUTING -i eth2 -p tcp --dport 80 -j DNAT --to
$IPT -t nat -A PREROUTING -i eth3 -p tcp --dport 80 -j DNAT --to
$IPT -t nat -A PREROUTING -i eth4 -p tcp --dport 80 -j DNAT --to
$IPT -t nat -A PREROUTING -i eth5 -p tcp --dport 80 -j DNAT --to
$IPT -A INPUT -i eth0 -p tcp --syn --destination-port 3128 -j DROPLOG


TCP wrappers are one of Linux’s most useful built-in features.

Instead of using a complex set of firewall rules, tcpwrappers provides an easy method of restricting access to certain daemons using ip addresses, host names, and ranges. While I wouldn’t reccommend on relying soley on them, they are a great tool for workstations and other machines behind a firewall.

hosts.deny is checked first; then hosts.allow. By default, if a program is not listed in either it is granted access to everyone.


sshd: ALL
ftpd: ALL
mountd: ALL



As you can see, you have several different ways to give (or prevent) access.

Generally any program you see running as rpc.program will be supported via tcpwrappers (use program, not rpc.program in hosts.*). Anything running from inetd.conf will also be supported.

Stand-alone services (ignoring SSH/FTP) will generally not work with this, and rely on the program denying access or iptables.

Even if you use iptables, have some service: ALL lines in /etc/hosts.deny can be useful if you ever have problems with iptables

Postfix Security

A major problem with the default postfix install is that any user can send email as any user (even if it’s not your domain!)

The solution is very simple.

Edit /etc/main.cf and add

smtpd_delay_reject = yes
smtpd_helo_required = yes



Make sure you don’t add ‘permit_mynetworks’ here, or local users (or webmail users) will be able to forge their email.

In /etc/postfix/domains, add

your.domain OK

other.domain OK

and run

postmap /etc/postfix/domains

postfix reload

You might also want to try to help stop spam (along with spamassassin) with blacklists and stopping bad senders.

In /etc/postfix/main.cf


reject_invalid_hostname,reject_non_fqdn_recipient,reject_unknown_recipient_domain,reject_rbl_client list.dsbl.org,reject_rbl_client sbl.spamhaus.org,reject_rbl_client cbl.abuseat.org,reject_rbl_client dul.dnsbl.sorbs.net,permit

I have mixed feelings about blacklists; my website has shown up on them from time to time after all. Still, if you’re willing to get a few false positives then this should help stop quite a bit of spam.

Speed up network transfers with ssh and tar

When you use sftp/scp to transfer directories, you notice it ends up taking a long time. It works on files one at a time and they can often take a small amount of time to start and finish. A solution is to use tar to stream the file over ssh (so you have one continuious stream, without starting/stopping a lot).

ssh [email protected] “tar cf – big_dir/” | tar xf –

I timed transferring a 330MB directory with more than 3600 files in it.

Transferring over 10/100 Ethernet over SMBFS with ‘cp -r’

real    2m45.495s
user    0m0.100s
sys     0m4.424s

Transferring over 54mb WiFi (at 70% signal strength) using ssh/tar

real    2m8.800s
user    0m12.377s
sys     0m10.501s

Transfering over 10/100 Ethernet using ssh/tar

real    0m37.929s
user    0m5.628s
sys     0m4.068s

It took 37 less seconds over wireless (pretty impressive, especially when dealing with only 330MB). It was a full 2 MINUTES (and 8 seconds) faster over the same kind of connection.

This is useful both in a LAN enviornment and over the internet.

Debian: IPtables and net protection should be enabled by default

As I come across network security issues in Linux, I can’t help but wish that Debian had decent default firewall rules (and kernel network protection in general) like many other distros.

This applies to both Debian 4.0 and Ubuntu 7.10.

By default, a Ubuntu or Debian install of Linux is vulnerable to a SYN flood. If behind a router, chances are there won’t be a problem. But if it’s a standalone Linux machine connected to the internet, the machine is vulnerable to a DoS attack.

It’s a simple fix.

echo 1 > /proc/sys/net/ipv4/tcp_syncookies


iptables -A INPUT -i eth0 -p tcp –tcp-flags ALL ACK,RST,SYN,FIN -j DROP
iptables -A INPUT -i eth0 -p tcp –tcp-flags SYN,FIN SYN,FIN -j DROP
iptables -A INPUT -i eth0 -p tcp –tcp-flags SYN,RST SYN,RST -j DROP

The second should probably be used if it’s a server. The first way may still have quite a few open SYN connections.

You may just want to block the IP(s) that are conducting a SYN flood on you (keep an eye on netstat or iptables.log). A script that does this would be pretty useful; I wonder if there are any out there (or if I have to write one?).

iptables -I -s ip.to.ban -j DROP

Along with rules to help protect against flooding, it seems like it would be a good idea to block all ports by default.

iptables -A INPUT -m limit –limit 100/second –limit-burst 150 -j RETURN

One solution could be to have a folder called /etc/security/iptables that contains files that get passed to iptables at startup (in the same way /etc/rc2.d gets read in numeric order). So you could have files like 22ssh, 23ftp, etc. with iptable rules in each file. You could also have an ‘ENABLED’ variable like some files in /etc/default have (so that ports wouldn’t be opened by default; the user would have to manually enable them for the port to be opened).

Then they’d just run /etc/init.d/iptables restart and the port would be opened (flush the rules, reapply).

I’ve put together a proof-of-concept for this; feel free to check it out. Extract it somewhere, and check out the source. Then try the following

tar xvzf debian-iptables.tar.gz -C /

Which will create and fill /etc/security/iptables and put an init file in /etc/init.d and a link in /etc/rc2.d

It hasn’t been tested as much as I’d like, but it should work.

Please do this at the computer itself; if you do it over the network you might be locked out.


iptables logging (the good way) in Debian Etch

When using iptables to log, you generally make a ‘LOG’ chain, and then

iptables -A INPUT -j LOG

iptables -A INPUT -j DROP

To log and then drop.

LOG has some disadvantages though. Using LOG, information will fill up the output of the ‘dmesg’ command as well as the kern.log file. Using Debian Etch, I was unable to get iptables to log to any other file but kern.log.

A better solution is ULOG.

You can clear your dmesg output with ‘dmesg -c’

apt-get install ulogd

iptables -N DROPLOG
iptables -A DROPLOG -j ULOG -m limit –limit 2/hour –ulog-nlgroup 1 –ulog-qthreshold 20

iptables -A DROPLOG -j REJECT
iptables -A INPUT -p tcp -i eth0 –dport 22 -j ACCEPT
iptables -A INPUT -i eth0 -j DROPLOG

This will drop and log all incoming traffic except for port 22.

You shouldn’t need to edit /etc/ulogd.conf, but you might want to check it out.

All information should get logged to /var/log/ulog/syslogemu.log