» Security

Popularity: 13%

Share This

The MySQL client allows specifying the database password on the command line using the following parameters:

If you are in a habit of doing this… STOP NOW!

If you are using a shell like Bash, the password is saved in the bash_history file. Should anyone into the server, they can easily get your MySQL password by viewing the history file.

Altering the command line to:

Causes MySQL to ask for the password, so that it cannot be stored in the history.

Proper security is layered. Just because one account password is hacked, doesn’t mean you should give away the keys to MySQL too!

Popularity: 16%

Share This

Spammers have now moved from email spam to blog comment spam to forum spam. I have received several complaints of dozens of daily messages posted to public forums. One enterprising spammer has been posting advertisement for his forum spamming services with links to an email address for contacting him.

If you have a low volume forum, you can subscribe to all new posts and delete as necessary. Most spams that I have seen come from a new user account. The spammer appears to be using a script to create a new forum account to post the single message and move on. Subsequent spam messages are also posted from a single use forum account. One way around this is to require admin approval on all new signups. Another option may be to require captcha and or email validation before automatically approving the new forum account. YMMV as some captcha systems can be easily circumvented.

Popularity: 83%

Share This

Good security consists of multiple layers of procedures and applications, all with the goal of keeping unauthorized users out and ensuring properly authorized users have access to only the things they should. With public internet servers and web applications this can mean things such as:

• Ensuring users create at least moderately secure passwords
• Instituting mandatory password changes on a monthly or quarterly schedule
• Regular security audits
• Firewall and firewall maintenance

Another layer not usually thought of is obscurity. If they can’t find it, they can’t exploit it. That being said, obscurity by itself isn’t very secure. It only takes one malicious user to find what has been hidden and all hell breaks loose. Multiple layers of security build upon each other more than just through addition. They add orders of magnitude more security to the system as a whole.

Most web applications support changing the default install directories. To keep prying eyes out of your data, move PHPMyAdmin into a directory with a random name. Move the admin directory for an applications like, ZenCart. If you are use these admin URLs frequently, the URL will be saved in the history of your browser and always accessible. If not a simple bookmark can help you remember.

Popularity: 11%

Share This

OSX has gone from no known virus threats on Friday morning, to two threats on Monday morning. What a weekend!

From the Symantec Anti-Virus Research Center:
OSX.Leap.A
OSX.Inqtana.A

Both are low risk viruii. OSX.Leap.A is a worm that spreads through iChat. OSX.Inqtana.A is a worm that spreads through the BlueTooth system. At this time, OSX.Inqtana.A is only a proof of concept.

Popularity: 14%

Share This

These snippets are all options in the sshd_config file, located at /etc/ssh/sshd_config on most Linux distros.

In order of increasing security

1. Dissallow SSHv1 and force SSHv2 connections
   Protocol 2

   SSHv1 is now considered unsecure.

2. Limit the number of SSH connection attempts at one time
   MaxStartups 2

   or

   MaxStartups start:rate:full

   From the sshd_config manpage

   Alternatively, random early drop can be enabled by specifying the three colon separated values "start:rate:full" (e.g., "10:30:60"). sshd will refuse connection attempts with a probability of "rate/100" (30%) if there are currently "start" (10) unauthenticated connections. The probability increases linearly and all connection attempts are refused if the number of unauthenticated connections reaches "full" (60).

   This one is good to slow up automated brute force password bots.

3. Dissallow direct root login
   Permit no root login attempts
   PermitRootLogin no

   or
   Permit root login attempts only via keys in authorized_keys file

   PermitRootLogin without-password

   This is the method I usually go for. It prevents brute-force root attempts but still allows for easy enough access. If someone has your private key, you have more problems anyway.

4. Change the port SSH listens to. If a hacker cannot find what port SSH is listening on, he cannot very easily try to brute force the password. Change the default port 22 to random non-used port number
   Port 22

   All valid users will need to adjust their SSH connections to use the new SSH port.

5. Disable all password authentication and rely solely on public key authentication
   PasswordAuthentication no

   All valid users must have a public/private key pair installed on the remote host and their local workstation or any other client that they will access the remote host with.

Make sure you load these changes by restarting the SSH server. On most Linux systems this can be accomplished with:

or

More information on each of these settings can be found in the sshd_config manpage

Popularity: 20%

Share This