When I first started out with Linux permissions were sorta hard to grasp, most likely because I never took the time to really sit down and understand them, but also because they are quite different than Windows permissions.

In Windows you can really put some detail in the ACLs, but with Linux you either need ACLs implemented or you need to understand how file permissions work. So first off, lets use the following example

# ls -l /
drwxr-xr-x  13 root root  4096 Apr 27  2007 usr
drwxr-xr-x  20 root root  4096 Oct  3 00:33 var

As you can see these are both owned by user root and group root and that the user has read, write, and execute permission permissions, while the group and others do not. So lets make a change to that to better explain permissions. So lets say we created /home/johndoe/usr and /home/johndoe/var.
Read the rest of this entry »

No I’m not excited about sudo, well I sorta am. I have run into situations where I typed a long command and forgot to type sudo. This is a huge problem when you can’t hit the home key and go to the start of the command, which happens in a lot of SSH tools.

The Fix!!!

sudo !!

Typing that will execute the last command, but it will execute it as if you had typed sudo at the beginning. This is a huge time saver.

Similar to the double bang trick is bang+asterisk. This combinations takes just the parameters from the previous command.

[user@host ~]$ ls /home
user
[user@host ~]$ cd !*
cd /home
[user@host home]$ 

Enjoy!

Update: I just thought about binding to a specific address to help prevent others from being able to ssh into a server. This is similar to changing the port except that there are a limited number of ports, you could bind to xf1er.domain.com and it would be forever before someone was able to brute force the address alone unless the DNS servers allowed zone transfers. The best solution is to probably use a dedicated IP address for ssh, one that nothing else is using and that nothing can resolve to. The reason is that say you had set ListenAddress to xf1er.domain.com if that resolves to the same IP as domain.com or www.domain.com it will still let you ssh in. It is not like setting the address for a particular site in Apache, where it will actually need to match the domain name.

Recently someone on the SoCal LinuxUsers mailing list was asking for information, a checklist or sorts on procedures to lock down your Linux box when putting it on the big bad internet. I will probably collect a lot more of these and make a real checklist, but this will get you started. Note that some of the configuration directives for OpenSSH are already set by default, I prefer to make the change in the config file anyway to ensure those things are set. You never know when an error might occur in an update and something could have been maliciously changed in the code or an accident happened.

• Install and Configure DenyHosts

  DenyHosts will add hosts to your /etc/hosts.deny file based on criteria you set and if you like it can download a file which is updated with hosts currently violating DenyHosts policies on other machines. For a lot of services you have to run them in xinetd or inetd for TCP wrappers to work, without TCP wrappers being involved in the daemon hosts.deny/hosts.allow will do nothing for you. The alternative to xinetd and inetd being involved is support for the libwrap library, which most OpenSSH packages have built in when compiled. You can check if a daemon has libwrap support by following the guide on ducea.com.

  All about Linux has a good post explaining how to use TCP wrappers to secure Linux.

Read the rest of this entry »

The first thing we need to do is create the public key. For this post we will use localmach for the local machine and remotemach for the remote machine.

Before beginning the following should be set on the remotemach in /etc/ssh/sshd_config

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile     .ssh/authorized_keys

Read the rest of this entry »