login
SSH Login Timeout – Password Authentication
Feb 6th
SSH login timeouts are not very effective at preventing unauthorized login attempts. Most ssh attacks are scripted attached launched by automatic mechanisms. The scripts most likely will use dictionary based brute force attacks that insert the password very quickly. Setting the login timeout very low will most likely not prevent such scripted attacks, and will only hinder the ability for a legitimate user to login successfully within the allocated amount of time. Set the login timeout to 60 seconds; I have set it to 5 seconds and it only caused problems for actual user logins.
Sshd_config Settings Rundown
Feb 3rd
- Image via Wikipedia
First change the port you are using. Do not use port 22 on servers that have internet connectivity. This is the first port that will be checked by countless robots searching the internet for vulnerabilities. Change the port to whatever, and then use the -p option in your ssh login attemt. Then make sure root login is disabled, remove the pound symbol from the front of the option line. If you can you should definitely allow rsa key login. Once you get your encryption key setup disable password login by setting the respective line to “no”. If you cannot enable keyed logins for any reason what soever, you should enabled ip based restrictions either by iptables or by tcp wrappers. Iptables is configured with the iptables command, and the tcp wrappers are configured in /etc/hosts.allow. You can reduce the time limit for password login, but sometimes this causes problems with remote users connecting; sometimes it takes a couple of extra seconds for people to login. Make the time limit around 30 seconds. If people are still having trouble connecting check the /var/log/auth.log file for more information about the failed login attempt. Maybe the password is too complicated? Before reducing the complexity of the password implement fail2ban, which will automatically block ip addresses based on failed login attempts, therefore you can reduce the complexity of the password without substantially reducing system security.
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=e60bad9b-01fa-477c-8d93-931cacb700d4)
Detecting a Security Breach – Ubuntu and Linux Machine
Jan 25th
Detecting a security breech is sometimes as easy as logging into the machine, using ssh, and viewing the last login attempt from a completely unrecognized ip address or domain. Subsequently check your auth.log file, in /var/log, for login attempts. If you see countless failed login attempts you have been the victim of a brute from attack. In gedit, or nano you can search for “attempt” or “access”. When several failed login attempts occur a log entry saying “possible breaking attempt” is posted. The first think a hacker will do, on a Linux machine, is attempt to change the root password, which will lock down the machine completely. If they cannot change the root password, they may just try and install a backdoor to the particular user that was breached. A backdoor can be a daemon running on any port, so check with “ps aux | grep user”. Grepping the ps command will bring up all of your active processes and if any process name looks funny you have identified a concern. You can also check what ports are accepting communication (open). A backdoor can also be an installed authorized key, which will allow password-less ssh access to the system.
Ultimately if a hacker changes the root password of your machine, there is nothing you can do. You must either restore from a backup, or rebuild the entire machine. No questions asked.
Server Security – Passwordless Remote Login
Jan 24th
Based on some recent experience do not ever allow password remote login. There are two things you chould apply to your ssh server. Implement a RSA key login, and implement fail2ban. Fail2ban will modify iptables (firewall) to block the ip address of offending attempts to connect. It will do so for your apache, ssh, ftp, and other servers. It is a separate program, not a wrapper, and it monitors log files for login attempts. You set the max login attempts (fails) in the jail.conf file in /etc/fail2ban. The combination of RSA keys and fail2ban will ensure a secure and accessible system, which is a must of the system is to be open to outside internet connections.
2048 RSA Automatic SSH Login
Jun 13th
There is no reason to be hassled to enter login usernames and password when accessing a terminal via ssh. SSH has built in rsa key authentication mechanisms. First build the private and public keys:
ssh-keygen
This will create your private and public keys in the .ssh folder in your home folder. You then copy the public key to the .ssh folder on the target system. Use scp for this.
scp .ssh/id_rsa.pub 192.168.0.100:.ssh/authorized_keys2
Change the ip address of the target system accordingly. Then login to the target system and change the ssh daemons configuration file.
sudo nano /etc/ssh/sshd_config
Scroll to the password authentication line, remove the pound sign, and make sure its set to no. Also make sure the daemon uses the authorized_keys2 file as the public key reference. Save the file, exit, and reset the ssh daemon.
sudo /etc/init.d/ssh restart
Now your ssh connections will be automated, and powerfully encrypted. You can remove the id_rsa.pub key from your .ssh directory for total security. Now the public key is only on the target system, and the only way to gain access to that system is via direct login or via the private key on your remote system. You can also transfer the private key to a usb drive, and delete the id_rsa key from the .ssh directory. When connecting via ssh use the -i option to locate the key on the usb drive. For example:
ssh -i /media/drive/id_rsa 192.168.0.100
Now the entire session will only work with the usb key in the drive. Your usb drive will literally be a key, without it there is no access to the target system whatsoever. Also do not loose the usb key, otherwise the only way to access the system will be directly via a terminal.
KDE Auto User Login
Nov 29th
Setting auto user login on KDEÂ is a little different than Gnome. On KDE go to your K menu and click system settings. Then click advanced, then click Login Manager. At the bottom right is the “administrator mode” button, click it and punch in your root password. Click the convenience tab. Check the box that says “enable auto login”, bam 
