Archive for category FreeBSD
Backup a live FreeBSD filesystem and remotely migrate to another server
Lately we’ve been all about live migrations / backups here at *.hosting. And why not? with the advent of such concepts as “self healing blade cloud environment” , we have made a point to testing / scripting live migration scenarios.
Following on our last post of backing up LVM volumes, we have decided to make a simple post for ‘dumping’ a live freebsd filesystem, compressing it mid-stream, and over the network (encrpyted through ssh of course) , before being saved as a file (or restored to a waiting live-cd mounted system).
By default in FreeBSD, it partitions your var, usr, root
Lets say, for the sake of argument, that your disk looks like this :
Filesystem Size Used Avail Capacity Mounted on /dev/sd0s1a 989M 445M 465M 49% / /dev/sd0s1f 9.7G 5.2G 3.7G 59% /usr /dev/sd0s1e 19G 1.5G 16G 9% /var
So lets dump the root partition since its the smallest :
dump -0uanL -f - /dev/sd0s1a | bzip2 | ssh user@0.0.0.0 "dd of=dump-root.bzip2"
Lets break down the options so you can fully understand what its doing :
-0 // dump level 0 = full backup
-u // update the dumpdates file after a successful dump
-a // bypass all tape length considerations; autosize
-n // notify if attention is required
-L // tell dump that it is a live filesystem for a consistent dump; it will take a snapshot
Alternatively you could dump the filesystem to a local file :
dump -0uanL -f - /dev/sd0s1a | bzip2 | dd of=/home/backups/dump-root.bzip2
If you wanted to dump from server1 and restore on server2 :
dump -0uanL -f - /dev/sd0s1a | ssh user@0.0.0.0 "restore rf -"
Again , this is a straightforward command. It is typically fast (within reason). You could script this for automated dumps/snapshots of your filesystem for full restores in a disaster scenario.
Related Links:
Migrate FreeBSD to Xen
There seems to be a lot of tutorials with respect to how you can dump/restore FreeBSD implementations. However, none of them appear to be all encompassing what is actually required from start to finish during the entire process.
The one thing that I think is lacking in proper documentation is utilizing FreeBSD in a LiveCD scenario (LiveFS) within a network capacity (necessary for migration).
We decided to write this tutorial so that people could have one place to establish all the necessary things required for this type of migration from start to finish.
In this scenario we actually migrated a FreeBSD implementation on VMWARE to XEN HVM. In the end, there were no technical problems with FreeBSD actually running after it was migrated — it ran beautifully actually.
I should note that this was tested with FreeBSD 7.2-RELEASE disc images.
Please find the guide below :
Prepare OLD Instance
1. Boot into old operating system
2. Take note of partition slices / slice names / sizes / etc
3. Reboot with FreeBSD LiveFS disc
Prepare NEW Xen
1. Boot Xen instance with FreeBSD Disc 1 ISO
2. Partition / install boot loader exactly the same slices as the old instance. To be extra careful, give your slices a bit more disc space than the old implementation.
3. Write changes & reboot with FreeBSD LiveFS disc
Establish FreeBSD LiveFS environment
You need to establish a few things to get SSH / DUMP / RESTORE to work properly on both the ”’old”’ and ”’new”’ instances
1. Boot into FreeBSD LiveFS (Fixit > livefs)
2. Create the following folders :
/etc/ssh /usr/sbin /usr/bin /root /root/.ssh
3. Copy the following files :
cp /mnt2/bin/ps /bin cp /mnt2/sbin/sysctl /sbin cp /mnt2/etc/ssh/* /etc/ssh cp /mnt2/bin/csh /bin cp /mnt2/bin/cat > /bin cp /mnt2/sbin/restore > /sbin
4. Set an IP address on both old and new instances:
new :
ifconfig eth0 10.0.0.50 netmask 255.255.255.0
old :
ifconfig eth0 10.0.0.60 netmask 255.255.255.0
5. Start sshd :
/mnt2/etc/rc.d/sshd forcestart
Start transferring slices
1. To allow for transferring of partitions properly, the /tmp partition should be mounted on the new Xen instance :
mount -t ufs /dev/ad0s1e /tmp
2. For the first partition you wish to transfer, mount the empty slice on the new xen instance :
mount -t ufs /dev/ad0s1a /mnt/ufs.1
Sometimes you have to fsck mark the filesystem clean to mount it :
fsck /dev/ad0s1a
3. On the old instance :
dump -0aLf - /dev/ad0s1a | ssh 10.0.0.50 "cd /mnt/ufs.1 && cat | restore -rf -"
That should dump/restore the slice from old > new.
Final things on the new Xen instance
Dont forget to boot the new instance in single user mode and modify ”’fstab”’ to reflect the new slice names (if applicable), as well as ”’rc.conf”’ for any hard coded interface names, etc. FreeBSD won’t boot if the right slice names / interface names aren’t present. Or at least cause problems.
You can mount the /etc slice while still in the LiveFS for the new FreeBSD instance.
Hopefully this was helpful! Obviously this has nothing to do with Xen, other than the fact that we were migrating the FreeBSD vmware instance to Xen.
You can do this on “real” machines, or from xen to vmware or anywhere. As long as the hardware is compatible.
Related Links:
ProFTPD with MySQL Authentication
Since this setup uses one FTP account to create user home directories and upload files, a compromise to this FTP user would cause the attacker to gain access to all FTP user home directories. I guess it just depends on how much you trust the DefaultRoot directive in Proftpd. I run Proftpd in its own chroot environment in addition to using DefaultRoot, so I’m used to feeling pretty safe with my Proftpd install. Anyway, here’s how I did the install/configuration
1. install proftpd-mysql from the ports with WITH_QUOTA set:
cd /usr/ports/ftp/proftpd-mysql/ env WITH_QUOTA=yes make env WITH_QUOTA=yes make install
2. Add the global proftpd user & Proftpd group to your system.
I used uid & gid 5500 simply because that’s what was used at one of the sites I was referencing (listed below).
pw groupadd -n Proftpd -g 5500 pw useradd proftpd -u 5500 -g Proftpd -s /sbin/nologin -d /dev/null -c "Proftpd User"
3. Create the mySQL database
create database proftpd; grant all on proftpd.* to 'proftpd'@'localhost' identified by 'password'
( change ‘password’ to something secret! )
4. Create the mySQL tables for the users & quota
create table proftpdUsers (
sqlUID int unsigned auto_increment not null,
userName varchar(30) not null unique,
passwd varchar(80) not null,
uid int unsigned not null unique,
gid int unsigned not null,
homedir tinytext,
shell tinytext,
primary key(sqlUID)
) ;
create table proftpdGroups (
sqlGID int unsigned auto_increment not null,
groupName varchar(30) not null unique,
gid int unsigned not null unique,
members tinytext,
primary key(sqlGID)
);
CREATE TABLE proftpdQuotaLimits (
name VARCHAR(30),
quota_type ENUM("user", "group", "class", "all") NOT NULL,
per_session ENUM("false", "true") NOT NULL,
limit_type ENUM("soft", "hard") NOT NULL,
bytes_in_avail FLOAT NOT NULL,
bytes_out_avail FLOAT NOT NULL,
bytes_xfer_avail FLOAT NOT NULL,
files_in_avail INT UNSIGNED NOT NULL,
files_out_avail INT UNSIGNED NOT NULL,
files_xfer_avail INT UNSIGNED NOT NULL
);
CREATE TABLE proftpdQuotaTallies (
name VARCHAR(30) NOT NULL,
quota_type ENUM("user", "group", "class", "all") NOT NULL,
bytes_in_used FLOAT NOT NULL,
bytes_out_used FLOAT NOT NULL,
bytes_xfer_used FLOAT NOT NULL,
files_in_used INT UNSIGNED NOT NULL,
files_out_used INT UNSIGNED NOT NULL,
files_xfer_used INT UNSIGNED NOT NULL
);
5. Add a test user to the proftpd database
(assumes /home/ftp is where you keep your ftp users. Otherwise, change the homedir location). This is certainly not a necessary step, but you should probably check to see if your configuration is working. You can delete this user later.
insert into proftpdUsers values ( 0, 'test', 'test', 5500, 5500, '/home/ftp/test', '/sbin/nologin' );
6. Set your proftpd configuration to use the mySQL authentication and quotas:
(NOTE: this is not a complete configuration file, it’s basically just the default config file with mySQL auth & quotas added, but note that the User and Group directives are the user & group we added in step 2. )
MaxInstances 30 # Set the user and group under which the server will run. User proftpd Group Proftpd # To cause every FTP user to be "jailed" (chrooted) into their home # directory, uncomment this line. DefaultRoot ~ # Normally, we want files to be overwriteable. AllowOverwrite on # Bar use of SITE CHMOD by defaultDenyAll # Log format and location LogFormat default "%t %h %a %s %m %f %b %T \"%r"\" ExtendedLog /var/log/proftpd.log ALL default SystemLog /var/log/proftpd.log ALL default TransferLog /var/log/proftpd.log ALL default # Uncomment this if you have "invalid shell" errors in your proftpd.log #RequireValidShell off # The passwords in MySQL are encrypted using CRYPT SQLAuthTypes Plaintext Crypt SQLAuthenticate users* groups* # used to connect to the database # databasename@host database_user user_password SQLConnectInfo proftpd@localhost proftpd yourdatabasepassword # Here we tell ProFTPd the names of the database columns in the "usertable" # we want it to interact with. Match the names with those in the db SQLUserInfo proftpdUsers userName passwd uid gid homedir shell # Here we tell ProFTPd the names of the database columns in the "grouptable" # we want it to interact with. Again the names match with those in the db SQLGroupInfo proftpdGroups groupName gid members # set min UID and GID - otherwise these are 999 each SQLMinID 5000 #============ # User quotas # =========== QuotaEngine on QuotaDirectoryTally on QuotaDisplayUnits Mb QuotaShowQuotas on # create a user's home directory on demand if it doesn't exist SQLHomedirOnDemand on SQLNamedQuery get-quota-limit SELECT "name, quota_type, per_session, limit_type, bytes_in_avail, bytes_out_avail, bytes_xfer_avail, files_in_avail, files_out_avail, files_xfer_avail FROM proftpdQuotaLimits WHERE name = '%{0}' AND quota_type = '%{1}'" SQLNamedQuery get-quota-tally SELECT "name, quota_type, bytes_in_used, bytes_out_used, bytes_xfer_used, files_in_used, files_out_used, files_xfer_used FROM proftpdQuotaTallies WHERE name = '%{0}' AND quota_type = '%{1}'" SQLNamedQuery update-quota-tally UPDATE "bytes_in_used = bytes_in_used + %{0}, bytes_out_used = bytes_out_used + %{1}, bytes_xfer_used = bytes_xfer_used + %{2}, files_in_used = files_in_used + %{3}, files_out_used = files_out_used + %{4}, files_xfer_used = files_xfer_used + %{5} WHERE name = '%{6}' AND quota_type = '%{7}'" proftpdQuotaTallies SQLNamedQuery insert-quota-tally INSERT "%{0}, %{1}, %{2}, %{3}, %{4}, %{5}, %{6}, %{7}" proftpdQuotaTallies QuotaLimitTable sql:/get-quota-limit QuotaTallyTable sql:/get-quota-tally/update-quota-tally/insert-quota-tally
Related Links:
Shell Script to Report On Hacking Attempts
It is always a good idea , when implementing open source firewall implementations (iptables, pf, etc), to build in as much reporting and verbosity as possible.
Having verbose reports on the state of your firewall, intrusion attempts and other information is key to ensuring the health and integrity of your network.
Somewhere along the line, we wrote a script to provide daily reports on intrusion attempts to penetrate our network — this usually happens when someone exceeds certain connection thresholds.
It may not be the most informative data, but the script can be modified to provide other important statistical information. It can also be modified to be used with other firewall implementations. I’m certain it wouldn’t be hard to convert this script to utilise iptables.
Below you will find the script itself — it can be set to run daily as a cronjob perhaps. Also note that the script tries to resolve a hostname for the IP address to at least provide some quick & easy information to the security administrators when determining coordinated attacks or attacks coming from compromised systems.
#!/bin/bash
# SDH PFCTL Daily Hack Table check
yesterday1=`date -v -1d +"%b"`
yesterday2=`date -v -1d +"%e"`
yesterday_display=`date -v -1d +"%b %d %Y"`
echo "" > /var/log/tablecheck.log
/sbin/pfctl -vvsTables > /var/log/pfctltables.log
echo "Firewall Table Audit: " $yesterday_display >> /var/log/tablecheck.log
echo -e "----------------------------------">> /var/log/tablecheck.log
echo -e "" >> /var/log/tablecheck.log
for obj0 in $(cat /var/log/pfctltables.log | grep "\-pa\-r\-" | awk -F "\t" '{printf "%s\n", $2}');
do
echo -e $obj0 "TABLE" >> /var/log/tablecheck.log
echo -e "--------------" >> /var/log/tablecheck.log
# this is because the date command outputs single digit non-aligned right, but pfctl doesnt display that way
if [ "$yesterday2" -le 9 ]
then
/sbin/pfctl -t $obj0 -Tshow -vv | grep -A 4 -B 1 "$yesterday1 $yesterday2" >> /var/log/tablecheck.log 2>&1
else
/sbin/pfctl -t $obj0 -Tshow -vv | grep -A 4 -B 1 "$yesterday1 $yesterday2" >> /var/log/tablecheck.log 2>&1
fi
if [ "$?" -eq 1 ]
then
echo -e "No values found for yesterday" >> /var/log/tablecheck.log
echo -e "" >> /var/log/tablecheck.log
else
echo -e "Hostnames :" >> /var/log/tablecheck.log
for obj1 in $(/sbin/pfctl -t $obj0 -Tshow -vv | grep -B 1 "$yesterday1 $yesterday2" | grep -v "Cleared" | grep -v "\-\-");
do
iphostnm=`/usr/bin/nslookup $obj1 | grep -A1 "Non-authoritative answer" | grep "name" | awk -F "=" '{printf "%s\n", $2}'`
if [ "$?" -eq 0 ]
then
echo -e "$obj1 / $iphostnm" >> /var/log/tablecheck.log
else
echo -e "$obj1 / No host name found" >> /var/log/tablecheck.log
fi
done
echo -e "" >> /var/log/tablecheck.log
fi
done
cat /var/log/tablecheck.log | mail -s "Firewall Table Report" you@youremail.com
Enjoy!
Related Links:
Creating a FreeBSD wireless access point
Access points are essentially wireless switches or hubs. Just like a switch or a hub, all clients communicate through the access point. FreeBSD allows us to easily create an access point with just very little configuration and just the right hardware
To set up a wireless access point using FreeBSD, you need to have a compatible wireless card. We are using a Prism 2-based chipset. For a complete list of cards that are supported, consult the man page for wi, or visit the Wireless Network Interface Section of the FreeBSD documentation site.
-
Configuring the kernel
Depending on how you wish to set up the access point will determine what options need to be added to the kernel config file. If the wireless network device is being installed on a server that is currently running as a Firewall/NAT, then we only need to compile the wireless device driver into the kernel:
# Wireless NIC cards
device wlan # 802.11 support
device an # Aironet 4500/4800 802.11 wireless NICs.
device awi # BayStack 660 and others
device wi # WaveLAN/Intersil/Symbol 802.11 wireless NICs.
device wl # Older non 802.11 Wavelan wireless NIC.
Choose the appropriate driver for your card from the list and include the wlan device, then recompile and install your kernel.
If this the wireless network device is going to be installed on a system that does not serve as a Firewall/NAT, then we would want to include the BRIDGE option, along with the appropriate wireless device driver in the kernel config file.
# Ethernet bridging support
option BRIDGE
# Wireless NIC cards
device wlan # 802.11 support
device an # Aironet 4500/4800 802.11 wireless NICs.
device awi # BayStack 660 and others
device wi # WaveLAN/Intersil/Symbol 802.11 wireless NICs.
device wl # Older non 802.11 Wavelan wireless NIC.
The bridging option will allow the wireless device to communicate with the wired ethernet interface. We must also add a couple of options to the /etc/sysctl.conf file in order to establish the bridge between the two interfaces:
net.inet.ip.forwarding=1
net.link.ether.bridge.enable=1
net.link.ether.bridge.config=wi0,fxp0
Be sure and replace fxp0 with whatever wired ethernet interface you are using with your FreeBSD installation. For information on bridging, consult the Bridging Section of the FreeBSD Handbook.
-
Configuring the Wireless Interface
The configuration of the wireless interface is fairly straightforward, we just need to add a few more options than if it were a wired ethernet interface. The following is an example of ifconfig options for a wireless interface:
ifconfig wi0 inet 10.0.0.5 netmask 255.255.255.0
ifconfig wi0 ssid My_Network channel 11 media DS/11Mbps mediaopt hostap up stationname "My Network"
Of course this can all be setup in the /etc/rc.conf file so that these settings are retained every time the system boots. From this point, your access point should be up and broadcasting. There are just a couple more options to consider
-
Post Configuration
As stated earlier, if the wireless interface is installed in a server that is functioning as a Firewall/NAT, then the bridging option is unecessary. We just need to add a couple of rules to our firewall configuration files to allow traffic to be passed from the wireless interface.
If you are using PF as your Firewall/NAT solution, simply add the following lines to your /etc/pf.conf file
pass in on wi0 from wi0:network to any keep state
pass out on wi0 from any to $wi0:network keep state
Replace wi0 with the appropriate interface name of your wireless card
If you are using IPfilter as your Firewall/NAT solution, then simply add the following lines to your /etc/ipf.rules file
pass in on wi0 from any to any keep state
pass out on wi0 from any to any keep state
Again, replace wi0 with the appropriate interface name of your wireless card.
-
Administration
Once the access point is configured and operational, we will want to see the clients that are associated with the access point. We can type the following command to get this information:
root@host# wicontrol -l
1 station:
ap[0]:
netname (SSID): [ My_Network ]
BSSID: [ 00:04:23:60:89:d9 ]
Channel: [ 11 ]
Quality/Signal/Noise [signal]: [ 0 / 51 / 0 ]
[dBm]: [ 0 / -98 / -149 ]
BSS Beacon Interval [msec]: [ 10 ]
Capinfo: [ ESS ]
Now you should have a complete functioning access point up and running. You are encouraged to read more about the wicontrol and wi commands for further information.
Related Links:
Dual Monitors in FreeBSD
To those (few) of you out there that actually use FreeBSD as a workstation (myself included) , you may have had the opportunity to utilize dual monitors.
As a Systems Administrator who is usually working on 3-4 things simultaneously , it is crucial to be able to function with enough screen space.
One of the headaches I’ve encountered is trying to get my Dual monitors working with my Ati/Radeon video card in FreeBSD. I’ve written a little tutorial to help those who may need help or are thinking of implementing a second monitor.
I found out my video driver and pci configuration by executing the following commands :
X -configure
pciconf -l
I entered the following as my xorg.conf (ATI / RADEON video driver):
Section "Files"
RgbPath "/usr/X11R6/lib/X11/rgb"
FontPath "/usr/X11R6/lib/X11/fonts/misc/"
FontPath "/usr/X11R6/lib/X11/fonts/TTF/"
FontPath "/usr/X11R6/lib/X11/fonts/Type1/"
FontPath "/usr/X11R6/lib/X11/fonts/75dpi/"
FontPath "/usr/X11R6/lib/X11/fonts/100dpi/"
FontPath "/usr/X11R6/lib/X11/fonts/local/"
EndSection
Section "Module"
Load "GLcore"
Load "i2c"
Load "bitmap"
Load "ddc"
Load "dri"
Load "extmod"
Load "freetype"
Load "glx"
Load "int10"
Load "type1"
Load "vbe"
EndSection
Section "InputDevice"
Identifier "Generic Keyboard"
Driver "kbd"
EndSection
Section "InputDevice"
Identifier "Configured Mouse"
Driver "mouse"
Option "Protocol" "auto"
Option "Device" "/dev/sysmouse"
Option "ZAxisMapping" "4 5 6 7"
EndSection
Section "Device"
Identifier "ATI Technologies, Inc. Radeon 9600 (R300 AP)"
Driver "ati"
BusID "PCI:1:0:0"
Option "MergedFB" "true" #Enable MergedFB function
Option "MonitorLayout" "TMDS, CRT" # Use LCD and CRT even if you have 2 LCD's or CRT's
Option "OverlayOnCRTC2" "true"
Option "CRT2Position" "LeftOf" #Physical location of your secondary monitor in relationship to your primary monitor.
Option "MetaModes" "1280x1024-1280x1024" #Monitor Resolutions for Primary-Secondary monitors
Option "MergedXineramaCRT2IsScreen0" "true" #determines which screen is going to be the primary screen; value can be "true" or "false
EndSection
Section "Monitor"
Identifier "Monitor gen'erico"
Option "DPMS"
HorizSync 28-64
VertRefresh 43-60
EndSection
Section "Screen"
Identifier "Default Screen"
Device "ATI Technologies, Inc. Radeon 9600 (R300 AP)"
Monitor "Monitor gen'erico"
DefaultDepth 24
SubSection "Display"
Depth 1
Modes "1280x960" "1024x768" "800x600" "640x480"
EndSubSection
SubSection "Display"
Depth 4
Modes "1280x960" "1024x768" "800x600" "640x480"
EndSubSection
SubSection "Display"
Depth 8
Modes "1280x960" "1024x768" "800x600" "640x480"
EndSubSection
SubSection "Display"
Depth 15
Modes "1280x960" "1024x768" "800x600" "640x480"
EndSubSection
SubSection "Display"
Depth 16
Modes "1280x960" "1024x768" "800x600" "640x480"
EndSubSection
SubSection "Display"
Depth 24
Modes "1280x1024" "1280x960" "1024x768" "800x600" "640x480"
Virtual 2624 1200
EndSubSection
EndSection
Section "ServerLayout"
Identifier "Default Layout"
Screen "Default Screen"
InputDevice "Generic Keyboard"
InputDevice "Configured Mouse"
EndSection
Section "DRI"
Mode 0666
EndSection
Starting KDE / Xorg initially displays two identical monitors. You need to use the “xrandr” utility to utilize the dual monitor configuration. The following script, when run after starting KDE will do this for you :
#!/bin/sh xrandr --output DVI-1 --auto --output DVI-0 --auto --left-of DVI-1
Related Links:
Optimizing the FreeBSD kernel
Often we are asked by VPS clients utilizing the FreeBSD operating system, how can they trim down the kernel in order to utilize the full memory footprint potential.
Without getting into too much detail, here are several things that we usually “omit” from the kernel options during make buildworld / buildkernel to provide for a 60-70% kernel footprint reduction in 7.1-PRERELEASE :
makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols
options MSDOSFS # MSDOS Filesystem
# Wireless NIC cards
device wlan # 802.11 support
device wlan_wep # 802.11 WEP support
device wlan_ccmp # 802.11 CCMP support
device wlan_tkip # 802.11 TKIP support
device wlan_amrr # AMRR transmit rate control algorithm
device wlan_scan_ap # 802.11 AP mode scanning
device wlan_scan_sta # 802.11 STA mode scanning
device an # Aironet 4500/4800 802.11 wireless NICs.
device ath # Atheros pci/cardbus NIC’s
device ath_hal # Atheros HAL (Hardware Access Layer)
device ath_rate_sample # SampleRate tx rate control for ath
device awi # BayStack 660 and others
device ral # Ralink Technology RT2500 wireless NICs.
device wi # WaveLAN/Intersil/Symbol 802.11 wireless NICs.
#device wl # Older non 802.11 Wavelan wireless NIC.
device ural # Ralink Technology RT2500USB wireless NICs
device rum # Ralink Technology RT2501USB wireless NICs
You can remove more ,but that should reduce your kernel size significantly. You should be able to recompile the kernel as per the FreeBSD documentation
