There are many security procedures and policies out there these days, and many of them overlook the simple things that can increase the security of your servers and networks in the production environment. This blog article will focus on some simple measures that are easy to implement.

Security through obscurity.

1. Don’t use descriptive DNS entries. I have seen many companies with descriptive DNS entries where there is no requirement and that can direct someone to the most critical elements of your network. Examples are, router.domain.tld, firewall.domain.tld, pptp.domain.tld. There is no requirement in DNS naming conventions and when you pick the names for these and other servers keep in mind that automated attacks may single out descriptive names like smtp.domain.tld. Sure it’s easier to remember the hosts because of the descriptive DNS entries but why take the risk when even a simple naming convention change could save you some grief. What if you used something like 01router.domain.tld, or routera.domain.tld. You get the idea.
2. Don’t run ssh, ftp, telnet, plesk, or webmin on a standard port. You run the risk of being the victim of a automated attack. Any service that listens can run on a non standard port. Of course www, smtp, and the like you should use the standard ports but most everything else can be changed to a different port, however things like network devices like routers, firewalls, and web accelerators should have their administration interface disabled or configured on a different port.
• Changing the port that sshd listens on.
• Edit the /etc/ssh/sshd_conf file and change the port to something other than 22 and make sure only protocol 2 is enabled. Make sure you uncomment PermitRootLogin yes to deny root logins, this requires users to either su to root or use sudo for superuser commands.
• To change the port for Webmin you need to login to do the following.
• Log on to Webmin
• Click on the Port and Address icon on the modules main page
• Change the port number by entering a number into the Listen on port field
• Hit the Save button to use the new settings.
• Changing the port on Plesk is not recommended by the manufacturer however you can do it.
• Edit the Apache configuration file %plesk_dir%admin/conf/httpd.conf
• Find the line Listen 8443
• Replace with Listen IP.ADDRESS:8444 or whatever port you would like to use.
• NOTE: In the case of Plesk running on Virtuozzo Virtual Environment, port changing can lead to VZPP-Plesk integration failure.
3. When using web applications change the default url to be anything but the default URL. A good example is http://www.domain.tld/mail for a webmail interface, even using mail1 will save you from an automated attack. Other examples are /stats, /awstats, /webstats, /forum, /cart, even changing /cgi-bin to something like /cgi-bin1 can be a bit of work modifying code or config files but it’s well worth it.
4. Never leave any tools installed for compiling applications this way if someone does get in they can’t build applications to run.
5. Only install packages from trusted sources. Sure it’s nice to have the latest PHP with all the bells and whistles but you could install some code that has a built in exploit if you download a package that was not hosted on a secure server.
6. Monitor installed packages daily. Add a daily cron job that counts the installed packages and compares them against a file which contains the known number of installed packages which emails you when the package count changes. Don’t forget to update the file after upgrading the system or you will get false positives
7. If you run a server that does not permit command line access make sure all the users have their shells set to something that does not give them a command prompt if they attempt to login, like /sbin/nologin and include a script in the shell environment so if someone does run a shell it emails you the server’s name and the last 5 lines of log file that tracks ssh access or logins. Sure it may be a pain to get an email every time you login, but it’s not if you catch someone login who should not be logging in with this simple method.
8. Make sure standard scripts have non standard names, a big mistake is ForMail.pl, you can easily rename this to sendmemail.pl or something so an automated attack can’t find it. This will work for things like /awstats also, you simply edit the /etc/httpd/conf.d/awstats.conf and add a 1 or something, again an automated attack can’t find it then.
9. Use a tmpfs.img to mount /tmp and /var/tmp with the noexec,nodev,nosuid flag to make global writable filespace more secure as malicious software can’t be executed and they are the most common locations that exploits are run.
   This is quite an important step so don’t leave this out. 
• Make a 300mb tmp file, you can adjust this if you need more space.

  cd /dev
  dd if=/dev/zero of=tmpfs.img bs=1024 count=300000
  mke2fs /dev/tmpfs.img

• Backup the current tmp directory contents

  cp -pR /tmp /tmp.old

• add the following line to /etc/fstab/dev/tmpfs.img /tmp ext2 loop,nosuid,noexec,nodev,noatime,rw 0 0
• Mount the new filesystem on /tmp and copy the files back, then link /var/tmp so it’s secure also.

  mount -o loop,nosuid,noexec,nodev,noatime,rw /dev/tmpfs.img /tmp
  chmod 1777 /tmp
  mount -o remount /tmp
  cp -R /tmp.old/* /tmp/
  rm -rf /var/tmp
  ln -s /tmp /var/tmp

10. Make sure all passwords are complex and changed at a minimum 30 day interval.