07.24.07
Posted in Admin hints, Linux, Open Source
at 8:53 pm
I think everybody that runs an own Linux server with the SSH daemon listening on port 22 is sooner or later annoyed by the amount of password attacks done by bots somewhere out in the Internet. What can you do against it?
Blocking via iptables ‘recent’ module
How you can do this on a Gentoo system is described in the Gentoo Wiki here. Because it blocks the connection attempt only due to the number of tries within a certain time it is a very basic solution and needs quite a lot of testing to examine the good parameters for the ‘hitcount’ and ’seconds’ arguments. You do not unintentionally want to block yourself when you only try to open several connections within a short time period. So not really the thing I recommend here.
Log parsing with sshguard
sshguard uses another approach. It parses the SSH log messages and searches for login failures. For example when you try to connect with a non-existent user sshguard catches it and creates an iptables deny rule. But also sshguard has a small design mistake. It wants you to create a sshguard chain in iptables and redirect all the traffic to the chain assuming that your default INPUT policy is ACCEPT. When it wants to block a host it runs iptables -A sshguard -s host-to-block -j DROP. In case you have your policy set to DROP you cannot configure the iptables to accept the allowed SSH traffic because else the blocking rules will not work anymore. I made a small patch to change the blocking command to insert the rule in first place of the chain. After you applied the patch you have to make sure that you setup your iptables the following way:
iptables -N sshguard
iptables -A sshguard -j ACCEPT
iptables -A INPUT -p tcp --dport ssh -j sshguard
Further you have to edit your system logger configuration file. Please read the documentation.
For all the lazy people I even made a Ebuild that also adds a second patch where you can disable the IPv6 ability of sshguard. You can find it here.
Permalink
07.09.07
Posted in Admin hints, Linux, Open Source, Xen
at 1:36 am
YES, YES, YES! Finally I made it.
Since a while I am playing with the migration functionality of a Xen domU between two Xen servers. It allows to move a virtual machine without reboot between two physical machines. But my problem was: It did not hold what it promised.
Trying all possible versions of Xen and the xen-sources in the Gentoo Portage I was able to migrate a domU but not when it was configured as SMP machine. After I found that the kernel has to include the CONFIG_HOTPLUG_CPU option, I was able to migrate the domU at least one time from one host to the other. When repeating this procedure the domU crashed with a kernel oops. By finally trying the latest Xen 3.1 version from the unofficial mescalito portage overlay with the xen-sources-2.6.18, repeated migration of a domU between the Xen servers does work now. Prerequisite is that both dom0 and domU run the 2.6.18 kernel. I am trying to run this in production now and will see how reliable it is.
I just remember that I did also remove the memory restriction from the dom0. The dom0_mem parameter in the grub configuration is optional and when omitting it the dom0 can use the unused memory for itself.
Permalink
07.07.07
Posted in Admin hints, Linux, Open Source, Xen
at 7:00 pm
For my home server I wanted to act a Xen domU as CUPS printing server. Therefore I needed access to my parallel printer connected to the Xen server. How are I/O-ports handled in Xen?
The I/O-addresses of the devices which can be found with cat /proc/ioports can be redirected from the Xen dom0. You have to enter the address range of the device you want to use in a domU in their configuration file (/etc/xen/domain-config). For my parallel port it would be:
ioports = [ '0278-027a' ]
Further I make sure that my dom0 does not access the device by removing parallel port support in the kernel configuration. When you boot then a domU kernel with parallel port and printer support it can access the device natively. Here a cut out from dmesg:
parport0: PC-style at 0x278 [PCSPP,TRISTATE]
parport0: Printer, Hewlett-Packard HP LaserJet 6P
lp0: using parport0 (polling).
In CUPS the printer is now accessible under /dev/lp0.
Unfortunately the documentation about this feature of Xen is a little bit rare. Another interesting thing is the redirection of PCI devices to a domU. Unfortunately I did not test this at my setup yet. I hope to come back to this topic later. For your creativity here some more examples from the net:
dulug.de - serielle Schnittstelle mit XEN
wiki.xensource.com - Assign hardware to DomU with PCI Backend as module
PCI Delegation in Xen
Permalink