Skip to content

The End of Windows Server 2003 Support and How to Mitigate Risk If You Stay Past the Deadline

Posted: June 3rd, 2015 | Filed under: IIS & HTTP | Tags:

July 14, 2015

That date spells the end of support for Windows Server 2003. July is quickly approaching (how is it already May?!) and for many this means some extra work is in order. Microsoft has been pushing migration from Windows Server 2003 for some time now, and undoubtedly there are millions of sites that have yet to be moved.

And we aren’t pointing blame or sitting on our high horse either. We are among those who are still using Server 2003, as some of our old sites still run on Server 2003 VMs. If we had our druthers, of course we wouldn’t be on 2003, but IT can be hectic and often times other tasks take priority.

For some, July 14th won’t be a perilous drop-dead deadline. It will be a line in the sand that they’ll easily step over without much immediate penalty. While we are in the camp of urging people to migrate, we are acknowledge many will let the deadline come and go without migrating. So how will those who don’t migrate be impacted?

One major impact is that they will be without the security bulletin updates that are crucial for keeping many organizations secure. In 2013, MSFT issued 37 critical security patches. And 2014 was especially serious for major security issues (list some bad ones) for which MSFT put out patches. After July 14, those bulletin updates will be no more. But that’s not all.

The Trouble Ahead

Bye-bye Patches

The end of support means the end of security patches. This means that should a major vulnerability be found in the future- like the SSL 3.0 vulnerability or MS1305 – that Microsoft won’t be backing you up with an emergency security patch. Given the number of major vulnerabilities seen over the last year, particularly in widely and long-used pieces of code, it’s a worrying proposition to continue without Microsoft’s security patches.

Hello Breaches

When the next major vulnerability to impact all versions of Windows Server comes along and finds itself in the headlines of every tech and infosec blog, expect hackers to be out there sniffing for you. Sites that advertise (link to article on how response headers indicate your OS version) they’re running Windows Server 2003 will be guaranteed wide-open targets. It likely won’t take long after support ends for a vulnerability to emerge that leaves those still on Server 2003 in a dangerous position. For all we know, someone could have knowledge of an undisclosed vulnerability that’s waiting to be unleashed after support ends.

No More Software Updates

At this point, other software you use on Windows Server 2003 may also stop receiving updates. When MSFT ends support for an OS, many developers follow suit soon thereafter. If you have (non-proprietary) software that your organization relies on then you may find yourself no longer able to run on the latest version because it won’t be released for Server 2003.

Compliance Issues

Certain compliances or regulations may require systems to be supported from the OS to software on top of it. Running the out-of-support Server 2003 could put you in trouble with the governance bodies that regulate compliances and put your company in line for penalties. Furthermore, a lot of these security compliances (i.e. HIPAA, PCI) exist to protect customer data and the like, making it that much worse to put customers at risk with an un-supported OS.

If You’re Temporarily Staying Put

First and foremost, you should understand the risks that come with staying on Windows Server 2003. As noted, it is a perilous task that could have a range of impacts:

  • Data breaches
  • Business applications breaking/not functioning properly
  • Security compliance penalties

Hanging onto Windows Server 2003 until July 14 doesn’t necessarily spell the end of the world, but it should be understood that there are very real risks in doing so.

If you do stay on Server 2003 past  July 14, you should ensure that you have a migration plan ready to act upon — or have one that is already being put into action.


If you plan to migrate servers, but won’t make the July 14 deadline, Port80 may be able to help. Using ServerDefender VP may help mitigate certain security risks until migration is complete. Every month, a range of vulnerabilities are disclosed in Microsoft’s security bulletin. For vulnerabilities those that can impact the application layer, then ServerDefender can help to mitigate the risk of running an unsupported operating system until you migrate.

Protection While You Migrate and After

ServerDefender Web application firewall will keep your sites and web apps running on Windows Server 2003 secure from hackers looking to take advantage of the unsupported operating system. And when you complete your migration, you can take your ServerDefender license with you for improved security.

Secure Migrate Move SD
Add SD to your Windows Server 2003 to secure your sites and web applications post WS2003 end of life. With SD added, you can complete your migration from WS2003 with peace of mind. After your migration is complete, you can move SD from your WS2003 server to your new server for fresh and secure new start.


One last plea

Migrating to a newer Windows Server before July 14 has several advantages. But adding ServerDefenderVP to the mix shares two key benefits:

  1. It allows your organization to stay compliant with security regulations
  2. It assists you in controlling your security

If you have a plan in place, even if it means toeing the line on the WS2003 deadline, you will be better prepared to weather any potential security storms. If you have any questions about how this works, please feel free to reach out to, or share some general thoughts in the comments below.


No Comments »

The Problem with Signature-based Web App Security

Posted: January 29th, 2015 | Filed under: IIS & HTTP

In the real world we have the benefit of being present and able to see and analyze scenarios in real-time. In the cyber world, we rely on code and algorithms to handle millions of complex tasks every day without much real-time human intervention. Unfortunately, one of the tasks that we leave in the hands of technology is web security.

This is a problem because unlike humans, code and algorithms cannot decide what is good and bad. Not from a philosophical moral perspective (humans still struggle with that), but from a security standpoint. In order for web security tools to know if a user is doing something bad it needs to be programmed to know what specifically to look for. The way that many tools know how to detect malicious actions or activity it by using attack/threat signatures. This may make for a great business model for those who sell such products, since they can sell signature updates, etc, but it makes for a dangerous security model.

What are signatures, anyway?

So what are signature-based rules, exactly? One way to envision them are as a glossary of different threats that a security tool can reference to know whether or not it should take action against inputs. A signature is typically based on an exploit that has already occurred and has been documented. The signature details the way that the exploit works using a series of parameters to indicate the specific actions that occur during the exploit.

This model depends on matching inputs to a specific signature in order to block them. This can be likened to taking a fingerprint of someone who wants access to something and comparing it against a database of fingerprints of known criminals. This will work great for stopping frequent criminals, but will never stop the first-time offenders.

Example rule:
'Cross-site Scripting (XSS) Attack',id:'958016',tag:'OWASP_CRS/WEB_ATTACK/XSS',tag:'WASCTC/WASC-8',tag:'WASCTC/WASC-22',tag:'OWASP_TOP_10/A2',tag:'OWASP_AppSensor/IE1',tag:'PCI/6.5.1',logdata:'Matched Data: %{TX.0} found within %{MATCHED_VAR_NAME}: %{MATCHED_VAR}',severity:'2',setvar:'tx.msg=%{rule.msg}',setvar:tx.xss_score=+%{tx.critical_anomaly_score},setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},setvar:tx.%{}-OWASP_CRS/WEB_ATTACK/XSS-%{matched_var_name}=%{tx.0}"

The problem with security tools that rely on fingerprint matching is that fingerprints are unique, and the fingerprints for attacks that haven’t happened yet don’t exist. That leaves a gaping hole in these tools ability to provide security.

Good luck stopping zero-days!

Since signatures only account for what has already been seen, they don’t do anything to account for what has yet to be seen. When a new, never-before-seen, zero day comes along the tool won’t find any matches in the signature database. Only after the exploit has been observed in the wild will vendors update their signature lists and send out an update to customers, who then typically need to add the update.

Yes, protecting against the known vulnerabilities that many script kiddies will try is indeed valuable. However, the script kiddies don’t pose the same threat as a well-trained hacker or even a hacker who possesses knowledge of a zero day vulnerability. Without any protection against new or unseen attacks, signature-based tools leave a wide attack surface that needs to be accounted for another way.

Signatures Everywhere!

Many organizations use automated security scanners to find vulnerabilities in their apps, and in turn can update their WAFs with the information learned from the scanner. So if the scan finds vulnerability ABC, then the security rules for that vulnerability can be automatically for the WAF to import (this isn’t the case with every tool, but is a feature than many tools highlight). The problem is that the scanner is using heuristics to find the vulnerabilities in the first place. Herein lies the vicious circle of signature-based security and the illusion of security.


Vulnerability scan run with signature-based tool > Rules created from scan > Rules imported into security tool > New scan rules released, prompting rescan >


With this type of system in place, you’re never really achieving protection against anything other than known vulnerabilities. It’s like basing all flight security off of the do-not-fly list, but not knowing you can/should stop the person with a dangerous looking item for – at the least – a further inspection.

Another issue with this approach is the constant need to update the rules. Not only does your security depend on a rule existing, but it also depends on you updating the rules (unless rules update automatically) immediately upon release. A breach could come down to: no rules existing to stop an exploit, or you not updating the rules in a timely manner.

A different approach

There are alternative ways to approach web application security, and not all vendors are using a signature-based model. Port80 Software takes an algorithmic and behavioral-based approach that combines whitelists and blacklists and completely ditches the signature model.

The signature approach is so common that when people come to evaluate our Web application firewall, ServerDefender, they often are confused by its non-use of signatures. People often ask, “Well, if it doesn’t use signatures, then how is it providing protection?” and “How often do you update signatures? And are they free?”

There are indeed alternative ways to approach web application security, and not all vendors are using a signature-based model. Port80 Software takes an algorithmic and behavioral-based approach that combines whitelists and blacklists and completely ditches the signature model.

Curious to see what our approach is? Learn about our innovative – signature-free – approach to application security.

1 Comment »

Exploring the LogViewer in ServerDefender VP

Posted: November 15th, 2014 | Filed under: IIS & HTTP, Web and Application Security | Tags: , , , , , ,

Security You Can See

For the least few years, we have been developing ServerDefender VP, an advanced Web application firewall for IIS. One of the features that has been evolving along with ServerDefender VP is the LogViewer. This is the hub of the WAF where users can interact with and monitor malicious traffic hitting their site. Since there is so much to do within the LogViewer it sometimes becomes easy for a feature or two to be missed, so we’ve decided to explain some of the cool tricks its capable of.

What is the LogViewer?

The LogViewer is a tool that visualizes events (blocked threats and errors) that occur in your application and allows you take a variety of different actions on them with only a few clicks. When selecting an event users can see an array of data that pertains to it such as the referrer, user-agent, IP address, session ID, GET and POST data, and other critical information.

ServerDefender VP Web app firewall LogViewer

Click to enlarge.

What Can Actions Can I take on an Event?

There are several different actions that a user can take on an event in the LogViewer. The primary actions are for security settings (blocking IP addresses and creating exceptions), forensic tools (viewing all events by IP, comparing a session against IIS logs), and exporting reports.

ServerDefender VP LogViewer Actions

Click to enlarge.

Adding Exceptions

One of the key actions available to users from the LogViewer is the ability to add an exception to event, such as a false positive. Adding an exception on an event lets users specify new settings should the same event occur. This means that users can tell a blocked action to be allowed and configure new rules for the future.

ServerDefender VP Input Exception

Click to enlarge.


The LogViewer’s forensic tools enable users to gain further knowledge about an event and the session and IP behind it.

“View This Session in IIS Logs” displays the session logs with errors recorded by ServerDefender VP highlighted. This feature is useful to determine what occurred in a session prior to an error occurring and establishing the validity of an error, should there be any questions around it.

“View this IP Only” displays only the events in the LogViewer attributed to that IP address. This makes it easier to visualize the actions of a single IP address and understand its patterns, which can help users determine if the action they should take against the IP, if any.

Questions for Us? Ready to try?

The LogViewer is a powerful tool for viewing malicious traffic in your app and way to quickly react to events. If there’s anything else you’d like to learn about the LogViewer – or ServerDefender VP in general –  send us an email at or Tweet us @port80software. If you’d like to enjoy a 30-day free trial, go ahead and download now.

No Comments »

Patch Now: Schannel Vulnerability Poses Huge Threat

Posted: November 13th, 2014 | Filed under: IIS & HTTP

A critical vulnerability in Microsoft Schannel headlined the security bulletin released by Microsoft for November. The vulnerability is the latest in TLS vulnerabilities for 2014, and means that every major TLS stack has been impacted by a severe vulnerability this year alone, as reported by Ars Technica. The Schannel vulnerability is drawing comparisons to Heartbleed, as it similarly allows for remote code execution and data theft.

Needless to say, it is imperative that affected systems are patched immediately.

Microsoft Security Bulletin MS14-066 – Critical – Find & Install Patch

Secure Channel, also known as Schannel, is the standard security package used by SSL/TLS in Windows. The Schannel vulnerability impacts all versions of Windows dating back to Vista/Windows Server 2003.

After the Bash and Poodle Vulnerabilities earlier this year, we should not be surprised to see a vulnerability that has gone unpatched for an extended period of time. This vulnerability just underscores the fact that even very mature software may have serious bugs from time to time.

The complete November security bulletin can viewed here.

Looking for more details about the Schannel vulnerability (MS14-066)? Read More

No Comments »

POODLE SSL 3.0 Vulnerability: What it is and how to deal with it

Posted: October 17th, 2014 | Filed under: IIS & HTTP


from our friends at Net-Square

A Vulnerability known as POODLE, an acronym for Padding Oracle On Downgraded Legacy Encryption, is making headlines this week. The bug is a vulnerability in the design of SSL version 3.0, which is more than 15 years. However, SSL 3.0 is still widely supported, and nearly 97% of SSL servers are likely to be vulnerable to the bug, according to an October Netcraft Survey.

SSL v3.0 Vulnerable Servers


This vulnerability allows an attacker to intercept plaintext data from secure connections. Since SSLv3 has been quiet famous in the last 15 years it has put literally millions of browsers in jeopardy. As the chart above indicates, this is a vulnerability that has a sweeping impact.

How it happens?

Though users are upgrading to latest SSL versions (TLS 1.0, 1.1, 1.2), many TLS versions are backward compatible with SSL 3.0, hence when web browsers fail at connecting on these newer SSL version (i.e. TLS 1.0, 1.1, or 1.2), they may fall back to the older SSL 3.0 connection for a smooth user experience.

The other possibility is, a user is forced to step down to SSL 3.0. If an attacker has successfully performed a Man In The Middle attack MITM and causes connection failures, including the failure of TLS 1.0/1.1/1.2 connections. They can force the use of SSL 3.0 and then exploit the poodle bug in order to decrypt secure content transmitted between a server and a browser. Due to this down shift of the protocol the connection becomes vulnerable to the attack, eventually exploiting and intercepting user’s private data.

Google’s Bodo Möller, Thai Duong, and Krzysztof Kotowicz published the complete security advisory which can be found on

Possible remediation

To avoid falling prey to attackers exploiting POODLE, avoiding the use of public Wi-Fi hotspots, if user is sending valuable information (using online banking, accessing social networks via a browser, etc.), and noting this is always a risk, but the Poodle vulnerability makes it even more dangerous.

The other recommendation is disabling SSL v3 and all previous versions of the protocol in your browser settings and also on the server side will completely avoid it.  SSL v3 is 15 years old now and has been superseded by the more up-to-date and widely supported TSL protocol, supported by most modern web browsers.

DigitCert published a detailed step-by-step guide for disabling SSL 3.0.

Richard Burte also shared the command lines to disable SSL 3.0 on GitHub.

No Comments »