Ident is important on IRC as some servers do not allow you to connect unless you have an ident, while others do, you find yourself with a tide (~) prefix before your username. These are sometimes banned. For example:

HM2K!HM2K@ROFL.name

#This is an example of a real user with a real ident

baduser!~asdfg@123.123.123.123

#This is an example of a possible exploited system

Generally the ident server (such as oidentd) will return the user’s username as the ident when it is requested, however on my servers, I allow some of my users to spoof their ident.

This means they can change their ident to whatever they like, regardless of their username.

To do this, you need to create the $HOME/.oidentd.conf file, with the following content:

global { reply ‘$ident’}

#Note: Where $ident is, replace with the ident you want.

I know some users find this a bit difficult or confusing, so I created a script to do it for them.

• setident.sh – A script used to set your ident

It’s works fine using the sh unix shell on FreeBSD.

If you are on my shell servers, you should be able to take advantage of this using the “setident” command.

Enjoy!

Build complete.
Don’t forget to run ‘make test’.

amber# make test
make: don’t know how to make test. Stop

It made me laugh anyway.

I no longer need the features of psyBNC and decided that there must be a better way.

At first I started looking at other, more basic BNC software, but then worked out that they work in very much the same way as psyBNC in the fact that you have to first connect to it, then tell it where to connect to.

So I thought… What about a socks5 proxy?

My BNC currently runs on my FreeBSD server, which I use for my IRC activity as it has plenty of IPs and lots of Vhosts.

mIRC can connect to an IRC Server through a Socks4, Socks5, or Proxy firewall.

In mIRC the fields the Firewall/Proxy dialogue box are as follows: Firewall Support <None|Server|DCC|Both>; Protocol <Socks4|Socks5|Proxy>; Hostname; User ID; Password; Port.

Judging by this, what I need is some kind of Socks daemon/server that has the ability to allow for a username or user id and a password.

I had a look at using OpenSSH’s Socks compatible dynamic forwarding by doing the following:

ssh -D<port> user@hostname

However, I discovered that the hostname was required, and I could not connect to any host on demand as expected.

So I decided to look at FreshPorts for Socks software, there are a few options…

• 3proxy – russian software, not a fan of this, it lacks documentation and support
• csocks – i386 only, no good on x64 machines
• nylon – seems pretty neat, tested it out, it has no options for username/password auth
• p5-Socks – a perl module, not a daemon
• proxy-connect – lacks proper maintenance
• prtunnel – poor documentation, doesn’t appear to do the task I want
• socks5 – “NEC has a funky license for this software”
• ss5 – bingo!
• tsocks – “Allow non SOCKS aware applications to use SOCKS without modification” — not what I want.

ss5 appears to be what I am looking for…

cd /usr/ports/net/ss5/ && make install clean

Based on the ss5 manual page I decided to create a ss5.conf file, which looked like this:

set SS5_SOCKS_USER hm2k
set SS5_SOCKS_PORT 33333
set SS5_SOCKS_ADDR rofl.name
set SS5_PASSWORD_FILE ~/ss5/ss5.passwd
set SS5_CONFIG_FILE ~/ss5/ss5.conf
set SS5_LOG_FILE ~/ss5/ss5.log
auth 0.0.0.0/0 – u
permit u 0.0.0.0/0 – 0.0.0.0/0 – - – - -

Once I’d done this, I tried to run it. I found that I wasn’t able to specify a config file meaning I probably wasn’t able to run this under anything other than root.

One thing I didn’t understand is that the ss5 configuration documentation say one of the variables (which the manual says to put into the config file) allows you to specify a config file. Which does not make sense!

So I decided to take a different approach, and coded my own SOCKS5 Server Script in perl…

I call it Simple Socks Server for Perl (sss.pl).

I hope someone else finds my script useful, and with any luck user feedback will drive me to develop it further.

Enjoy!

$longip(address)

Converts an IP address into a long value and vice-versa.

$longip(158.152.50.239)  returns 2660774639

$longip(2660774639)       returns 158.152.50.239

What I was originally trying to do was increase an IP by 1, but due to the octets only allowing up to 255, this became increasingly difficult to do.

What I decided to do in the end was convert the IP to a “longip” then increase it by 1, then convert the IP BACK to normal IP.

This required a way to convert an IP to and from longIP, I was told it could be done purely using shell script, here’s what I did…

I decided that shell script wasn’t powerful enough for what I wanted, and that I could do it easier in perl, this is the result:

#!/usr/bin/perl

# longip by HM2K 2008 (Updated: 17/01/08)

# Description: Converts (Short) IPs to Long Ips and visa versa.
# Usage: ./longip.pl <ip>

use warnings;
use strict;
use Socket;

sub longip {
my $input=shift;
if ($input =~ /\d+\.\d+\.\d+\.\d+/) { return ip2long($input); }
else { return long2ip($input); }
}

sub ip2long { return unpack(“l*”, pack(“l*”, unpack(“N*”, inet_aton(shift)))); }

sub long2ip { return inet_ntoa(pack(“N*”, shift)); }

print longip(shift);

Thanks for the assistance from #perlhelp (EFnet).

It’s also worth noting that cls (EFnet) created a shell script version called “ipconv.sh”, which is about 50 long lines in total (too long for such a simple task imo), however it didn’t convert how I wanted. If you ask him (or me) nicely, you may receive a copy.

Update: I also found a version of “ipconv.sh” in libconnect.

Enjoy!

server# cd /usr/ports
/usr/ports: No such file or directory.

I panicked a little bit, as I’ve not setup a freeBSD server in a while, so I tried to recall what I did last time.

I remembered that all I did last time was use “cvsup”, however…

server# cvsup
cvsup: Command not found.

Panic!

Here’s the deal… apparently the “cvsup” command is no longer used, and instead we’ve now got “csup“, which apparently is a rewrite of cvsup in C. This can be quite confusion if you were not aware of the change (like myself).

Now we know this we can log in as the “root” user, and setup the ports:

First of all, copy the example “ports-supfile” (needed for csup) to your root directory.

server# cp /usr/share/examples/cvsup/ports-supfile /root/ports-supfile

Now we run the csup command:

server# csup /root/ports-supfile
Name lookup failure for “CHANGE_THIS.FreeBSD.org”: hostname nor servname provided, or not known

Obviously there’s a problem. We need to edit the “ports-supfile” and change the host, or do we…?

server# csup
Usage: csup [options] supfile
Options:
-1 Don’t retry automatically on failure (same as “-r 0″)
-4 Force usage of IPv4 addresses
-6 Force usage of IPv6 addresses
-A addr Bind local socket to a specific address
-b base Override supfile’s “base” directory
-c collDir Subdirectory of “base” for collections (default “sup”)
-d delLimit Allow at most “delLimit” file deletions (default unlimited)
-h host Override supfile’s “host” name
-i pattern Include only files/directories matching pattern.
May be repeated for an OR operation. Default is
to include each entire collection.
-k Keep bad temporary files when fixups are required
-l lockfile Lock file during update; fail if already locked
-L n Verbosity level (0..2, default 1)
-p port Alternate server port (default 5999)
-r n Maximum retries on transient errors (default unlimited)
-s Don’t stat client files; trust the checkouts file
-v Print version and exit
-z Enable compression for all collections
-Z Disable compression for all collections

We can use the -h option of csup to supply a host override, we now just need to find a cvsup host to use. Select one that is closest to your server, for example, my server is in the UK, so I would use “cvsup.uk.FreeBSD.org”. You could also use fastest_cvsup, to find the fastest one for you.

Now we issue the command again, but now with the -h option:

server# csup -h cvsup.uk.FreeBSD.org /root/ports-supfile

And with any luck, providing your server has an internet connection the process should begin.

Note: I hate using the “vi” editor and since this system hasn’t got ports yet, I can’t install my preferred editor “nano”, once I have nano installed via ports, I would edit the ports-supfile with the selected cvsup hostname, meaning I do not have to supply one in the future when I come to update the ports.

Hope this helps somebody!

In this case I will be running FreeBSD 6.0, with bash shell, SSHd, named (bind), httpd (Apache2+PHP4), FTPd (pure-ftpd).

Note: In many cases, if you don’t wish to review the config when adding to it you can do: echo ‘<string>’ >> <file> (ie: echo ‘accounting_enable=”YES”‘ >> /etc/rc.conf)

sshd

• edit /etc/ssh/sshd_config
• Add line “Port 22″ – This is default, BUT change to another port if you want to be even more secure.
• Add line “Protocol 2″ – We don’t want protocol 1, just 2.
• Add line “LoginGraceTime 1m” – If you don’t login within 1 min, it will timeout.
• Add line “PermitRootLogin no” – You should not allow direct root login via ssh, use su.
• Add line “MaxAuthTries 3″ – If you get your login incorrect 3 times, you’re doing something wrong anyway.
• Add line “X11Forwarding no” – You don’t run Xwindows on a server muppet!
• Add line “MaxStartups 15:30:60″ – This means, after 15 concurrent unauthed connections, 30% of connections will be dropped, until it reaches a max of 60, then it’s full.

sysctl

• You can read each current setting by doing sysctl <setting> (ie: sysctl kern.securelevel)
• If you are unsure about using a setting you can use “sysctl -w <setting>” to temporary set, until you next reboot.
• edit /etc/sysctl.conf
• Add line “security.bsd.see_other_uids=0″ – We don’t want users to see each other’s processes.
• Add line “kern.securelevel=1″ – By default it is -1, you don’t need this unless you’re running Xwindows, run at least 0.
• Add line “net.inet.tcp.blackhole=2″ – This will drop ALL tcp packets that are received on a CLOSED port and not reply.
• Add line “net.inet.udp.blackhole=1″ – This will drop ALL udp packets that are received on a CLOSED port and not reply.
• Add line “kern.ipc.somaxconn=1024″ – Default is 128, this means we can have more concurrent connections. If like you me you have plenty of bandwidth, this is best, otherwise if you get attacked, you’ll reach 128 very quickly.
• Add line “net.inet.icmp.icmplim=50″ – Default is 200, you shouldn’t need this many, set it to 50 to reduce the amount of ICMPs sent back per second.
• Add line “net.inet.ip.rtexpire=2″ – Default is 3600, See the FreeBSD handbook: Denial Of Service Attacks.
• Add line “net.inet.ip.rtminexpire=2″ – Default is 10, See the FreeBSD handbook: Denial Of Service Attacks.
• Add line “net.inet.tcp.always_keepalive=1″ – This will help discover dead connections and clears them.
• Add line “net.inet.ip.random_id=1″ – This is optional, but I like the idea. It gives you random PIDs instead of sequential.

This is my “/etc/sysctl.conf”:

security.bsd.see_other_uids=0
kern.securelevel=1
net.inet.tcp.blackhole=2
net.inet.udp.blackhole=1
kern.ipc.somaxconn=1024
net.inet.icmp.icmplim=50
net.inet.ip.rtexpire=2
net.inet.ip.rtminexpire=2
net.inet.tcp.always_keepalive=1
net.inet.ip.random_id=1

rc.conf

• edit /etc/rc.conf
• Add line ‘portmap_enable=”NO”‘ – You only need this if you’re using NFS, which we’re not.
• Add line ’sendmail_enable=”NO”‘ – This will tell sendmail to only listen on the localhost, it’s not a good idea to leave a mail server open to spam on a shell server.
• Add line ‘nfs_server_enable=”NO”‘ – As above, we don’t need NFS.
• Add line ‘nfs_client_enable=”NO”‘ – Again, no NFS, not even a client.
• Add line ‘accounting_enable=”YES”‘ – This enables process accounting. (You need to do touch /var/account/acct && accton /var/account/acct).
• Add line ‘clear_tmp_enable=”YES”‘ – This will clear the “/tmp” dir at boot time.
• Add line ’syslogd_flags=”-ss”‘ – This stops syslogd from broadcasting on port 514.
• Add line ‘enable_quotas=”YES”‘ – Assuming you’re running a shell server, you want quotas enabled.
• Add line ‘check_quotas=”YES”‘ – This will help keep your users within their quotas.
• Add line ‘ntpdate_enable=”YES”‘ – This will enable ntpdate, which will keep your date/time up-to-date.
• Add line ‘update_motd=”NO”‘ – This will ensure that the FreeBSD details aren’t added to the /etc/motd on each reboot. We don’t want to broadcast this information.
• Check for ‘inetd_enable’ – Set it to NO, or add inetd_enable=”NO”, if it’s not there.
• Check for ‘named_enable’ – Okay, so running named will increase overheads, but if this is a shell box it probably makes sense to run your own dns server as IRC relies a lot on resolving hosts.
• Check for ‘log_in_vain’ – You may have set this based on what you read else where, but I recommend having this as “NO”, because it logs events on non-open ports, which could cause a ddos.

The latter half of my “/etc/rc.conf” looks like this:

inetd_enable=”NO”
linux_enable=”YES”
sshd_enable=”YES”

portmap_enable=”NO”
sendmail_enable=”NO”
nfs_server_enable=”NO”
nfs_client_enable=”NO”
accounting_enable=”YES”
clear_tmp_enable=”YES”
syslogd_flags=”-ss”
enable_quotas=”YES”
check_quotas=”YES”
ntpdate_enable=”YES”
update_motd=”NO”
named_enable=”YES”

Firewall

For a shell server, a firewall may not be required, but for many others it may be required.

• edit /etc/firewall.rules – for a shell server, you can do the following:
  • You need to allow new connections for services on the following ports: 21 (ftpd), 22 (sshd), 53 (dns), 80 (httpd).
  • If you are running any other core services, you will need to open the ports for those too. Remember, the first 1024 ports are reserved for root services.
  • If you run an IRC shell server, you should open a range (ie: 2000-4000) for your users services. (such as eggdrops and psybncs).
  • No other new connections to other ports should be allowed.
  • All other traffic is okay.
• Don’t forget to “chmod 600 /etc/firewall.rules”
• Add line ‘firewall_enable=”YES”‘ – We want a firewall enabled.
• Add line ‘firewall_logging=”YES”‘ – Logging the firewall can be useful.
• Add line ‘firewall_script=”/etc/firewall.rules”‘ – It needs to know where to find the rules. (don’t forget to touch /etc/firewall.rules)

Date and Time

You must ensure your system’s date/time is correct, otherwise SSH may fail and logs will be incorrect.

• As above, ensure you have ‘ntpdate_enable=”YES”‘ in your “rc.conf”.
• For first time use: “touch /etc/ntp.conf && echo /etc/ntp.conf >> server uk.pool.ntp.org prefer && echo /etc/ntp.conf >> driftfile /var/db/ntp.drift”
• Run: ntpdate uk.pool.ntp.org

Login.conf

Using login.conf you can create custom classes for your users giving them all sorts of limits and restrictions.

• edit /etc/login.conf
• If you change the “passwd_format” in the Default class to read “:passwd_format=blf:\”, this will give you blowfish password hashes, for better security, but you need to rebuild your login database by doing: “cap_mkdb /etc/login.conf”, and update all passwords by doing “passwd <user>” as root (check “/etc/master.passwd” all passwords will start with $2 if done correctly), don’t forget to edit /etc/auth.conf to “crypt_default=blf” also. This step isn’t required, but recommended.
• There are lots more options, you need to read the handbook for the “login.conf” file.
• Run “cap_mkdb /etc/login.conf” when you’re done to update the database.

pure-ftpd

Instructions are as follows:

• cd /usr/ports/ftp/pure-ftpd && make install
• cp /usr/local/etc/pure-ftpd.conf.sample /usr/local/etc/pure-ftpd.conf
• edit /usr/local/etc/pure-ftpd.conf (if required)
  • Change “NoAnonymous no” to yes
• /usr/local/sbin/pure-config.pl /usr/local/etc/pure-ftpd.conf
• echo ‘pureftpd_enable=”YES”‘ >> /etc/rc.conf

Apache 2

• edit /usr/local/etc/apache2/httpd.conf
• change the “ServerAdmin” line with your email address.
• change the “ServerTokens” line from “Full” to “Prod”, this means only “Apache” will be displayed.
• echo ‘httpd_enable=”YES”‘ >> /etc/rc.conf

oidentd

• echo ‘oidentd_enable=”YES”‘ >> /etc/rc.conf
• edit /usr/local/etc/oidentd.conf
• Ensure the defaults deny everything, and that root has a different reply, ie:

default {
default {
deny spoof
deny spoof_all
deny spoof_privport
deny random
deny random_numeric
deny numeric
deny hide
}
}

user root {
default {
force reply “UNKNOWN”
}
}

Note: You can add a user, if you want to allow spoof for certain users, and allow that.

Files and Permissions

• “find / -perm -2000 -ls && find / -perm -4000 -ls” – This lists binaries that everyone can currently access.
• Use “chmod a-s <file>” to remove access or “chmod o-rwx <file>” to allow just for wheel users.
• “chmod 640 /etc/crontab” – This will allow only root and wheel users to see it. Users don’t need to know what processes are started by cron.
• “chmod 600 /etc/rc.conf” – Users don’t need to access this.
• “chmod 600 /etc/sysctl.conf” – Users don’t need to access this.
• “chmod 0750 /root” – Stops non-wheel users from viewing root files.
• “chmod 640 /var/db/locate.database” – You don’t want all users to see all the files on your system.
• edit /etc/motd – Change this to say what you like.
• “touch /etc/COPYRIGHT” – This will remove the copyright info.

ToDo

• Provide an in-depth example of a firewall script
• Provide details about working with Quotas
• Provide better usage of login.conf

Additional Security

• Try checking system integrity with tripwire.
• Keep things up to date with cvsup.

Resources

• FeeBSD Security Information
• Defcon1 Security Guide
• A basic guide to securing FreeBSD (DALnet)
• Hardening FreeBSD (bsdguides.org)
• Protecting yourself with FreeBSD
• sysctl.conf Sample (Freebsdblog.org)
• Securing FreeBSD (ONlamp.com)
• FreeBSD Security HowTo (windowssecurity.com)
• tris’ FreeBSD setup info
• cPanel FreeBSD Seminar

Final notes

I’ve written this as more of a reference, i’ve more than likely missed a few things, so feel free to add your own comments.

What makes Xen so special above the rest is that it offers such a wide span of guest operating systems.

I am a big fan of CentOS so I have chosen this as my host, but Xen as a host will pretty much run on any Linux based OS, NetBSD, or even Solaris.

Just as a side note, the system I will be running this on is P4 3.0 CPU with 2GB ram.

To begin with I tried Xen 3.1 (32 bit PAE SMP) on CentOS 4, during this time I came across the following resources…

• Xen on CentOS-4
• How to Install Windows on Xen
• GettingStarted (XenSource Wiki)
• CentOS Xen Wiki Documents
• CentOS 5 Virtualization Guide
• RedHat Virtualization
• Installing Xen On CentOS 5.0 (i386)

I soon discovered that CentOS 5 had far better native support for Xen than CentOS 4.

Therefore, CentOS 5 was to be used, once installed you could simply do “yum groupinstall Virtualization”, and it would install Xen for you ready to use out of the box. More or less.

So this is great right? Xen installs on CentOS 5 via the virtualisation group pretty much hassle free, which means we have the dom0 setup.

The next step is to create a guest or DomU. There are plenty to choose from (Many Linux Distros, NetBSD, FreeBSD, OpenBSD, Solaris, and even Windows XP & 2003 Server), but we want FreeBSD. This is where the fun begins! We find the following resources:

• FreeBSD 5.3 Xen DomU Install HOWTO – Outdated (For Xen 2.2 not Xen 3.0)
• How to install FreeBSD as domU
• Status of FreeBSD xen guest
• FreeBSD as DomU/Guest HOWTO

Okay, fine no problem. Right?

Yes, until you get an error like this:

ERROR: Non PAE-kernel on PAE host.

Which effectively means that the CentOS 5 Dom0 (Host) is running a PAE kernel, yet what we’re trying to install as a domU (Guest) is a non PAE kernel.

So, what is PAE? basically it gives your system the ability to handle 4GB of RAM or more (max 64GB RAM) , if you have less than 4GB, you don’t really need it. It’s primarily a fix for x86 processors, providing they support it, 64-bit processors don’t need it.

So how do we fix this problem? I investigated and found the following resources:

• 32-bit, 64-bit, and PAE, oh my! (Xen Wiki)
• FreeBSD as domU (YUAN Jue’s Group)
• FreeBSD under Xen (xen-users mail list)
• FreeBSD/xen (rink.nu)

In conclusion there are two options:

1. Recompile the CentOS 5 dom0 (Host) with a non-PAE kernel with Xen.
2. Recompile the FreeBSD domU (Guest) with a PAE kernel.

So what are the problems?

Option 1 would mean moving away from the native kernel, meaning that each time a new update comes up the kernel would have to be rebuilt manually. Although building the kernel without PAE will decrease overheads, building the kernel manually may lose performance. Considering this is the host, it’s vital that it is stable, therefore this is lesser of an option.

Option 2 is apparently really easy to do, practially a flick of a switch, providing you understand what you are doing with FreeBSD and Xen. Unfortunately, my skills in this area are limited.

Where do we go from here?

Well, considering option 1 is the least favourable option, as it seems, the only way to go is to contact the people who know with regards to running FreeBSD as a DomU…

• Kip Macy
• YUAN Jue
• Rink Springer
• Chris Brookes

Alternativly…

• CentOS Forums
• Xen Mailing Lists
• BSD Forums

Any feedback or comments will be greatfully received.