Monday, 3 December 2012

Malware Prevention - Best Practices


Preventing Malware Infections
Preventing malware on your Web site is easier than you might think. And it doesn't require too much extra time, money, and resources to protect your systems. Following best practices for prevention and using the resources that you already have, you can significantly lessen the chances of having malware on your Web site.
Discuss these tips and guidelines with your developers and server administrators. Find out if and how these best practices are applied in your company. Set administrative and development policies based on these best practices as well as the recommendations of your trusted administrators.
Back up your Web server!
  • Perhaps the most significant preventive measure that you can take is actually preparing for the worst case scenario. What do you do when your Web site is infected and you can't just delete the malware? In that case, you want to make sure that you can recover everything that you use to run your Web site.
  • Maintain a redundant, up-to-date backup Web server. If your active server is infected, you can switch over to the clean backup server. Your customers will not experience any downtime while you clean the infected server.
  • If maintaining a redundant backup is cost- and resource-intensive, make sure that you have backup copies of all operating system and application software, including all patches and maintenance releases.
  • Make especially sure that you regularly back up all of the data. If any business or customer data is compromised or damaged, you can restore the data with minimal downtime for specific features – instead of taking your entire Web site offline.
Secure your Web server.
  • User access must be secure. Your administrators and developers should use strong passwords, change their passwords regularly, or use access credentials that are handed out by a trusted administrator.
  • Follow the "principle of least privileges." Know who has access to your server and make sure that only those who need access have it. Additionally, restrict user privileges person-by-person; give your administrators and developers only the privileges that they need to do their job.
  • File transfers must be encrypted. Use Secure FTP (SFTP) or Secure Copy (SCP) tools to transfer the files. FTP tools are not encrypted.
  • Practice secure application development. In your back-end code, validate user input type and eliminate security holes (known as "vulnerabilities") such as buffer overflow, SQL injection, and cross-site scripting.
  • On your customer-facing Web site, don't give away any information that your customers don't need – the information might be useful for attackers. For example, in error messages, don't show your server type or version or say that "we can't connect to the database". Don't provide specific login errors like "your password is wrong" – this message tells an attacker that an account exists with the username. 
Trust the person at the keyboard.
  • Make sure that everyone with access to your Web server understands and recognizes social engineering methods. Social engineering is convincing someone to do something or reveal confidential information, typically by impersonating a person of authority or influence. A saying goes: "it's easier to hack the person than it is to hack the machine".
  • Through social engineering, a malware attack starts without even touching your Web server. With just a little information about your company, an attacker can impersonate a company executive or external authority (such as the police or a lawyer) over the phone. If the attacker is convincing enough, the attacker might persuade a junior developer to unknowingly install or link to malware.
  • Have confidence in and trust all of the people who have access to your Web server. But regardless of your level of trust, your server should track user logins and all actions while logged in.
  • Trust and accountability are key to preventing the most direct threat – an inside job, a deliberate attack by an employee or colleague. Whether driven by personal reasons or coerced by an outsider, this person already has all of the access and privileges needed to put malware on your Web site.
  • For any changes to your Web site, have a clear sign-off process. You should also have contingency plans if critical people are not available, so that everyone knows what to do when you or your server administrator can't be reached. 
Use your Web server for one thing and one thing only: running your Web site.
  • Do not use the server to browse the Web, check your email, instant message, blog about your vacation, or send your mom photos from last week's family reunion. You have enough to worry about with attackers trying to get in – don't help them out by actively roaming the Internet.
  • Remove all unused programs from your Web server. Popular applications sometimes have known vulnerabilities that attackers can easily exploit. If a program is not being used, remove the program so that it is not a potential point of attack.
  • If possible, remove software documentation from the server and store it elsewhere. Documentation that includes application names, version numbers, and bug fixes can give attackers insight into what's on the server and how to gain access. 
Patch, patch, patch. Keep your server software, operating systems, and applications up to date.
  • Know what software is on your server. Keep a list of all operating system and application software installed on the server, including version numbers.
  • Keep all software on the server up to date and running the current versions. Newer versions often include fixes for known vulnerabilities. Vulnerability fixes close the loopholes that the hacker and malware communities know how to exploit.

0 comments: