Category: Security

Banning ips with Denyhosts and iptables

If you’re looking for a nice way to automatically ban an ip address without specifically doing the iptables command, here’s a nice script to get you started. This script parses the /etc/hosts.deny file and blocks them using iptables.


#!/bin/bash

ROOT_UID=0


E_NOTROOT=67


if [ "$UID" != "$ROOT_UID" ]; then


echo "Must be root to run this script."


exit $E_NOTROOT


fi


iptables -F


echo "The following ips are blocked: " 1> /var/log/block.log


for x in `cat /etc/hosts.deny | grep -v ^# | cut -d ":" -f 2`; do


/usr/share/.scripts/deny.sh $x >> /var/log/block.log


done


exit0;

For ease of use, that script calls another script called deny.sh.


#!/bin/bash


ROOT_UID=0


E_NOTROOT=67

if [ "$UID" != "$ROOT_UID" ]; then

echo "Must be root to run this script."

exit $E_NOTROOT

fi

iptables -I INPUT -s $1 -j DROP

if [ $? != 0 ]; then

echo "block did not work on $1"

exit 1;

fi

echo "$1 was blocked."

exit 0;

Notice that the script first flushes all the current blocked ip addresses so that you don’t accidentally block the ip addresses many times. This could cause many problems if you’re trying to unblock someone.
Have fun and be safe!

Secure Portable Workstation with Debian Etch

Pictures coming soon!

I came across a “dying” Dell Latitude C680. It was old, but after looking at the specs I decided to keep it.

2.4/1.2ghz (speedstep)

1GB Ram

60GB HDD (mine was dead)

Two battery/expansion bays (one battery, one floppy)

One CD-Rom drive (thought it was dead, turned out to be the bay itself was bad)

GeForce 440 64mb video

The cdrom drive failed on me, but I was able to replace the floppy drive with another CD-rom drive.

I modified the hard drive bay caddy (mostly with electrical tape and the plastic case of a CF card) to house a 4GB CompactFlash card connected to a CF to IDE laptop convertor. With a little bit of fuss, I was able to get it to slide into the bay without catching on anything.

Using a Debian Etch CD, I did a full disk encryption LVM base install. It wasn’t too slow, however there were parts where the CF card was obviously choking a bit.

After booting into the system, I tested the CF card with hdparm -tT /dev/hda and was pleasantly surprised.

Timing cached reads: 716 MB in 2.00 seconds = 357.50 MB/sec
Timing buffered disk reads: 114 MB in 3.02 seconds = 37.71 MB/sec

So cached reads are about 1/2 as slow as I’d expect from a regular IDE drive, but the buffered disk reads are about as high.
I’m running Fluxbox, with Iceweasel and a few other operations and am noticing no problems with performance. Sometimes when dealing with multiple files at the same time things get slow.

Like any solid-state drive, this will make your laptop much more rugged (no moving parts except for fans and cd-rom drive).

While it has limited space, I could have easily purchased a 8/16/32GB CF card with similar speeds… if I had the money.

The CF card was around $25, and the adapter was $5.

For the next stage, I plan on using the now dead CD rom bay on the side to house USB devices with a powered USB hub.

This laptop will mainly be used for school (if it gets stolen, not a big deal) and war driving.

tcpwrappers

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.

/etc/hosts.deny

sshd: ALL
ftpd: ALL
mountd: ALL

/etc/hosts.allow

sshd: 192.168.0.0/24
ftpd: 192.168.1.0/255.255.255.0
mountd: 192.168.5.2,server2,192.168.3.2,192.168.6.0/24

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

smtpd_sender_restrictions=check_sender_access,hash:/etc/postfix/domains,

reject_unauth_destination,reject_sender_login_mismatch

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

smtpd_recipient_restrictions=permit_mynetworks,reject_unauth_destination,

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.

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

or

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.

http://bbis.us/debian-iptables.tar.gz

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

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

SYSLOGD=”-r”

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 / Ubuntu NFS Server

apt-get install nfs-kernel-server nfs-common portmap

By default, portmap is only accessiable on localhost. This seems to have changed for Etch, but it doesn’t hurt to double check.

Remove the line ‘-i 127.0.0.1’ option from ARGS in the file /etc/default/portmap or comment it out.

Restart it with /etc/init.d/portmap restart

Edit /etc/exports

/usr/local 192.168.1.(rw,no_root_squash,async)
/stuff 192.168.1.(ro,async)

This will make nfs-kernel-server complain about ‘no_subtree_check’; feel free to add it.

no_root_squash means that the ‘root’ user on a client system going to this directory will be root on the server share as well. This is something you’ll only want to use in a protected LAN. Otherwise, ‘root’ will be ‘nobody’ while in the shared directory.

NEVER ALLOW NFS TO BE SHARED ACROSS THE INTERNET.

NFS is unencrypted by default (I believe you can only encrypt it using Kerebos).

I highly suggest you use tcpwrappers.

/etc/hosts.allow

portmap: 192.168.1.
lockd: 192.168.1.
rquotad: 192.168.1.
mountd: 192.168.1.
statd: 192.168.1.
nfs: 192.168.1.

/etc/hosts.deny

portmap:ALL
lockd:ALL
mountd:ALL
rquotad:ALL
statd:ALL
nfs:ALL

To make everything easier, edit your /etc/hosts file. This should be the same on all linux machines.

192.168.1.100 laptop
192.168.1.101 server
192.168.1.104 workstation

Restart NFS.

/etc/init.d/nfs-kernel-server restart

Mount on the client machine now:

mount server:/usr/local /mnt/server-local

You’ll probably want to add this to /etc/fstab.

server:/usr/local /mnt/sever-local nfs rsize=8192 0 0

On a desktop machine, I like these options

server:/usr/local /mnt/server-local nfs rsize=8192,user,noauto 0 0

This will allow your user to mount the share by double-clicking ‘server-local’ in “Computer” (located in Places on Ubuntu)

Passwordless SSH Authentication

This will show you how to log into SSH without having to use a password.

From the machine you want to be able ssh without a password from

ssh-keygen -t dsa

Default password, and empty passphrase.

From the same machine

cat ~/.ssh/id_dsa.pub | ssh user@remote “cat – >> ~/.ssh/authorized_keys”

ssh user@remote

You should now be in without having to be asked a password. There are some obvious security implications here; nothing you should have to worry about if you have a strong password and good permissions on /home/user.

This is very useful for automated backups using scp/rsync.

scp -r -p ~/Important user@remote:~/backups/`date +%F`

The above command will backup /home/user/Important to /home/user/backups/2008-01-18

I’ll deal with rsync in a different post; lots of nifty stuff there. 😉

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 example.net)

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 migrate_common.ph and replace “padl.com” with your domain

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

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

./migrate_group.pl /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/pam_unix.so /lib/security/pam_pwdb.so

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://127.0.0.1/

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
TLSCipherSuite HIGH:+MEDIUM:!LOW

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

and

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
TLS_REQCERT demand

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.

http://bbis.us/etch-ldap.tar.gz