Linux Archives - Webx Networks

Secure Shell (ssh) on Linux Servers – Beginner’s Guide


sshWikipedia defines Secure Shell as

Secure Shell (SSH) is a cryptographic network protocol for secure data communication, remote command-line login, remote command execution, and other secure network services between two networked computers that connects, via a secure channel over an insecure network, a server and a client (running SSH server and SSH client programs, respectively).

For a layman it is similar to what you see as “Command Prompt” on Windows PC or Terminal in Mac OS X. By using ssh, you can login to your server and access files and folders in your account in text format instead of graphical interface. This feature is for Advanced Users for powerful control of their web hosting account.

Most of the tasks related to web hosting can be done using cPanel or FTP. However some tasks are more conveniently done using ssh e.g. editing .htaccess file for mod_rewrite rules.

You need ssh client on your computer to login to an ssh server. There are free and commercial software available. For Windows, putty is a popular free ssh client. It does not even need to be installed. You can download putty.exe file and run it on your computer.

Putty Configuration For SSH

When you are running putty, it will ask you to enter following information of the remote server to connect to it:

Host Name (or IP Address): This is your server IP address or domain name.
Port: 22 (You may need to check with your hosting provider if this port does not work. They may have set it to a different port for security reasons).
Connection type: SSH

Click Save to save the session settings for future connections.

Click Open to make a connection to the remote server.

First time you connect, it will issue a Security Alert:

The server’s host key is not cached in the registry. You have no guarantee that the server is the computer you think it is…..

This is normal for the first time. When you click Yes and continue, it will be cached for future connections.

Enter your ssh username when prompted with login as: (this is typically your cPanel username)

Putty ssh login

Enter password. If ssh is allowed for your account, you’ll be in ssh environment and can issue linux shell commands. If it is disabled or you enter wrong password, access will be denied. Please contact support for help. When you login successfully, it will also print a line that Last login: showing you the last date/time when someone logged into this account and the IP address of the user.

If you are on Mac OS X or Linux computer, you can go to Terminal and issue a command like this ssh username@IP

Where username is your cPanel username, and IP is your server IP address. If ssh is on a different port then the command would be
ssh -pXXX username@IP
Where XXX is the ssh port.

Once you are logged in, you can issue linux shell commands. Below is a short list of important commands.

Command Meaning and description
pwd print absolute path of current working folder
cd change folder to home folder
cd public_html change folder to public_html. This is typically where your website files reside. You can replace public_html with other folder names to move around.
cd ../ Move up one folder in the folder (directory) tree.
clear clear the screen so you can enter new commands without any old output on it
rm xyz.txt remove (delete) xyz.txt file
cp xyz.txt abc.txt Copy xyz.txt file as abc.txt (for making a duplicate or backup of the file)
mv abc.txt xyz.txt Rename file abc.txt as xyz.txt
uptime Display the current time with how long the server has been up and running since last reboot
hostname Display server’s hostname
ls List all files in current folder. ‘dir’ also works as replacement command
ls *.jpg List all files with names ending in .jpg in current folder
exit Log off your shell

Website Hacked – How to secure it?


hackedThis article applies to general security of websites with emphasis on Linux cPanel based shared web hosting. These are some of the best practices that can help prevent hacking. And if the website gets hacked, some steps that should be taken to properly secure it. 

1. Update Web Applications Regularly

First thing you should do is to check vendor/developer websites for all of the web scripts/applications (e.g. WordPress, Joomla, Drupal etc.) used in your account for any updates. This includes any addon modules you may be using in any web applications. If you are using any open source web application, that may be the prime suspect. However, you must check all and keep them up to date. Search on google or security related websites for any known exploits in public knowledge for any web application in your use. For example if you are using WordPress or Joomla, you must get yourself registered in their mailing lists and update to latest stable release or whenever they release a security patch. The window of opportunity for hackers should be kept minimum. We do this for a number of websites that we maintain and they have never been hacked in 17 years.

2. Audit Files in Your Account

Once you have verified that 100% of scripts/web applications are on latest stable version, you will need to go through all files of your account and make sure none is uploaded by hackers before you audited. Remove any unattended install of any applications. For example if you installed a web app to test it out and forgot to remove it.

Go through all files in your folders and check for timestamp of file changes. There may be files in folders you would never imagine. You can use ftp or cPanel File Manager to go through all files under public_html and compare them with your local copy. [You should always maintain a local copy for this comparison as well as backup] – especially check any modified files for any code injected into it.

Typical locations for hackers to install malicious scripts is images folder or web app upload folder.

3. Strong Passwords

Make sure all passwords are mix of alpha-numeric and not any dictionary word. Just because you thought of a difficult word from dictionary does not make you safe. Reset all passwords if you are hacked, including email, database, web app logins, and any control panel. Hacker may have already scanned all your files to pick e.g. database password for future attacks.

4. MySQL Security

The MySQL database access for a web application should be through separate database users. Do not use your main account user/pass for it. Your main login should never be stored in any file in your account. If you need to access MySQL remotely, make sure you allow only your static IP for access.

5. Archive Raw Logs

In your cPanel, activate archive option of your web logs in Raw Log Manager. This will give you the opportunity to check how the hacker exploited one of the scripts. Otherwise all raw logs are cleared after generating stat reports. If you have already been hacked, it is too late now but you can archive the logs for future attacks.

6. Old Web Applications

If you have customized a web application with modifications or modules, make sure it is also latest stable. Many popular web application may be stable but one of the addon mods are exploitable, which may not be maintained any more. Avoid using them. Only use well maintained code in your account.

7. Sanitize Input Data

If you have developed some code yourself, make sure all input variables are sanitised (checked for valid data before using it). Otherwise a single line of bad code can give access to your entire account. The usual mistakes are (a) to include a file based on user input (b) passing the data as it is to database or other scripts without sanitising it. Again, make sure all input to a script is checked for valid data. All exploits are based on input data. If your site does not take any input, you are 100% safe from web exploits, i.e. if you run 100% static html site with no script whatsoever anywhere in your account.

8. PHP Scripts Security

For php scripts, any application that uses register_globals to be active has more chances of being exploitable. Avoid such applications. In latest php, register_globals are no longer active so this type of exploits are going down.

9. Email Scripts Header Injection

If you have an email script for a contact form, make sure it is safe from header injection. In essence make sure that email address, subject and other part of data that is being submitted by user does not contain line breaks. If any line break comes in, the script should block such attempts. With such header injection spammers can use your account and server to send huge spam.

10. Open Source Responsibility

Using open source free web applications is great but you have to maintain it by regular updates or you can loose all your data and site if a new exploit is released. And as a hosting account owner, it is your responsibility that you maintain such applications and keep your account protected.

If your site has been running fine for years, it does not mean there were no security holes in it. It actually means that exploit was unknown or you were lucky that no one exploited it before.

Also avoid using open source software (including any plugin/theme) that is not well maintained or has been abandoned by the developer. Another indicator would be high number of critical exploits discovered for it in the past, meaning the code base is not very secure and more exploits could be discovered in future.

11. Secure Configuration Files

If you are on a shared hosting account, for added security, change the permissions of your configuration files (having database credentials in them) to “660”. You can do that via ftp, ssh or file manager. For example via ssh: chmod 660 config.php

12. Protect Administration Sections

Again for additional security if you can block access to certain administrative sections of your site do that by giving access to only authorized IP addresses and blocking access for everyone else. Or password protect it. This can be done using .htaccess file or Password Protected Folders.

13. Uploaded Files

If there is any file upload facility in your account, make sure that only authorized users can use it. It should also have some sanity check on what type of files are allowed. This is one of the easiest entry points for hackers.

Also the uploaded file should not be accessible via web URL directly. They should be stored outside of public_html unless (a) it is only uploaded by a site admin (b) checked and validated that it does not contain malicious data.

14. URL Forwarding / Webmail

If there is any URL forwarding or Webmail facility for your site membership, make sure access is restricted. It should be allowed only with proper authorization, otherwise it could be used for spamming.

15. Test / Dev Installs

If you’re exploring something by installing a test instance of a web app, or you are in the process of developing a new app, lock it behind password or IP access right away.

16. World Write Folders Not Required

Since our linux web hosting servers come with suphp, you do not need any file or folder with world write permissions. The normal folder permissions should not exceed 755. And php/html files can be 644. CGI/perl scripts can be 755.

17. Software Piracy

If you download a commercial software or a plugin of a web app from suspicious website e.g. a commercial theme or plugin for WordPress, chances of that code already infected with malicious code are very high. Never download such files, and never install them on your website. Same is the case with any client software installed on your computer.

18. Educate Web Developers/Programmers About Security

Anyone who writes web application code, should be familiar with security. Here is a book that covers the web application security particularly on php: http://www.oreilly.com/catalog/phpsec/ we recommend it to all. It covers different aspects of vulnerabilities found today in web applications. Remember, one single line of bad code can give access to your entire account. Writing code is easy but writing secure code needs awareness. This is not a problem of PHP or server. It is lack of security awareness and education. It should be high priority in a web development project.

Let us know if you would like to add more to these tips by posting them in comments section below.

Videos not converting after mplayer / mencoder patched?


After applying the recent security patch and updating MPlayer, the videos may not be converting to flv. The videos may not be playing as well if your YouTube clone script uses mencoder to convert them to flv. We noticed that one vendor’s script uses this phrase

which needed to be changed to this

Those who are using ffmpeg for conversion need not worry.

Side Note: We noticed that ffmpeg converted a 90MB wmv file into 240MB file. But using mencoder we got 95MB flv file. mencoder seems to be a winner here.

Customer Review

“P.S. Impressive response time, thanks!”

Clayton
Back to Top

© 2018 Webx Networks.