Polarwave's OpenBSD
Tips and Tricks for Newbies

Security and Obscurity

Security

There are many steps to securing a system, network, and so forth. Among
some of these are:

1) Keeping the system in a locked environment, protecting it physically. 2) Using a UPS along with a program that interfaces with the UPS to shut the system down gracefully, thus avoiding not only power spikes and sags, but possible data corruption. 3) Keeping good backups to protect data and minimize downtime should the system crash. 4) Having a good administrator and limiting as much as possible anyone else from having admin responsibilities with the accompanying control and permissions. 5) Keeping up with security notices and patching vulnerabilities as quickly as possible. 6) Maintaining a good firewall, pf(4) being my firewall of choice, along with running as few services as possible and still provide everything necessary for the users. 7) Chrooting users and processes such as Apache or whatever server one runs. 8) Employing strict login policies as in ssh, using rsa/dsa keys rather than cleartext logins, and not allowing root login as much as possible. 9) Using an online proxy server for anonymity. You could try tor and privoxy which can be installed from ports or packages.

Obscurity

The preceding list is certainly not comprehensive in scope, but merely suggestions for a
good starting point towards providing a secure system. There is also the ongoing debate
pertaining to utilizing obscurity, as in the suggestion to run services such as ftp, ssh, and
even Apache or one's web server of choice where applicable, on higher, non-standard ports,
thus avoiding, more often than not, the script kiddies who are always looking for a way in.
That's not to say someone with the knowledge and skills and tools can't launch a complete
port scan, but it does help not to run the aforementioned services on standard ports, at least
in my own experience. I know when you move ssh or ftp to a higher port, your security logs
will immediately become much smaller and less time consuming for you to check. After doing
just that, I got to thinking, since I have a very small amount of users, it'd be easy to script a
routine that changes the ssh network port on a regular basis and notify the users of the new
port assignment. If you use rsa/dsa keys instead of cleartext logins, the users will need their
~;/.ssh files on hand when logging in from a remote location. They'll also need their ~/.gnupg
files if you choose to encrypt the files before sending as I've outlined below. This write up
outlines how I scripted the entire routine. Here's a list of things I did to accomplish it:

1) root's crontab runs a port rotation script daily. 2) At the end of the port rotation script, rev reverses the order of the newport file, saving it to each users personal directory. /home/user/personal/`date +"%Y%m%d"`filename Naturally all paths are arbitrary depending on your system. 3) It chmods each copy to 600 and chowns it to each user. 4) The user's crontab runs shortly afterward, first running a script I call fetchaddy.sh which uses curl to access a server perl script and concatenates the home router's IP address to /home/user/personal/`date +"%Y%m%d"`filename. If you don't have access to a server on the web with cgi use, you can still send an email in your script and read the originating IP address in the email header. Afterward, each user's crontab runs a script I named dprshell.sh (acronym for "daily port rotate") which encrypts their file using gpg and their own personal gpg keys, and then either scp's the file to a remote unix shell account or else emails it to the account of their choice. Encrypting the file, another defensive layer, is not absolutely necessary, but I thought it was a good idea.

In /root/bin the ssh port rotation script looks like this:

#!/bin/sh # On the first initial run, newport is not going to exist. # You need to take whatever port is in /etc/ssh/sshd_config # and put it in newport in /root/bin/newport. After that, # you can run the script and test it out before putting it # in root's crontab. # cp -f ~/bin/newport ~/bin/oldport # # apg(1) is in /usr/ports/securty/apg and, naturally, you can # install it from packages. # # In the following command, the -E switch means to exclude, # and you can see it has excluded all letters along with 0 and 1 # to stop it from creating a number that would be below the 1024 # reserved range. apg -a 1 -M n -n 1 -m 4 -x 4 -E A-Z,a-z,0-1 > ~/bin/newport # # netstat(1) is part of the base system, so no need to install it. # netstat -f inet -a ¦sed ´s/[A-Z,a-z,*()-._]*//g´ ¦cut -c 19-23 ¦ \ sed -e ´/^ *$/d´ * ~/bin/portsused # # Following routine makes sure the value of portused is not a port # already in use. # while grep $(cat ~/bin/newport) ~/bin/portsused; do apg -a 1 -M n -n 1 -m 4 -x 4 -E A-Z,a-z,0-1 > ~/bin/newport shift done # # Following is done for security. # chmod 600 ~/bin/newport && chmod 600 ~/bin/oldport && \ chmod 600 ~/bin/portsused # # Here's where we change /etc/ssh/sshd_config to use newport. # sed -e ´s/´"$(cat ~/bin/oldport)"´/´"$(cat ~/bin/newport)"'/g´ \ /etc/ssh/sshd_config > ~/bin/sshd_config.tmp # # Once again, chmod 600 for security, but sshd_config is, by default, # chmoded to 644 in an initial install. 600 is arbitrary, up to root. # chmod 600 ~/bin/sshd_config.tmp cp -f ~/bin/sshd_config.tmp /etc/ssh/sshd_config # # Now we replace all instances of the old ssh port in /etc/pf.conf # to the new port value. # sed -e ´s/´"$(cat ~/bin/oldport)"´/´"$(cat ~/bin/newport)"´/g´ \ /etc/pf.conf > ~/bin/pf.conf.tmp # # And this one is chmoded 600 by default in a default install, so # don't skip this. # chmod 600 ~/bin/pf.conf.tmp cp -f ~/bin/pf.conf.tmp /etc/pf.conf.last cp -f ~/bin/pf.conf.tmp /etc/pf.conf # # Now we want the sshd daemon and pf to reread their config files. # kill -HUP `cat /var/run/sshd.pid` && pfctl -f /etc/pf.conf && cd # # Let the user(s) know what the new port is for remote access. rev(1) # is part of the base system, so again, no need to install anything. # It reverses the numerical value of the port, thus giving you another # layer of defense. # rev ~/bin/newport > /home/user/personal/`date +"%Y%m%d"`filename && chmod 600 /home/user/personal/`date +"%Y%m%d"`filename && \ chown username /home/user/personal/`date +"%Y%m%d"`filename

Here's the script I call fetchaddy which would go in a user's cgi-bin directory
on a web server:

#!/bin/sh echo echo echo "Content-Type: text/plain\n\n" echo "$REMOTE_ADDR"

Remember to make it executable.

Following is the command to get the info from the online script. You can
install curl(1) from ports or packages.

$ curl foo.bar.com/cgi-bin/fetchaddy 2>/dev/null ¦tail -1

As I said, if you don't have access to a server's cgi-bin, you can still email yourself
online and read the originating IP address in the message header. This is so if the
home system is on an ISP without a static IP address and they change it, you can
still find your way home. The new ssh network port wouldn't do much good if you
didn't know the IP address.

Now comes the script I call myip. You'll have to have the aforementioned curl
command in it to get your home IP address into the file that's going to be scp'd
to you. The script also uses gpg(1) to encrypt to whatever user each user on the
system is going to send the file to, does a chmod 600 to make it readable just to
that user, and uses scp(1) to send the file. As I said earlier, you can change this
script to instead attach the file to an email and send it that way.

#!/bin/sh # # Notice in the following line the double >> so it will concatenate the # IP address to the file which already has the new ssh network port rather # than overwriting it. curl foo.bar.com/cgi-bin/fetchaddy 2>/dev/null ¦tail -1 >> \ $HOME/personal/`date +"%Y%m%d"`filename gpg --encrypt -r gpgid -o $HOME/personal/`date +"%Y%m%d"`filename.gpg \ $HOME/personal/`date +"%Y%m%d"`filename chmod 600 $HOME/personal/`date +"%Y%m%d"`filename.gpg scp $HOME/personal/`date +"%Y%m%d"`filename.gpg \ username@wherever.com:.gnupg/ # # One more line of defense for the incurable paronoid. Delete the local # files if you want. # rm -f $HOME/personal/`date +"%Y%m&37;d"`filename rm -f $HOME/personal/`date +"%Y%m%d"`filename.gpg

NOTE: Anywhere in the preceding where you see `date +"%Y%m%d"` means the date
is being prepended to a file in order to keep track. If you rotated your port daily, you
would not be able to access your home box with yesterday's file, right?

One last conundrum. Most lower end routers, at least in my experience, only have a
GUI interface accessible through your browser of choice. If you don't have telnet or
(s)ftp capibility on your router, then you've got two other choices. You can setup
remote Administration on most routers. Set it up with a really strong password,
using both uppercase and lowercase letters, numbers, and any punctuation symbols
allowed, and make it at least 12 characters long, and even go as far as to copy and
paste it into the interface rather than typing it directly. Or, if you feel you've setup
your pf firewall sufficiently safely and you're only going to have the one box running
while either you're gone and need remote access, or else your other users need it,
you can run your cable straight from your network card to your modem, and, if you're
using a static IP address on your box, switch over to DHCP unless you already have
a static IP address from your ISP. At least that's the case with my ISP. Anything
connected to my cable modem has to use DHCP. As always with OpenBSD, there's an
excellent FAQ on setting up DHCP at:

Dynamic Host Configuration Protocol (DHCP)

You can restart your network either by rebooting or doing a "sh /etc/netstart"
(minus quotes).

Cheers!

Bookmark this on Delicious

No affiliation between this site and the OpenBSD project exists or is implied.

Polarwave's OpenBSD Tips and Tricks for Newbies

Security and Obscurity

Security

Obscurity

Some Suggested Security Links:

Polarwave's OpenBSD
Tips and Tricks for Newbies