Even if a system it
self is absolutely secure, a simple
misconfiguration can lead to a security intrusion. A lot of times, web applications come with a
default configuration that are often not changed by the system administrator.
For example, Microsoft IIS (Web Server) used to come with a sample site called
Exair. This sample site was often kept in the server by the administrator. If
the site was accessed directly multiple times, the CPU usage of the server will
shoot to 100% and the site comes to a crawl. Another example of application configuration management testing is
the failure to remove certain comments from the source code. For example, some
times developers comment on HTML files with important information while the
site is in development. If these comments are not removed before going live,
then you are giving the public full access those important information. Couple of ideas to prevent these problems are
listed below
- Only enable server modules that you use (for example, if you don't use apache's SSL module, then disable it. This limits the complexity of the server)
- Replace all default error pages with custom made error pages so no server information is given out. This can be done with an .htaccess file in Apache.
- The server should be ran with just the right amount of privileges. If you give a server too much access, then a intrusion of the web server can lead to the downfall of the entire system.
- Logging should be setup for authentication passes and failures.
Lastly, the
importance of logging should be stressed. Logging provides administrators with
various types of information. However, we must make sure that logs are secure
from attackers but viewable to the administrators. For example, logs might contain GET
information that has usernames & passwords. If an attacker somehow gets the
logs, then user information has been compromised. Logs should also be stored in a different
location rather than the server it self. A lot of times attackers use a
programmer called log zapper to
completely wipe any trace of the attack.
Logs also can be used as a denial of
service weapon. If a attacker
keeps attacking a system, and the server constantly creates logs - eventually,
the system will run out of hardrive space.
So, we must either move the logs to a different server or limit the size
of it. Lastly, and if the attacker has
not deleted the logs, we can use it to understand how we were attacked. For web
server attacks, 40x errors happen due to
a file not being found and 50x errors tells
us that the application failed for whatever reason (perhaps, the failure of a
SQL injection).
Sources:
No comments:
Post a Comment