Posted: May 8th, 2012 | Filed under: IIS & HTTP, Web Security Tools
The Perceptions of Web Application Firewalls
Difficult to configure. Confusing to use. Time-consuming to manage. Set-it-and-forget-it security. These are some of the perceptions of Web application firewalls that can be, in many cases, dangerous to the security health of your organization. Like physical exercise, exercising good security practices requires effort and commitment, but at the end of the day, the benefits far outweigh the costs. This may be news to some, but a Web app firewall is not a set-it-and-forget-it security crutch. Rather, a Web app firewall is a security tool that requires dedicated use. Most importantly, the Web application firewall isn’t a sentient being, it’s a device that, like many of man’s creations, is only as good as the person or people wielding it.
A State of Mind
Security is never a feature you can outright purchase. It’s not a box you can check, or a test you can pass and be done with. This rationale applies to security whether it be for a car, a home, or your Web apps. This is a concept most people can grasp in more physical, trivial day-to-day tasks, but sometimes is lost when it comes to the Web. For example, driving to and from work is potentially very dangerous. However, if you practice, get your license, and drive with caution, while avoiding activities like speeding and texting while driving, you will -in all likelihood – be safe. No one would get into the driver’s seat of a car for the first time and expect passive safety features like a seat belt and airbag to make up for their lack of experience. The same applies to Web app firewalls; there are measures of practice that must be applied in order to achieve security, one cannot rely solely upon passive features to do all the work. Web app firewall users need to be active drivers, not passive ones. Here are some tips to help keep in an information security state of mind, and become an active Web app firewall driver.
Think in Layers
Don’t: Put up only a single obstacle to prevent vulnerability exploits.
Do: Use a Web app firewall as one layer in a multi-layered wall.
Why: Most code in applications isn’t perfect (really, none of it is, but even if it was finding legitimate paths of entry via proper authorization information is possible). This means there are flaws in it that can be exploited by attackers. However, flaws or vulnerabilities oftentimes cannot be easily fixed or recognized. Security should be thought of in layers, with each layer serving its own purpose and no layer being responsible for the entire load. Think of home security; you may have a fence, locks on your doors, and an alarm. A WAF should only constitute a single layer in a larger defense scheme.
How: A Defense in Depth strategy. This type of strategy aims to create a series of backup measures in case one layer fails, which allows each security tool to perform within its functional specifications and not put the entire job of security on one layer. This strategy can also be thought of as a funnel, with broader measures at the top leading down to the most specific security functionality at the base, in the form of a Web app firewall.
Firewall
Block traffic going to all ports other than Ports 80 and 443. This will funnel traffic into those two ports for inspection by the other layers of security behind it. Wendy Nather wrote a piece on why we still need firewalls that nicely explains their usefulness.
IDS
Detection is needed to alert a system admin if and when an intruder is recognized in the application. Being aware of an intruder’s existence inside the app allows for a potential attack to be identified before the attack has commenced. This will give a system admin time to take additional preventative measures to prevent an attack, such as blocking the IP or logging off a user account if its been taken over. This will provide a more general security detection solution that will alert when intrusions occur at the network and system levels, not specifically within an application, as an app firewall would.
IPS
An intrusion prevention system will prevent an attacker from gathering information on your app and sever. It’s essential to prevent hacker reconnaissance by obfuscating information like server type, file extensions, and application or site errors from being easily accessible to hackers. This is again a more system and network level approach.
Application firewall
Finally, your applications will require an app firewall to secure them specifically, as they are valuable centers of information with large amount of traffic going in and out. A Web app firewall can monitor, detect, and prevent malicious traffic accessing applications. With active usage, a Web app firewall will act as a powerful last line of defense for your Web apps against attacks.
Shrink Wrap Your Security
Don’t: Expect a WAF to be correctly configured for your site out of the box.
Do: Set up your Web application firewall for your specific needs.
Why: Shrink-wrapping a Web app firewall’s security to tightly fit around your specific requirements leaves less room for error. Simply using a blacklist of attack signatures is a good way to get hit by a Zero Day, and whitelisting could lead to false-positives.
How: Set app specific policies that only allow an app to be used the way it was intended. Any vulnerabilities found through penetration testing that cannot be easily remediated should have app firewall policies put in place to protect until corrections can be made to the vulnerable code. Setting some of the below policies in your Web app firewall is a good start to shrink wrapping security.
Input validation. Configuring a Web app firewall’s input validation policies will help prevent against attacks like SQL inject and cross site scripting (XSS). Platform-specific exploits can use complex URL strings to gain access to a shell or a Common Gateway Interface (CGI), from which a hacker can easily get a directory listing revealing file structure. Input sanitizing prevents harmful scripts from being injected into your app through URLs or form fields and should be enabled on an app firewall. This should be configured depending on the characters permitted and needed in each individual field.
Use different configurations. Like customizing input sanitizing, if you need to secure – for example – an Exchange server and a Joomla site, do not use the same configuration for both. Just as a house with no windows will need different security than a glass house, different Web apps will have their own security needs that should be addressed independently.
Manage file uploads. If users can upload files, only allow the file types your site uses. This means things like preventing dynamic files from being uploaded if your site only hosts images. A Web app firewall should be configured to block any attempt to upload files that your app or site does not use. Be sure to be as specific as possible by either whitelisting only what you will use, or blacklisting all file types that you cannot use.
Be weary of session hijacking. Set user sessions to timeout when idle for an extended period of time. This will help prevent a user’s session from being hijacked, leading to unauthorized access to sensitive information. Policies can also be enforced so a session can only be used on a single IP address, thus preventing an outside hacker (with a different IP) from gaining access to the legitimate users session because it is limited to one IP.
Request management. You know the areas of your site or app where sensitive data can be accessed, the types of sensitive data, and the types of files that your site is composed of. Make sure access to admin URLs are restricted and requests for sensitive files are blocked by your Web app firewall for untrusted users.
Without security measures in place, hackers will find vulnerable penetration vectors in your Web applications. Imagine your site as a bank; there are ordinary locks and alarms on the perimeter doors, but the valuable goods (money, etc.) are inside a vault. Since you know your Web applications best, it’s up to you to make sure you place locks on all the doors, and make sure you put bigger locks on the more important doors. If you’re unsure what needs to be secured, thoroughly scrutinize and pentest your site.
You’re Never Done Securing
Even after you’ve configured your Web application firewall perfectly and put in place the best security policies you can, there are dangers to be aware of. Human error, trust betrayal, and organizational challenges pose security threats that are hard to defend against, but are important to evaluate as they pertain to your organization.
Denial of Service (DoS). Made popular by its presence in the media as the attack method of choice by hacktivist groups, denial of service attacks (DoS) have become a major concern for many organizations – and rightly so. DoS attacks rely on a large number of requests to bring down a target site or app. Casual DoS attacks can be diminished through use of a Web application firewall by limiting the number of requests per second or blocking IP addresses with high request frequencies. Though if you are dealing with very serious and determined DoS attacks, you may want to perform a risk assessment and investigate cloud-scale countermeasures, which will require some organizational backing to make the necessary changes.
Zero Day. Zero Day attacks are attacks that exploit previously unknown vulnerabilities. Even if you have tested against every known exploit and have secured against them, new vulnerability exploits will arise that you will not be protected against. Any attack, even know attack types like SQL injection or cross site scripting, can become major threats if its a zero day exploit. New exploits are created every day and can be very damaging, though a Web app firewall can be used to preempt them. When purchasing a Web app firewall make sure it has a strategy for dealing with unknown exploits or a methodology for dealing with attacks that it hasn’t seen before. Even with an app firewall in place, it’s important to remember that security today doesn’t mean you won’t be vulnerable tomorrow.
Exploiting Legitimate Trust Relationships. Web app firewalls and security policies can go a long way to securing an organization, but exploitation of trust relationships – whether intentional or unintentional – are hard to defend against. Members of an organization must be intelligent and prudent about their Web use for the organization to remain secure. This means not opening attachments from unknown senders, not clicking on strange links from unknown and un-trusted people, and so on. For example, if a user unknowingly downloads a keystroke logger from an untrusted email correspondant, a hacker can simply lift credentials from the logger and gain legitimate access to an organization’s system – no SQL injection, session hijacking, or complex hacking techniques required. This example brings to light the human element of Web security; an organization is only as safe as its least secure link.
Test, Update, and Evaluate
Don’t: Have static security or perform one round of penetration testing, auditing, or use being PCI compliant as an excuse to not perform further testing.
Do: Test and audit regularly. Evolve your security plan as threats and traffic trends on your site change.
Why: Security vulnerabilities can arise after a code change, an update or through a new hacking method. Nothing is ever static; the Web is constantly changing, which means that security needs to stay current with changes that occur. New vulnerabilities are discovered all the time, even in major software companies’ code.
How: Stay current with patch and updates; people spend hours developing these for a reason. Stay informed by reading about information security trends, following #infosec on Twitter, talking to peers, and so on. Regularly pentest and audit your apps and sites. Analyze logs and learn from them to make adjustments to Web app firewall configuration.
Log. When first setting up a WAF, use a logging mode to evaluate your site’s traffic. This will give you a sense of where tighter policies may need to be set or where exceptions may need to be set.
Check for false positives. False positives are bad for business. You never want to blocking a legitimate and harmless user who accidentally mistyped a URL or input incorrect characters into a field because security policies are set too tightly. Logs should be checked regularly for errors that aren’t really errors, and exceptions should be added to policies that may be resulting in false positives.
Perform tests. Penetration testing for vulnerabilities in your code will show you what you need to protect against until new code can be deployed to fix it. Set new policies in your app firewall based on your testing.
Update and patch. Install updates as they are released. Deploy patches to secure vulnerable code; it does’t matter if the patch is out if you don’t actually apply it. If there is an update or patch available to secure a vulnerability, chances are there are people who know how to exploit it.
Web app firewalls can be a useful ally toward greater Web security for those who know how to use them properly. Whether you’re in the market for a new Web app firewall, or are already a proud owner, understanding that a Web app firewall is a tool designed to be driven is an important step toward increased Web security.
No Comments »
Posted: April 13th, 2012 | Filed under: IIS & HTTP
Utah Medicaid Data Breach
On March 30, Utah’s Medicaid health services was breached by a hacker based in Eastern Europe who stole up to 780,000 medical files – up to 280,096 of which contained social security numbers. According to Utah Department of Technology Services spokesperson, Stephanie Weiss, the breached server was “A test server and when it was put into production there was a misconfiguration. Processes were not followed and the password was very weak.”
This week Utah Governor Gary R. Herbert called for an audit of all state information security and data storage procedures – as well as the handling of the information in the recent breach. It’s unfortunate that it took an incident like this to recognize the need for thorough security audits.
Low-latency Networks for Your Home
A brief overview of the problem of network latency, and how software solutions look to remedy it.
Microsoft Patches and Internet Explorer Woes
Microsoft issued six security bulletins with new patches addressing four critical vulnerabilities. All four four of these critical bulletins were for remote code execution vulnerabilities.
Of note is a critical remote code execution vulnerability in Internet Explorer. By tricking a user to open a document in their browser, a hacker could take control of the user’s PC.
The Anatomy of a Hack
Patrick Meenan rolled out his access logs to trace the activities of a hacker who penetrated the forums at webpagetest.org.
No Comments »
Posted: April 2nd, 2012 | Filed under: IIS & HTTP
Startling Finds
Don’t think your site is receiving harmful traffic? Incapsula recently put together a report about website traffic and its legitimacy, harmfulness, and humanness. The information compiled came, “from a sample of one thousand website of Incapsula customers, with 50,000 to 100,000 monthly visitors,” their site says.
What did the report say? 51% of all website traffic was non-human. Of that 51%, 31% of traffic consisted of potentially harmful visitors, including hacking tools, scrapers, spies, and comment spammers.
That means that less your site’s traffic may be less man than machine.
So wait, you’re telling me that of the 10,000 visitors Google Analytics told me I had last month, only 5,000 of them were actual people?
No, actually, the amount Google Analytics told you is more or less accurate about the amount of human traffic, it simply doesn’t tell you about the hackers, spammers, scrapers, and spies that are visiting your site. These visitors essentially go unnoticed and are invisible unless you look for them. But how can you prepare and secure your site if you don’t even know what’s actually happening on it?
A Problem of Analytical Proportions
Now you’re probably crying, “why wouldn’t Google tell me these kind of things?!” Well, the short answer is: they can’t. When a user goes to a page on your site, their browser makes a request from your web server to send a specific page. The web server returns the page to the browser with an embedded piece of JavaScript, which is the code that runs Google Analytics. The code gathers the information from the page opened in the browser and sends it to the databases at Google. After the information is sent to Google, you can go to your Google Analytics account to access the gathered data.
The problem is that non-human traffic, like scrapers and hacking tools, are visiting your site, but they don’t run the JavaScript used to send the information from the browser to Google. Since Google Analytics runs on a separate server from your site, this script needs to send the information to the Google Analytics databases in order for a visit to be recorded.
What Can You Do?
You can keep using Google Analytics, or your preferred analytics service, but there are measures you can take make yourself more aware of what is happening on your site.
- Check log files. By manually coming through your server log files you can see all the traffic that has come to your site. It may take a little bit of time and work, but spotting bots can be done fairly easily. Things to look for:
- Suspicious user agents. Users not fetching dependencies like JavaScript or cookies are good signs of a bot.
- Rapid movement. If you notice a visitor has viewed a lot of pages in a very short period of time (i.e. 1000 pages in 10 seconds), that’s a good sign of a bot.
- Bad Requests. If your site is on ASP and you see requests for PHP, a guessing bot is probably making the illegitimate requests.
- Checking for Robots.txt requests. This is the file that bots will look for and request, by noting the number of requests you will know how many times bots were on your site.
- It’s a Trap! Setting up traps to catch bots can be done by creating invisible links on your site, which human visitors won’t be able to see or find, but bots crawling your site for links will be able to. For every time that link is hit, you will know that a bot visited your site.
- ServerDefender VP can track and show you all every request hitting your server. Real-time logs and monitoring clearly display the names of malicious visitors. Below are images of what bad traffic looks like versus legitimate traffic.
No Comments »
Posted: April 1st, 2012 | Filed under: IIS & HTTP
Microsoft's new IIS 8 Logo
The New IIS and Windows Server 8
In March, Microsoft released beta versions of its latest and much-altered Windows line-up. While most of the focus was given to Windows 8 for PCs, there is much to be seen in the new Windows Server “8” (the official title is in parentheses for the time being) and IIS 8.
We took a look at the new features in IIS 8 and Windows Server 8 beta (Download the Windows Server 8 Beta) and have put together a breakdown of some of what’s new and what’s got us excited.
What’s New
A lot has been added or changed for IIS and Windows Server 8. Microsoft’s continued efforts for cloud integration are apparent, as well as improvements in virtualization, security, and elsewhere. Here are a sampling of the changes made:
-Server virtualization. Server 8 goes “beyond virtualization” to offer features for building a private cloud, scaling and protecting workloads, while being more cost-efficient and more secure.
-Multiserver control. Now, you will be able to control multiple servers simply and easily through a single server.
-PowerShell 3.0. The newest iteration of the command-line interface provides a comprehensive management platform for servers, storage, and networks.
-Cloud service connectivity. Server 8 provided flexibility in the cloud, allowing users to build and deploy applications in the cloud or on-site.
Also…
-There is the new Metro user interface. Optimized for touch screens, tablets, and mobile devices, the Metro UI is one of the most noticeable visual changes, albeit not one of the most useful for the server edition.
What’s Exciting
Since we develop security and performance tools for IIS, our opinion of “what’s exciting” is somewhat skewed. Below we’ve highlighted some of the best new performance and security features, as well as some other exciting new aspects.
IIS
Centralized SSL Support
Previously, copying and importing SSL certificates was an inefficient process, with each certificate needing to be copied and imported individually to their respective machines.
Now, IIS 8 has Centralized SSL Certificate Support to store all SSL certificates centrally in a file server, allowing the files to be shared by other servers. This makes scaling easy, since additional servers can all share a single folder, and only this single folder will need to be updated. The ability to simply copy certificates also means you will no longer need to follow multi-step importing procedures like this.
In short: SSL certificate management is simplified into one shared location.
Dynamic IP Restrictions
Allows users to set up filters to deny access to IP addresses of potentially malicious users. Dynamic IP Restriction will automatically block potentially harmful IP addresses, making it beneficial in protecting against DoS attacks.
Microsoft highlights the following ways that dynamic IP filtering can be used:
- “Block access for IP addresses that exceed the specific number of requests
- Block access based on the number of connection attempts from an IP address during a specified time period.
- Specify the behavior when IIS blocks an IP address. Requests from malicious clients can then be aborted by the server instead of returning HTTP 403.6 responses to the client.”
Administrators can set static rules like “block requests from IP address X” or dynamic rules like “block requests from IP addresses with more than X simultaneous connections” to restrict access. There’s even a “logging only” feature that allows admins to set rules that log what would happen if the rule was in play, but do not actually block any requests.
Using IIS 8.0 Dynamic IP Address Restrictions
In short: Dynamic IP Restrictions can be set up to block potentially malicious IP addresses and can help thwart DoS attacks.
FTP Logon Attempt Restriction
This new server-level feature (meaning that the restrictions set apply to the entire server not just a single site) restricts logon attempts to the FTP server. This feature will help alleviate brute-force attacks by limiting the number of logon attempts in a specified time period, preventing malicious users or tools from running the gamut of names and passwords to gain access to your server.
When a user reaches the number of failed login attempts, the FTP connection to the client is automatically closed by the server. The client’s IP address is blocked from accessing the FTP service until the service has been restarted.
In short: FTP Logon Attempt Restrictions can help prevent brute-force attacks on your servers.
IIS CPU Throttling
IIS users have been exclaiming “Finally” since this feature was announced. CPU throttling allows admins to set the maximum amount of CPU consumption for specific application pools. When tenants are in a cloud environment, CPU throttling will help prevent a single user’s application from monopolizing CPU resources and slowing down other users. This resource management also controls resource consumption on a site level, preventing any one site from hogging the CPU’s memory.
In shared-hosting scenarios, where several tenants are on the same server, CPU monitoring will be able to see which users require more CPU resources and potentially prevent low-usage tenants from being over-billed.
- CPU Throttling
In short: With CPU throttling, admins can now monitor usage and set specific levels of CPU usage for different applications.
Improved Live Migration
Hyper-V allows for increased speed of live migrations between clustered virtual servers. This is, as Microsoft calls it, “live migration without limits.” Now, rather than requiring a shared storage location on the backend, live migration simply copies the memory pages of the migrating virtual machines to the destination prior to migration – with no perceived user downtime. Plus, admins can use up to 10 gigabytes of bandwidth to complete live migrations.
In Short: Live migration between virtual servers is faster and easier.
Windows Server 8
Easier Security and Compliance
Administrators will now be able to set up centralized access rules and policies by using claims, which are statements about an associated object’s attributes. These are used to manage access to information, like preventing modification or deletion of files. With this feature, admins will be able to establish strong, yet malleable rules like “to access files classed as (HBI) data, a user must be a full-time employee, access from a managed device, and logon from a smart card.”
With this, admins will be able to execute an audit on file servers to ensure that employees are in compliance with company and legal policies.
In Short: Administrators can now set up centralized access rules and policies to more easily ensure security and compliance.
Storage Spaces
Storage spaces is a sophisticated storage solution that provides a more cost-efficient and reliable way to store data. Physical disks will be turned into storage pools that act as storage spaces. All available physical disks can be used to create one pool, or multiple pools can be created by dividing the physical disks.
Storage spaces are made continuously available by integrating with failover clustering and resiliency modes (mirroring and parity) allow data to be mirrored for backup in the event of storage failures.
In short: Storage spaces are a cost-efficient, reliable, and continuously available storage solution.
Multitenant Security and Isolation
Hyper-V provides the platform capabilities to create private cloud environments and transition to infrastructure as a service (IaaS) environments. Windows Server 8 has new security and isolation features that use Hyper-V Extensible Switch to make cloud and IaaS environments more secure. The Extensible Switch is a Layer-2 virtual network switch that provides programmatically managed, policy enforcement on virtual machines that isolate multiple tenants and maintain security.
Interview with Microsoft’s Bob Combs on the Extensible Switch
In short: Hyper-V’s Extensible Switch provides security and isolation for multi-tenant usage.
Other New Features
PowerShell. Power shell is Microsoft’s command-line shell designed for system admins that has been around since 2006, but Microsoft has pushed to make PowerShell a major component of Windows Server 8 by adding more than 2000 native commands. We found this nifty PowerShell cheat sheet and a thorough breakdown of all the PowerShell commands in Windows Server 8.
Application Initialization. Allows admins to configure Windows Server 8 to initialize web applications, enabling the application to be ready for the first request.
NUMA-Aware Scalability. Non-Uniform Memory Access (NUMA) is an architecture that determines memory-based upon memory location relative o the processor. NUMA prefers local memory access over remote memory access.
WebSocket Protocol. The new standards-based protocol provides real-time bidirectional communication between a browser or application and a server. The WebSocket Protocol is supported in IIS ASP.NET 4.5 and WCF for writing server-side applications.
Try it Yourself
Want to test-drive Windows Server 8 for yourself? Here are some useful documents for getting you started:
More New Features…
We’re still digging into the new features. Follow us on Twitter for more updates as we move closer to the release date, and continue to breakdown the new pieces of Windows Server 8 and IIS 8.
No Comments »
Posted: March 20th, 2012 | Filed under: IIS & HTTP
Last week, Port80′s Thomas Powell and Joe Lima presented a webinar on web app security for ecommerce sites. The webinar was focused on Magento’s ecommerce web apps and can be seen in full below. Enjoy!
Web Application Security Best Practices for Ecommerce Sites
No Comments »
