Using Putty to ssh onto a Debian machine, the “home” and “end” keys don’t behave well. By default, both of these keys output a “~” character instead of moving the cursor to the beginning or end of the line.
I found the solution, it’s a simple change in Putty’s settings (Connection -> Data -> Terminal-type string). By default this is set to “xterm” but changing it to “linux” fixes the home and end keys.
I run an internet facing ssh server, so my logs are regularly full of brute-force password attacks like this:
Jan 20 02:59:21 drevil sshd[12803]: error: PAM: Authentication failure for illegal user root from 213.136.100.86
Jan 20 02:59:24 drevil sshd[12806]: error: PAM: Authentication failure for illegal user root from 213.136.100.86
Jan 20 02:59:27 drevil sshd[12816]: error: PAM: Authentication failure for illegal user root from 213.136.100.86
Jan 20 02:59:30 drevil sshd[12820]: error: PAM: Authentication failure for illegal user root from 213.136.100.86
Jan 20 02:59:34 drevil sshd[12827]: error: PAM: Authentication failure for illegal user root from 213.136.100.86
Jan 20 02:59:37 drevil sshd[12830]: error: PAM: Authentication failure for illegal user root from 213.136.100.86
Jan 20 02:59:40 drevil sshd[12833]: error: PAM: Authentication failure for illegal user root from 213.136.100.86
Jan 20 02:59:44 drevil sshd[12836]: error: PAM: Authentication failure for illegal user root from 213.136.100.86
Jan 20 02:59:47 drevil sshd[12840]: error: PAM: Authentication failure for illegal user root from 213.136.100.86
Jan 20 02:59:51 drevil sshd[12843]: error: PAM: Authentication failure for illegal user root from 213.136.100.86
There are several simple ways of reducing the chance of a break-in through this method:
1. Use strong passwords
This is an obvious place to start. The vast majority of these attacks come from automated scanning tools. These attempt to log in using passwords from a commonly used “dictionary”, so avoid simple words like “password”. Using a combination of letters, lower and upper case letters, and even symbols (!”£$%^&*) will give a password that is unlikely to be listed in a “common passwords” dictionary.
2. Restrict the users who can connect via ssh
OpenSSH has the capability to specify a “white list” of allowed users and deny all others. Simply add this line to your /etc/sshd_config and restart the sshd service:
AllowUsers dave mike sarah
This will block attempts to connect as any of the common system users (root, postfix, mysql etc), EVEN if the attacker guesses the correct password. If this list is kept as small as possible, it is much easier to verify these users have strong passwords.
3. Rate limit new ssh connections
A simple iptables script can be used to rate limit new incoming connection attempts. There are two ways of doing this, using the limit and recent iptables modules. Here’s the limit solution:
iptables -N NEW_SSH
iptables -A INPUT -p tcp –dport 22 -m state –state NEW -j NEW_SSH
iptables -A NEW_SSH -s 10.0.0.0/24 -j ACCEPT
iptables -A NEW_SSH -m limit –limit 3/min –limit-burst 3 -j ACCEPT
iptables -A NEW_SSH -j DROP
The third line ensures that connections from the internal network (in this example 10.0.0.0/24) are not subject to rate-limiting. The weakness of this approach is that while an attack is underway, ALL new ssh connections from outside are blocked. The recent module allows a slightly different approach (taken from debian administration):
iptables -N NEW_SSH
iptables -A INPUT -p tcp –dport 22 -m state –state NEW -j NEW_SSH
iptables -A NEW_SSH -s 10.0.0.0/24 -j ACCEPT
iptables -A NEW_SSH -m recent –set
iptables -A NEW_SSH -m recent –update –seconds 60 –hitcount 4 -j DROP
iptables -A NEW_SSH -j ACCEPT
This module “blacklists” IP addresses that exceed the rate limit, while still allowing other IP addresses to connect. If a connection makes it past this rate limiting, we accept it (last line).
4. Run your ssh server on a different port
The automated scanners look for ssh services on the default port (22), so if you move your sshd to a non-standard port less scanners will find you. It’s worth noting that this approach doesn’t improve security at all against a determined attacker. Personally I don’t use this technique, my SSH servers run on port 22.
I came across a really handy tool for listing the number of RAM sockets you have, and what’s currently in them all. The tool is dmidecode, and it’s installed by default on Debian Etch:
drevil:~# dmidecode -t memory
# dmidecode 2.8
SMBIOS 2.3 present.Handle 0×1000, DMI type 16, 15 bytes
Physical Memory Array
Location: System Board Or Motherboard
Use: System Memory
Error Correction Type: None
Maximum Capacity: 4 GB
Error Information Handle: Not Provided
Number Of Devices: 2Handle 0×1100, DMI type 17, 23 bytes
Memory Device
Array Handle: 0×1000
Error Information Handle: Not Provided
Total Width: 64 bits
Data Width: 64 bits
Size: 256 MB
Form Factor: DIMM
Set: None
Locator: DIMM_1
Bank Locator: Not Specified
Type: SDRAM
Type Detail: Synchronous
Speed: 333 MHz (3.0 ns)Handle 0×1101, DMI type 17, 23 bytes
Memory Device
Array Handle: 0×1000
Error Information Handle: Not Provided
Total Width: 64 bits
Data Width: 64 bits
Size: 256 MB
Form Factor: DIMM
Set: None
Locator: DIMM_2
Bank Locator: Not Specified
Type: SDRAM
Type Detail: Synchronous
Speed: 333 MHz (3.0 ns)
Thanks to MJ Ray and Stuart Langridge, hopefully this will save me getting the screwdriver out in future!
I just finished upgrading my Debian Etch fileserver from 2×200GB IDE disks to 2×500GB SATA disks. I managed to keep the server running for nearly the entire time, by failing and hot-adding disks to the RAID-1 arrays. If I had room in the case for more than two disks it would have been even easier.
Here is the configuration BEFORE:
I started the ball rolling by failing one partition from each RAID array:
mdadm –fail /dev/md0 /dev/hdc1
mdadm –fail /dev/md1 /dev/hdc2
mdadm –fail /dev/md2 /dev/hdc3
Then I powered down the server, disconnected and removed hdc and added a new 500GB SATA disk to the SATA PCI card. It booted up fine with all three RAID arrays degraded. I used fdisk to partition the new SATA disk (/dev/sda) with identical sized partitions 1 and 2, and with the third partition taking up the remainder of the disk. I set all partition types to fd (linux raid auto-detect):
Then one at a time I hot-added these partitions to the running RAID arrays. This causes a background reconstruction, so it’s worth waiting for each to finish before starting the next:
mdadm –add /dev/md0 /dev/sda1
mdadm –add /dev/md1 /dev/sda2
mdadm –add /dev/md2 /dev/sda3
When all three were completely synced (cat /proc/mdstat to see the progress), I edited /etc/mdadm/mdadm.conf to change all references from /dev/hdcx to /dev/sdax. I then re-built the initramfs so it knew how to start the arrays at boot time:
update-initramfs -k all -c -t
I then powered down the server again, removed the last IDE disk (hda) and added the second SATA disk (sdb). At this point the system is unbootable, so I started from a rescue CD (actually the Debian Etch netinst cd, starting with the “rescue” boot option). Once I got a command prompt (Alt-F2 and Alt-F3 virtual consoles), I installed grub:
mount /dev/sda1 /mnt
chroot /mnt /bin/bash
nano /boot/grub/device.map
I edited the device.map so it looked like this:
(hd0) /dev/sda
(hd1) /dev/sdb
Then installed grub on the first SATA disk:
grub-install /dev/sda
I rebooted and grub succesfully booted the server. As expected, all RAID arrays were in degraded mode. I used fdisk to re-partition the second SATA disk to match the first, then hot-added the mirrors to the RAID arrays (waiting for each re-sync to complete before starting the next):
mdadm –add /dev/md0 /dev/sdb1
mdadm –add /dev/md1 /dev/sdb2
mdadm –add /dev/md2 /dev/sdb3
Then I edited /etc/mdadm/mdadm.conf to update the partitions to (for example) sda1,sdb1. I re-build the initramfs again as above, and rebooted to test everything booted up cleanly. Also I checked /proc/mdstat after the reboot to check all arrays were fully functional.
So now the new disks are installed, but there’s no extra storage available because the ext3 partition is still set to the old size! I rebooted into single user mode, unmounted /home, then used resize2fs to expand the filesystem to use the whole partition:
e2fsck -f /dev/md2
resize2fs /dev/md2
One reboot later and voila, 455GB usable in /home.
Then I followed this guide to install grub on the second RAID disk in a bootable way.
The Debian package for Wordpress in Etch is version 2.0. Lenny (the current testing distribution) has version 2.2, which has quite a few improvements. Here’s how I installed this testing package without upsetting the rest of my stable system.
Wordpress is a php package, so it’s architecture independant and has hardly any dependencies. In fact the only dependency that can’t be satisfied from stable is libphp-phpmailer: wordpress 2.2 needs a newer version of this library than shipped with etch. It’s possible to manually download those two packages from the testing distribution and install them manually, but there’s a better way.
Add the testing distribution to your /etc/apt/sources.list so it looks like this (the first two should already be in there):
deb http://ftp.uk.debian.org/debian/ etch main contrib non-free
deb http://security.debian.org/ etch/updates main contrib non-free
deb http://ftp.uk.debian.org/debian/ testing main
Then use apt-pinning to disable the testing distribution for all packages except the ones you want. Edit the /etc/apt/preferences file (you may have to create it if it doesn’t already exist) so it looks like this:
Package: *
Pin: release a=stable
Pin-Priority: 700Package: *
Pin: release a=testing
Pin-Priority: -1Package: wordpress
Pin: release a=testing
Pin-Priority: 800Package: libphp-phpmailer
Pin: release a=testing
Pin-Priority: 800
The magic part of this is the preference of “-1″ for the testing distribution, which removes its packages from the available list. If you put a positive preference such as 500 (which is lower than the stable preference of 700), stable will still “win” for most packages but you’ll see some that aren’t in stable. The preference of 800 is assigned to the two packages we *do* want, and this makes them preferred over stable.
Now install wordpress 2.2:
apt-get update
apt-get install wordpress
If you already have wordpress 2.0 installed, “apt-get update; apt-get upgrade” will upgrade your 2.0 copy instead.
This technique can be used to cherry pick other packages from testing into a stable base system, but only if they don’t have significant dependencies (such as a newer c library version). In this case, backports.org is your friend.