|
|
There seems to be a belief these days that complying with the PCI standard is bound to be expensive and difficult to put in place. Actually if you have a Linux system, this doesn't have to be the case at all. However, while a Linux system is generally thought to be better for security, nevertheless, there are weaknesses to Linux that could be exploited by a potential hacker, and knowing these weaknesses and knowing how to deal with these weaknesses can be crucial to the server administrator who wants to ensure that his systems and networks are PCI complaint.
|
|
There seems to be a belief these days that complying with the PCI standard is bound to be expensive and difficult to put in place. Actually if you have a Linux system, this doesn't have to be the case at all. However, while a Linux system is generally thought to be better for security, nevertheless, there are weaknesses to Linux that could be exploited by a potential hacker, and knowing these weaknesses and knowing how to deal with these weaknesses can be crucial to the server administrator who wants to ensure that his systems and networks are PCI complaint.
Actually, with Linux security, knowing in advance what you are going to need to secure and making the right alterations in the right place can go a long way towards perfecting your security. Anyone who's worked with PCI-DSS knows that truly enhancing the effectiveness of this system lies in a complete understanding of the risk factors. Generally speaking, I would say that limiting risk factors primarily lies in the realm of limiting access. Now when I say limiting access I'm not just talking about password security, but about even small lapses in security that could be used by a potential hacker.
Limiting outgoing information:
Apache, for example, routinely gives out a lot of information that it should actually be retaining. For example, its version, the modules that it has loaded, and even your operating system. Now this is unnecessary information that a hacker or intruder could possibly use, if not to break into your system, then certainly to help in breaking into your system. Under such circumstances, you need to limit this seemingly minor risk. It's actually very simple to prevent Apache from handing out all this information. All you do is to change the server tokens directive when you configure Apache to 'server tokens prod'. Then all you do is restart Apache, and it will be a great deal more secure than it was before.
Now that was only one loop hole that we plugged. There are others. Another interesting tip that can further improve the security of your server is to disable the option “server signature” in the configuration as well. Now what this does is that it cloaks your PHP byline. You'll find that your PHP reveals its version number much as Apache does, and you need to switch off this variable in the PHP configuration. The PHP configuration is PHP.INI, and the variable that you need to change is the expose_PHP. Just turn it to off, and when you restart Apache, the change will be implemented, and the PHP version will no longer be visible.
Now the next flaw Full Story |
