19 Feb 2008 mysql_secure_installation — Improve MySQL Installation Security
This program enables you to improve the security of your MySQL installation in the following ways:
- You can set a password for root accounts.
- You can remove root accounts that are accessible from outside the local host.
- You can remove anonymous-user accounts.
- You can remove the test database, which by default can be accessed by anonymous users.
Invoke mysql_secure_installation without arguments:
shell> mysql_secure_installation
The script will prompt you to determine which actions to perform.
Source: http://dev.mysql.com
Posted by Hans-Henry Jakobsen
10 Feb 2008 chkrootkit: false positive on port 465
On my Debian Etch server I’ve got Zimbra Open Source Edition mail solution installed and when I use chkrootkit to scan for rootkits it reports the following
Checking `bindshell'... INFECTED (PORTS: 465)
After a quick research I realized that this port 465 is SMTP over SSL on a Zimbra installation.
Further investigation reveals that port 465 is run by
# fuser -vn tcp 465
USER PID ACCESS COMMAND
465/tcp: root 19053 F.... master
And then I checked pid 19053
# ps aux|grep 19053 root 19053 0.0 0.2 6628 1236 ? Ss Feb09 0:00 /opt/zimbra/postfix-2.4.3.4z/libexec/master
This tells me that the postfix daemon is running on port 465 and obviously chkrootkit is giving me a false positive.
Tags: chkrootkit, fuser, Postfix, rootkit, Zimbra
Posted by Hans-Henry Jakobsen
15 Jan 2008 Allow NFS through iptables on a RedHat system
This post describes how you can configure your RedHat Enterprise WS 4 NFS system behind a iptables firewall to be available for clients outside the firewall on a permanent basis.
Symptom
NFS relies on portmap to assign the ports on which it will listen. One side effect of this is that the ports are randomly assigned, so each time NFS is restarted the ports will change. This can make it difficult to run an NFS server behind a firewall which only allows access to specific ports on the system.
Solution
The first step is to assign a permanent port number to each of the NFS services (rquotad, mountd, statd, and lockd). While they can use any unused ports greater than 1024, it is recommended that you first consult the file /etc/services to find a valid unused port range. The following examples use the range 10000-10005.
The majority of the ports are configured through the file /etc/sysconfig/nfs. You will need to create this file if it does not exist. It should look similar to the following example:
# NFS port numbers STATD_PORT=10002 STATD_OUTGOING_PORT=10003 MOUNTD_PORT=10004 RQUOTAD_PORT=10005
The lockd service is configured differently from the others because it is compiled as a kernel module. To set the port which lockd uses, add these options in the /etc/sysconfig/nfs file:
LOCKD_UDPPORT=30001 LOCKD_TCPPORT=30001
where “30001″ can be replaced with any port that is available and can be assigned for use.
After these configuration changes, you can view the port assignments with the command rpcinfo -p
# rpcinfo -p | awk -F " " '{print $3 ", " $4 ", " $5}' | sort | uniq
proto, port,
tcp, 111, portmapper
tcp, 2049, nfs
tcp, 32771, nlockmgr
tcp, 800, rquotad
tcp, 814, mountd
udp, 111, portmapper
udp, 2049, nfs
udp, 32768, nlockmgr
udp, 797, rquotad
udp, 811, mountd
At this point, the ports will remain the same when NFS is restarted. The following is a list of ports which need to be opened on the firewall:
proto, port, tcp, 10004, mountd tcp, 10005, rquotad tcp, 111, portmapper tcp, 2049, nfs tcp, 32771, nlockmgr udp, 10004, mountd udp, 10005, rquotad udp, 111, portmapper udp, 2049, nfs udp, 32768, nlockmgr
You can now open these ports on the firewall to allow remote clients to mount a share on the server. If you are using iptables, the following commands can be used to add inbound/outbound rules to allow access to these ports.
This is an excerp of my /etc/sysconfig/iptables file. It allows NFS connections from IP address 192.168.0.10 but doesn’t restrict traffic out.
-A RH-Firewall-1-INPUT -s 192.168.0.10 -p tcp -m tcp --dport 111 -j ACCEPT -A RH-Firewall-1-INPUT -s 192.168.0.10 -p udp -m udp --dport 111 -j ACCEPT -A RH-Firewall-1-INPUT -s 192.168.0.10 -p tcp -m tcp --dport 2049 -j ACCEPT -A RH-Firewall-1-INPUT -s 192.168.0.10 -p udp -m udp --dport 2049 -j ACCEPT -A RH-Firewall-1-INPUT -s 192.168.0.10 -p tcp -m tcp --dport 10000 -j ACCEPT -A RH-Firewall-1-INPUT -s 192.168.0.10 -p udp -m udp --dport 10001 -j ACCEPT -A RH-Firewall-1-INPUT -s 192.168.0.10 -p tcp -m tcp --dport 10002:10005 -j ACCEPT -A RH-Firewall-1-INPUT -s 192.168.0.10 -p udp -m udp --dport 10002:10005 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A RH-Firewall-1-INPUT -i eth0 -p tcp -m tcp -j LOG --log-prefix "Reject Traffic " --log-level 6 -A RH-Firewall-1-INPUT -i eth0 -p tcp -m tcp -j REJECT --reject-with icmp-port-unreachable
This post is a modified example of the solution from RedHat Knowledgebase Article ID 5928.
Tags: iptables, NFS, RedHat, rpcinfo
Posted by Hans-Henry Jakobsen
20 Dec 2007 Allow NFS through iptables
This is one way to determine the ports needed to open in your iptables rules to get NFS to work properly. First we need to determine the ports NFS uses
rpcinfo -p | awk -F " " '{print $3 ", " $4 ", " $5}' | sort | uniq
Notice!
Since portmap assigns ports on random this example is only valid as long as you don’t restart your NFS.
On my system, a RedHat Enterprise Linux WS 4, the result was
proto, port, tcp, 111, portmapper tcp, 2049, nfs tcp, 32771, nlockmgr tcp, 768, rquotad tcp, 782, mountd udp, 111, portmapper udp, 2049, nfs udp, 32768, nlockmgr udp, 765, rquotad udp, 779, mountd
This gave me a nice overview of protocols (tcp/udp) and ports used.
Now the rules
iptables -A RH-Firewall-1-INPUT -s 192.168.0.0/255.255.255.0 -i eth0 -p tcp -m state --state NEW -m multiport --dports 111,2049,32771,768,782 -j ACCEPT iptables -A RH-Firewall-1-INPUT -s 192.168.0.0/255.255.255.0 -i eth0 -p udp -m state --state NEW -m multiport --dports 111,2049,32768,765,779 -j ACCEPT
You see that the multiport statement is just like the result of my rpcinfo command above.
Remember to save your new rules, othervise they will disappear the next time the iptables rules are being loaded.
In addition to this rule you should add the iptables rule for ssh access I wrote about earlier.
Another way to determine the ports
nmap -sC -p 111 localhost
Notice!
This solution won’t work after a reboot of the server since NFS changes ports. One way to overcome this problem is to follow the instructions in a newer post I’ve made about RedHat and NFS.
Tags: awk, iptables, nmap, rpcinfo, sort
Posted by Hans-Henry Jakobsen
18 Dec 2007 Determine false positive from rkhunter
I’ve installed rkhunter, a rootkit checking script, on a Ubuntu 7.10 (Gutsy Gibbons) distro and today it mailed a message saying that 3 files had their properties changed. The files were /usr/bin/chattr, /usr/bin/lsattr and /usr/bin/perl
Before doing anything I tried to update rkhunter to see if there had been any updates to fix this message rkhunter --update but the files were still giving a error warning. Since I haven’t used Debian/Ubuntu systems much I had to find a way to determine if these files had been tampered with. If this had been a RedHat system I would have run the command rpm -V packagename to verify if a package has been tampered with.
I found the package list at http://packages.ubuntu.com and entered the program paths I’ve shown above in the “Search the contents of packages” search box. The result after the search for /usr/bin/chattr, /usr/bin/lsattr and /usr/bin/perl
- /usr/bin/chattr was in the package base/e2fsprogs
- /usr/bin/lsattr was in the package base/e2fsprogs
- /usr/bin/perl was in the package base/perl-base
Downloaded the packages from the same website and verified the downloads using md5sum and then used the ar command to unpack/extract the files.
ar -x *.deb
This will give two tarballs control.tar.gz and data.tar.gz. The first is the information dpkg needs to do a proper installation and configuration of the package, the second contains the binaries and data files.
When I extracted the tarball named data.tar.gz and wrote a little script using md5sum on each of the files to determine that all files were valid with the correct size, sum etc.
The md5sum script
#!/bin/bash
# This script have to be run from the path you extracted the debian package
for FILE in " /usr/bin/chattr /usr/bin/lsattr /usr/bin/perl usr/bin/chattr usr/bin/lsattr usr/bin/perl"
do
md5sum $FILE > md5sums.txt
done
echo If this number is larger than the amount of files compared, then something is fishy
echo `awk -F " " '{ print $1 }'< md5sums.txt | sort | uniq | wc -l`
Luckily my system files had the same md5sum as the files extracted from the downloaded package. This proves that my system was not compromised, at least not these files anyway.
The script can be downloaded here
The error message from rkhunter
Warning: The file properties have changed:
File: /usr/bin/chattr
Current hash: 4703e5adba10128a0abbc036cefae73f754db142
Stored hash : 2502e2f117415f56cd64568b042a91dd3ef79b80
Current inode: 1735115 Stored inode: 1733967
Current size: 7228 Stored size: 7296
Current file modification time: 1197053992
Stored file modification time : 1189103575
Warning: The file properties have changed:
File: /usr/bin/lsattr
Current hash: c3eba9c1952ccf894f8f71b999b081fe5ad5f4de
Stored hash : 4ba9ee6cb8455509347059f7917ef7ed4bab6891
Current inode: 1735124 Stored inode: 1734372
Current size: 6000 Stored size: 6068
Current file modification time: 1197053992
Stored file modification time : 1189103575
Warning: The file properties have changed:
File: /usr/bin/perl
Current hash: 9c4d220d96fbaf9aaedbe4e034a767e8d510d7f6
Stored hash : 155faff21807a6ad3687806ba7737223cd56ac68
Current inode: 1733338 Stored inode: 1733472
Current size: 1078128 Stored size: 1078160
Current file modification time: 1196759924
Stored file modification time : 1191046830
Tags: ar, bash, chattr, Debian, gutsy gibbons, lsattr, perl, rkhunter, Ubuntu
Posted by Hans-Henry Jakobsen
