07/07/2009

Information gathering and application security

The first stage of many potential attacks against your web application involves information gathering. The stage where an attacker investigates  the attack surface. There's so much information that can be gathered about your web application and its environment without much effort. Lets look at a very basic example. We'll use a Linux command shell and the telnet utility just to show you how simple and easy information gathering can be.

The first step is to run the telnet command and open up an http session on port 80. As an example we'll use the address www.yourwebapplication.com as the web applications fully qualified domain name.

alex@desktop:~$ telnet www.yourwebapplication.com 80
Trying 10.0.0.8
Connected to www.yourwebapplication.com.
Escape character is '^]'.

The command happily establishes an http session. Now we'll run the http GET command and we'll see what comes back.

GET /
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>302 Found</title>
</head><body>
<h1>Found</h1>
<p>The document has moved <a href="https://www.yourwebapplication.com/">here</a>.</p>
<hr>
<address>Apache/2.2.11 (Ubuntu) PHP/5.2.6-3ubuntu4.1 with Suhosin-Patch mod_ssl/2.2.11 OpenSSL/0.9.8g Server at www.yourwebapplication.com Port 80</address>
</body></html>
Connection closed by foreign host.

Look at all the information thats available to us. We now know that the server is running Apache, PHP, OpenSSL, and Ubuntu Linux. We even know what versions of Apache, PHP, and OpenSSL are running. We also know that everything that hits port 80 is redirected to port 443.


Are there other ways to gather this information? Absolutely but thats not the issue. This was a simple illustration to show you that less than 1 minute with a telnet utility can yield some very useful information.

A great deal of the attack surface has been exposed. Now we know that we can launch attacks against PHP, Apache, OpenSSL, or Linux. So how do you defend against this type of information gathering? The answer is simple but not necessarily easy. Obscure or remove what your web application and its environment are revealing. I'm definitely not a proponent of security by obscurity and thats not what I'm promoting here. I'm simply saying make things harder to find. Always remember that security is a process and any steps you take to make it harder for the bad guys can be circumvented. You have to continually audit, test, and implement mechanisms based on your results. Configure your environment to only return necessary information. Compile your tools from scratch after editing source code if necessary. Change the default error information that your environment is returning. You might have some debugging information enabled by default that could reveal a great deal more about your environment. Information about your back end database for instance or what framwork/s you're using.

When performing security audits against your web application take the time to investigate how much information can be gathered, as you can see sometimes it doesn't take very much skill or effort just a healthy dose of curiosity.

Posted at 12:09 AM | | Comments (0) | TrackBack (0)

Digg This | Save to del.icio.us

07/05/2009

Version control and Server administration

In my last post I wrote about tool transferability and methodology between the fields of system administration and software development. Version control is one of these tools and methodologies.  There are numerous version control tools that one can use and most of them extremely effective at what they do. My preference is Git but before going into why Git is my tool of choice I'd like to talk a little bit more about version control.

In my opinion its always a really good idea to keep configuration files under version control. To some this may seem like over kill and to others I might just be stating the obvious. Version control serves a far greater purpose than simply keeping track of changes. At some point you will want to know how and/or why your system configuration ended up the way it did. Version control helps you tell a story of how your system got from one point to the next, if done correctly version control will cover every detail of that story.

In my last post I also wrote about the value of documentation. Version control is a form of documentation. With version control the documentation happens more frequently and in smaller bursts or at least in my opinion it should. Documenting small changes can help you keep track of your thoughts and go a long way in helping you simplify your changes. Its hard to document a complex implementation.

So what is it about Git that I like so much? There's a great deal to like about Git but one of the best features Git offers is branching. Git makes it so easy to create, manage, and work with branches. I'll leave the details for my next post when I'll get into further detail and look at a real world configuration example. 

Posted at 09:40 PM | | Comments (0) | TrackBack (0)

Digg This | Save to del.icio.us

Simplifying system configuration

Have you ever inherited or walked into a Linux environment, looked at the configuration, and things look like they were seemingly just slapped together so badly that the system looks like Frankenstein. I know I have. In fact over the years I've found that systems I've administered and developed on have looked like this to some degree. I'm not saying that no thought went into these seemingly slapped together configurations, sometimes sys admins are under a great deal of pressure to just get things working that the end result is a Frankenstein type system that somehow works. I believe that so much better can be done. Having spent years in both software development and system administration I've found that there are numerous processes that either field can borrow from the other. In good software shops Frankenstein type development is not tolerated. Code is reviewed, audited, and re-factored on a regular basis. Systems are designed and built according to various proven and effective methodologies. I've found that applying a great deal of these principles to system administration can elliminate the Frankenstein effect. As a result systems run better and are far more robust. So what are some practical things that can be to reduce the Frankenstein effect?

Automation:
I'm a huge proponent of automation. It is very hard to automate a jumbled and needlessly complicated Linux environment. If done correctly automation will force you to clean up environments so that automation can be implemented easily. Take out your programming and scripting tools and begin working on task automation. Whether that may be system monitoring, editing configuration files, system cleanup, or more. Automate away as much of the mundane as possible. You'll find that keeping configuration simple enough for a script to administer will go a very long way in elliminating the Frankenstein effect. Once the mundane
is dealt with start looking at automating away the more complicated system tasks.

Documentation:
Writing documentation is an excellent way to ensure that systems are put together well. Documenting your system configuration will force you to make sense of what you've built and in the process reveal bugs and unecessary layers of cruft. In my opinion quality documentation is very much a by-product of building a quality system. It is far easier to document a well built system than a poorly built one. If you're finding it hard to document your configuration maybe you need to rethink how your system is put together. I believe that configuring your sytem in a manner that enables you to easily write good documentation significantly increases the quality of your system implementation.  Building solutions that are easy to document means keeping things simple. Building complicated solutions is far easier than Building simple solutions. I would never presume to tell you how to simplify your systems, however, I've found that in some cases writing clear, simple, and quality documentation first and then building against that documentation can be an extremely effective path forward.
 
In future posts I'll be exploring how to implement all of the above in further detail. These are just a couple of things that have helped me to better build and automate Linux solutions. There's hardly ever a one size fits all method. The key is to always do what is best and practical for you and your environment.
                                                                                                                                                       


Posted at 07:08 PM | | Comments (0) | TrackBack (0)

Digg This | Save to del.icio.us