Shared SQL 2008 Databases Available

SQL 2008 Logo For customers who have shared databases, you can now create new databases on our SQL 2008 servers. Back in November, we were the first to offer SQL 2008 hosting in conjunction with with Dell, Intel, Microsoft and the Professional Association for SQL Server so we've been looking forward to being able to roll out SQL Server 2008 into our production environment for quite some time.

To create a new SQL Server 2008 database just login to the MaximumASP Account Center, go to your database screen and choose Add New Database. You'll now be able to choose between a SQL 2005 or a SQL 2008 database.

New DNS Solution for Customer Domains

The External DNS system at MaximumASP has been replaced with a new system of hardware appliances based on the BIND nameserver software. The appliance vendor of choice for this solution is Infoblox,one of the industry's leading companies in DNS infrastructure and management as well as security for core network services.

The Infoblox DNS solution replaces our old DNS servers which were running Microsoft DNS on 64-bit Windows 2003 servers. The decision to replace this critical part of our network infrastructure was made a number of months ago following a series of DNS related outages. We were simply outgrowing the capabilities of Microsoft DNS.

BIND based software is a comfortable fit for our external DNS that offers us the performance and uptime our customers are accustomed to having. To further our commitment to performance and uptime, the decision was made to use a network appliance solution and place management of DNS with our netops department. This decision placed priority on the security of our external DNS in addition to performance.

Of the appliances considered, the Infoblox family of boxes met - and in many cases exceeded - all our needs. The solution provided the functionality we required, a flexible solution architecture, a short migration path, a knowledgeable and responsive technical support base and a thorough attention to security.

As we were wrapping up our final tests on the new system, posts all across the industry spoke of the DNS vulnerability identified by Dan Kaminsky in early July. Because the code update was already available from Infoblox when we first caught wind of the vulnerability, our solution went live with the patch in place. Now, granted, the possibility of that vulnerability affecting our external DNS was low. However, the fact that Infoblox was prepared before the public-at-large knew about the problem convinced us that we made the right choice.

Since putting the new system in production, the days of our public DNS servers needing weekly reboots and experiencing other "mini-disasters" related to server performance and software limitations, our netops now boasts DNS uptime in terms of months (soon to be years) and DNS problems have been cut down to almost nothing. In fact, this all comes to fruition without any of our Microsoft Certified engineers needing to learn a single BASH command.

Alert - Account Center Downtime

The MaximumASP Account Center will be undergoing maintenance this Wednesday night / Thursday morning from Midnight until 4am EST. The downtime is not expected to be longer than 30 minutes. Thanks for your patience.

New Feature - AntiVirus Status

For customers that are having their servers monitored by MaximumASP, you can now check the status of the Virus Scan under your device's AntiVirus page. On this page you'll find the results of the most recent full scans along with any of the files that the real-time scanning engine has cleaned up. Please note that if you are managing your own AntiVirus system or have opted out of our managed AntiVirus protection then nothing will be displayed.

AntiVirus Status

New Feature - Uploaded Files

A few of our customers have probably noticed the new Files tab in the MaximumASP Account Center. This feature will allow us to upload important documents such as contracts, Visio diagrams, VPN software or help text to your account that you can download at any time. If we haven't uploaded any files to your account you won't see this tab.

Mass SQL Injection Attacks

Recently, a Mass injection attack has started that is targeted at SQL Injection vulnerabilities within application code, with some of these attacks specifically targeted at ASP and .NET applications in particular. Some of these attacks are even fully automated and are being launched via botnets and other infected systems. The source of these attacks and the attack code being used changes so fast that it is impossible to block at the network level.

SQL Injection and Cross site scripting (XSS) attacks are nothing new. For several years now Computer Security professionals have been warning of massive attacks such as these disrupting normal business operations on the Public Internet. It looks as though this new wave of attacks and new method of infecting clients with malicious code has started.

The Security Team at MaximumASP has been watching this traffic very closely. A vast majority of these attacks have been originating from Chinese IP space or from compromised systems being controlled by Chinese attackers. Much of the data that is being injected into the databases contains links back to malicious Javascript code or links directly to Virus/Trojan code which is being hosted from other infected systems and from systems that reside in the Chinese web space.

The only way to protect your systems from attacks such as these is to correct the insecure application code that is allowing these database changes to be made. This means to validate all client side input to your applications for type, length, format and range. Client side input is defined as any piece of data that can be changed or modified by the client. This could be in the form of HTTP GET, HTTP POST, Javascript, cookies, VIEWSTATE or any other code that allows a client to input data to your web application.

Some of these recent attacks have even used Google search engines to find HTTP GET parameters that maybe vulnerable to an injection attack. After these GET parameters have been collected an automated system attempts to inject code into these parameters to determine if the application is possibly vulnerable attack. If the code is vulnerable links to malicious Javascript and virus code are injected into the database so the application’s clients become infected. This method of attack is extremely effective since your web server logs never see the attacking client until the attack takes place. Since they are using search engines such as Google to find your application’s parameters and code you never see any type of information-gathering scan taking place before the attack starts.

One way to protect yourself from the attacks described above is to use HTTP POST parameters for input instead of GET parameters. POST parameters are just as vulnerable to injection as GET parameters but the POST parameters will not be as easily found by things such as search engines or automated scans.

Microsoft provides a free security tool called URLScan that restricts the types of HTTP requests that Internet Information Services (IIS) will process. It can be installed on servers running IIS 4.0 or later. URLScan can be configured to block encoded URL’s, unwanted character sets, extremely long requests as well as many other useful features that can help protect your system from known and zero day (unknown) attack vectors. For more information or to download this Microsoft product please go to the following link:

If you do not have access to your application’s source code, you can do some research and ensure the 3rd party application you are using does not have any known existing vulnerabilities. Many 3rd party applications such as phpBB have recently been attacked and exploited. Attackers are again using search engines such as Google to find servers with these vulnerable applications installed and then launching attacks to deface or inject malicious code.

For more information on protecting yourself from Injection vulnerabilities please see the following links:

Security: Learn to help yourself

In this industry there is a growing and needed focus on security. There is always the threat of viruses, spyware, worms and hacker attacks. Many people feel that the larger companies are more vulnerable to attacks than small businesses. In truth, however, it’s often the other way around.

As a hosting company we do what we can to mitigate network intrusions. We feel it is our responsibility to offer these services as part of our base products. I used to get a kick out of companies announcing that they were now offering SPAM protection on their mail servers. Wouldn’t you do that by default? That is why MaximumASP invests in its network security using intrusion prevention systems, enterprise firewalls and virus protection. We literally block hundreds of thousands of possible attacks every hour coming into our network.

Many people think that if these tools are in place they are safe from the possible threat of being hacked. These systems simply protect the network but there is another side that many people do not think about or address. It is application security. It is important that people understand that the way an application is written must also be secure. There are many vulnerabilities on the application level that we see.

It is impossible for MaximumASP as a hosting company to throw some hardware network device up and protect from these types of attacks. The only way to prevent someone from taking advantage of these vulnerabilities is to correct the issues within the code itself.

Some developers are not aware of these risks. A SQL or Code injection, according to Wikipedia, is “a technique to introduce (or "inject") code into a computer program or system by taking advantage of the unenforced and unchecked assumptions the system makes about its inputs. The purpose of the injected code is typically to bypass or modify the originally intended functionality of the program.” The functionality most often bypassed is system security. Cross-site scripting attacks have been used most recently in phishing schemes.

Here are some tips to help you avoid the potentially disastrous effects of some of these attacks:

  1. Never trust any type of client side input. This means forms such as HTTP POST data, parameters set within a URI (HTTP GET) or cookie information.
  2. Always filter all un-needed characters from all client side input. This is especially true for any type of special characters. The following are characters that should never be allowed to pass in any client side input:
    • | (pipe sign)
    • & (ampersand sign)
    • ; (semicolon sign)
    • $ (dollar sign)
    • % (percent sign)
    • @ (at sign)
    • ' (single apostrophe)
    • " (quotation mark)
    • \' (backslash-escaped apostrophe)
    • \" (backslash-escaped quotation mark)
    • < > (triangular parenthesis)
    • () (parenthesis)
    • + (plus sign)
    • CR (Carriage return, ASCII 0x0d)
    • LF (Line feed, ASCII 0x0a)
    • , (comma sign)
    • \ (backslash)
  3. Include the URL encoded value of all characters you are filtering. For example the ‘ (single apostrophe) is equal to %27 when url encoded. The & (ampersand sign) is equal to %26 when url encoded. The URL’or%201=1%20-- is the same as—
  4. If you are going to pass any authentication information from your client to server SSL must be used to protect your data.
  5. Session cookies values should be very long and random. If your session values are easily guessed it is possible for an attacker to guess the value and steal or alter a session.
  6. Authentication information should not be passed within a cookie. Cookies can be stolen from a client’s system and used to authenticate just like a username and password.
  7. Application Session cookies should expire on logout or after a short period of inactivity.
  8. Remove all developer notes from production code. Often developers leave comments and notes within code that could be of use to an attacker. This is fine during development of an application but before this code is viewable to the public these notes and comments should be removed.
  9. Enable custom error messages at your webserver. Custom error pages allow you to remove the default error pages that could help an attacker learn how your system works.
  10. Always protect administrative or management URL’s with authentication and SSL. Never rely on hard to guess or hidden files or directories to protect these pages.
  11. If authentication is required for a web application always require strong passwords and ensure these passwords are being stored on your system in a secure method.

Web Application vulnerabilities like SQL injection, cross-site scripting and brute force attacks are the number 1 way we see customer accounts compromised on the MaximumASP network. If you follow the simple rules above when developing your webapplication your chances of becoming compromised are greatly reduced.