You are currently browsing the tag archive for the ‘security’ tag.
It’s foolish to use an absolute term such as securely in the context of computer security. A better title would have used the qualifier more. If you happen to be a security expert, please be so kind as to leave a comment with any tips, admonishments, etc.
I need to allow users to upload files to a web server via an SFTP client, period. I don’t want them to be able to do anything else, and I don’t want them to be able to see any files other than their own.
SSH configuration is located in the /etc/ssh/sshd_config file.
I prefer to disallow the root user from logging in remotely via ssh, change yes to no for PermitRootLogin:
I prefer to disallow using passwords when logging in remotely, so I require the use of public keys. Change yes to no for PasswordAuthentication. Before you activate the following line, make sure you’ve setup your SSH keys properly or you may lock yourself out of your server. The short answer is to generate a public/private key pair on your local machine and place the public key (typically id_rsa.pub) in the ~/.ssh/authorized_keys file on the server, then test it by logging in via ssh – you should not be prompted for a password if successful:
To allow access for these special sftp users, I change the Subsystem sftp line to be:
Subsystem sftp internal-sftp
and add the following at the very end of the config file:
Match Group sftp ChrootDirectory /home/%u PasswordAuthentication yes X11Forwarding no ForceCommand internal-sftp
The Match statement sets up a chroot jail for any user in the sftp group so that the user will only have access to their home directory. It also overrides the global rule to disallow password login so the sftp users may use the traditional means of username/password to login. It also forces them to use the sftp command instead of allowing normal shell access.
To activate these changes, restart the ssh daemon:
sudo /etc/init.d/ssh restart
When adding users, we need to ensure they’re in the sftp group so that the Match statement in sshd_config will actually match. Alternatively, you could match on some other criteria such as username. First create the sftp group:
sudo groupadd sftp
Then add a user with that group and no shell specified:
sudo adduser --shell /bin/false --ingroup sftp brian
That should take care of everything. Test the new user by attempting to login via ssh:
ssh email@example.com firstname.lastname@example.org's password: This service allows sftp connections only. Connection to 10.0.0.1 closed.
That should fail as shown above. Also test to see if you can view any directories outside of the users’s home directory:
sftp email@example.com sftp> ls /etc Couldn't stat remote file: No such file or directory Can't ls: "/etc" not found sftp>
Some additional tools to enhance security:
- shorewall firewall
- fail2ban (locks ip addresses out for a time period after N failed attempts)
- rkhunter (checks for root kits)
- chkrootkit (checks for root kits)
I prefer to not have cookies stored in my browser, but it’s impractical to not store any cookies since this would require repeatedly logging in to authenticated sites that I frequently use. A simple solution in Firefox is the following:
From the Edit menu, choose Preferences and then click the Privacy tab. You should see a dialog similar to the following one:
Check the “Accept cookies from sites” checkbox. For the “Keep until” setting, select “I close Firefox”. The latter is the key – it will erase all cookies from Firefox whenever you close the program. Of course, we don’t want to erase all the cookies, so click the “Exceptions…” button on the right and you’ll see a dialog similar to the following:
Just type the name of the web site you want to allow in the text box and click the “Allow” button, and Firefox will add it to the exception list so it won’t be deleted when you close Firefox. You can add a full URL such as http://www.MySite.com, or just the domain name MySite.com to allow cookies for any host in that domain. You an also add sites you want to disallow any cookies from by clicking the “Block” button.
I have about 30 sites that I allow Firefox to store cookies for, but this technique has helped me avoid accumulating tons of unwanted cookies in Firefox. I hope it’s helpful for you.
This is so easy, you’re gonna love it! Thanks Tyler Pedersen.
I’ve been using my laptop more frequently at wifi hotspots. Many web sites I visit encrypt traffic with SSL for authentication, but after that they send traffic in the clear which means the cookies that are used for authentication purposes are sent in the clear, so anyone with a sniffer within range of my laptop could easily intercept the traffic, steal my cookies and impersonate me on the web site. Not good! So, I went looking for a simple solution, and found a great article about using ssh for this purpose. Ya gotta love open source software
I’ll assume the following:
- You’ve used ssh before
- You have access to a remote host running sshd
Issue the following command on your local computer:
ssh -Nf firstname.lastname@example.org -D 1080
replace email@example.com with the appropriate information. Look at the man page for ssh, or read the article linked above for an explanation of the options.
The next step is to configure Firefox to use the SOCKS proxy you setup with the above command. I’m using Firefox 188.8.131.52 on Ubuntu 7.04 Linux.
Edit | Preferences | Advanced | Settings
Pulls up the following dialog:
Notice how I’ve switched from “Direct connection to the Internet” to “Manual proxy configuration”. I’ve also set the SOCKS Host to be ‘localhost’ and the port to be ’1080′.
I can now surf and have encrypted traffic between my local computer and the remote host I ssh’d to. The traffic between my remote host and the destination web site will be unencrypted, but hopefully that traffic is harder to sniff without being detected.
At this point, I tested it out and everything worked fine. I then killed my local ssh process and Firefox complained about the connection being reset, so I knew it was in fact sending data over the ssh tunnel.
The final step is optional, but if you want to avoid having the bad guys detect your DNS requests (or possibly redirect them – d’oh!), you can configure Firefox to route DNS requests through the proxy.
about:configin the Firefox address bar.
- Look for network.proxy.socks_remote_dns and set the value to true
Is that easy or what? Thanks again Tyler.