We’re glad to see others are seeing the importance and worth in a distributed Web Application Firewall (dWAF); however, we wouldn’t call Akamai’s recent news the first WAF in the cloud.  The technology is a black list filter for requests.

Adrian Lane @ Jeremiah: in reference to Jeremiah’s point on white list vs. black list

…I am making the assumption that Akamai relieves their customers from specific ‘black list’ threats and the burden on web site WAFs, but does not relieve customers of the need to build their own ‘white list’ of policies.

Today’s WAF technology looks very different.  Black, white and gray listing is considered a basic functionality.  Proactive features like session protection, form field virtualization, learning and assisted security policy refinements are a must. Exchanging information with web application security related products, such as web application security vulnerability scanners or static code analysis tools, are a must-have.

For these reasons, art of defence launched the first fully fledged dWAF for their customers at RSA 2009.  More recently, we’ve made this service available to AWS customers or solution providers so they can protect their applications by applying hyperguard SaaS either as software plug-in to an existing web server Amazon Machine Image (AMI), or by using AoD’s custom AMI.  The technology behind this is going to be implemented at other various cloud service providers in the near future so they can offer a true dWAF (at least) in their cloud.

Follow the discussion on Twitter @hyperguard.

As stated in the OWASPs guide, phishing attacks are one of the highest visibility problems for banking and e-commerce sites because they have the potential to destroy a customer’s credit rating and livelihood.  Needless to say, this is a major concern.  To make matters worse, a recent report by Trusteer states that on average 12.5 users out of 1 million accidently access a phishing website, while this number may seem relatively small, it isn’t for banks.  They lose about $2.4-9.4 million annually.  In addition, 45% of bank customers who are redirected to a phishing site divulge their personal credentials—wow!  This report proves just how important it is for banks to use a WAF.

A WAF will detect the linking of third party websites to the legit web application and initiate counter-measures. This detection can also be carried out dynamically by only blocking access once a specific number of requests have occurred.

Trusteer’s data was compiled by measuring live phishing attacks from their Rapport browser plug-in.   Read the report in its entirety or check out ZDNet or The Tech Herald for additional commentary.

Follow the discussion on Twitter @hyperguard.

Firewalls have been around in some form or another, from the early days of networks.  A typical firewall protects the ‘trusted’ internal network from those who are on the ‘untrusted’ outside.  Things have changed since the early days.  The exploits make it all the way to applications through open ports on the firewall.  Requirements to give access to partners, contractors, guests, and customers accessing self service portals, deem the notions of ‘trusted’ and ‘untrusted’  portions of the network useless.   Today we stand at a crossroad between installed legacy infrastructure, that does not satisfy even present day security needs, and emerging technologies.  Emerging technologies don’t focus on networks and hosts, but on protecting the ‘data’ and the ‘content’. Wisdom of the day is to let the traditional firewalls keep the riff-raff out by only allowing traffic to appropriate ip addresses and ports in, and let the more application specific techniques protect the ‘data’ and defend against application level denial of service attacks.

The cost of the switch from legacy to emerging technology will be large, but the balance is tipping such that the cost of not making the switch will be even larger. Open source can help with the costs by offering the emerging techniques developed by a community of cooperative experts.  OpenADC will allow network security experts to write cost effective traditional firewalls that face the internet, and application developers to write the application specific firewalls that sit just in front of the application, such that the two work in unison to provide best protection for the application.

In rest of the posts in this category, I will survey existing open source firewalls — both the traditional network level firewalls, and application specific ones. 

What has your experience been with open source firewalls?  Let me know in your comments.

Traditionally when we think of application delivery controllers, and what goes on them, traditional services such as  those listed below come to mind.

1. Loadbalancers

2. SSL offload

3. XML offload

4. Asymmetric application acceleration

5. Traffic tracing

The openADC platform will allow developers from the user and consultant community to write services as they see fit, and whenever they need them.  With this in mind we look into the crystal ball and come up with this list of services we anticipate.  This is just a start, and we will keep adding to the list.  Here it is:

1) End to end transaction monitoring, which includes database and other back end transaction monitoring.

2) Data Leakage monitoring and enforcement.

3) Compliance related monitoring and enforcement.

4) Auto-encryption of sensitive information while it is being transmitted.

5) Application usage pattern discovery.

6)Application performance monitoring, proactive degradation sensors and alerts.

7) Web Application Firewalling.

Flexible programmable Deep Packet Inspection engine.

El Pabellón de España según el estudio Miralles-Tagliabue

Una de las bazas fuertes de España en la Expo de Shanghái es el edificio de su Pabellón. Al decir edificio quiero separar el continente del  contenido. Ambos son el Pabellón de España, pero en este post sólo hablo del edificio que alberga al Pabellón que ha obtenido esta semana el premio World Architecture Festival por su desarrollo, y que ha sido diseñado por el estudio de arquitectura Miralles-Tagliabue.  El premio que ha recibido el Pabellón se enmarca dentro de la categoría Proyectos Futuros, y la organización realiza una poética descripción de las virtudes que le han granjeado el premio. Toda la información online sobre el Pabellón a la que se puede acceder por el momento se encuentra en un PDF que se puede descargar de la página Web de la SEEI. Pero para ponerlo fácil os resumimos algunas de sus virtudes.

El estudio Miralles-Tagliabue (EMBT) fue fundado por el arquitecto catalán Enric Miralles (1955-2000), que incorporó como socio a  la arquitecto milanesa Benedetta Tagliabue, que ahora dirige el estudio tras el fallecimiento de Miralles. Entre sus proyectos más emblemáticos figuran el Parlamento de Escocia, la sede de Gas Natural y el mercado de Santa Caterina, ambos en Barcelona, y la reforma del barrio portuario de Hamburgo.

Según leemos en el PDF, “Tagliabue pretende con su propuesta de pabellón huir del concepto tradicional de caja contenedora, abriendo paso a grandes espacios a la manera de cestos de mimbre que permitirán un tránsito fácil y fluido. [...] En el pabellón se emplearán materiales naturales ecológicamente sostenibles. La fachada contará con el mimbre como principal elemento de revestimiento, jugando con toda su potencialidad técnica, además, según Tagliabue, el tejido en fibras naturales, una técnica artesanal de tradición ‘global’ utilizado tanto en Oriente como en Occidente, se convierte en hilo conductor entre España y China. El mimbre, se sustenta en un entramado de soportes y vigas de acero tubular, lo que permitirá que la luz penetre en el interior tamizada por la estructura de mimbre y acero. El pabellón, que contará con un presupuesto de 18 millones de euros, tendrá una superficie útil de aproximadamente 7.081 metros cuadrados, que se edificarán sobre una parcela de 6.000 metros cuadrados. El Pabellón de España figura entre los más grandes de los países participantes junto a Francia, Inglaterra, Alemania e Italia.”

by Aziz Narejo, Tx

Hats off to Amar Sindhu, her colleagues in WAF, Jami Chandio and others who have taken a practical step in this case. All of you have done a superb job in this as well as in many other cases. Please take up the case of the girl molested by her teachers too. She and her family needs the help of the civil society activists.

Courtesy: SANAlist@yahoogroups.com

—

More on this issue, please click here to read Nisar Khokhar’s report at BBC urdu

http://www.bbc.co.uk/urdu/pakistan/2009/11/091103_poet_alleged_as.shtml

Who would have thought a carpool service web site could be the stuff of pulp novels and Hollywood capers? After reading about the early September plight of RideMatch.info in the New York Times, you might not see the connection since ‘Agent Smith’ reported technically about this run-of-the-mill SQL injection attack on the popular Southern California commuter website. Dig into the details and you will assuredly start to crave popcorn and your favorite soda!

The opening shot would pan stage-left to settle on a robed gentleman at his PC. Steaming cup of java in hand, our subject clicks his mouse on SEND to whisk his phone number, address, commute time, work location, employee ID number and name to RideMatch’s member database to find a suitable carpool. Satisfied, our man walks slowly off camera.

Camera fades to black as the narrator sets the stage for drama to come, “little did Joe know his life was about to crash into those of a cat burglar, overworked web application developer and an eager hacker.”

Because a hacker had exploited a coding flaw in RideMatch’s site – the infamous SQL injection – a hacker was able to see every user’s data, pinpointing who was home when, employment information and social security numbers (a.k.a. employee ID numbers), whose value was only in the sale of this information to others. While the burglary didn’t actually happen, it isn’t much of a stretch to see that it very well could have. Would a web application firewall (WAF) have prevented this and saved RideMatch from certain liability? If configured correctly, yes.

How prevalent is this issue? Very. Here are just a few of the interesting public cases.

On August 17, 2009, the United States Justice Department charged an American citizen Albert Gonzalez and two unnamed Russians with the theft of 130 million credit card numbers using an SQL injection attack. In reportedly “the biggest case of identity theft in American history”, the man stole cards from a number of corporate victims after researching their payment processing systems. Among the companies hit were credit card processor Heartland Payment Systems, convenience store chain 7-Eleven, and supermarket chain Hannaford Brothers.

In 2008, at least April through August, a sweep of attacks began exploiting the SQL injection vulnerabilities of Microsoft’s IIS web server and SQL Server database server. The attack doesn’t require guessing the name of a table or column, and corrupts all text columns in all tables in a single request. ^[21] A HTML string that references a malware JavaScript file is appended to each value. When that database value is later displayed to a website visitor, the script attempts several approaches at gaining control over a visitor’s system. The number of exploited web pages is estimated at 500,000

On April 13, 2008, Sexual and Violent Offender Registry of Oklahoma shuts down site for ‘routine maintenance’ after being informed that 10,597 social security numbers from sex offenders had been downloaded by SQL injection

Not: Bu döküman “Mod Security Reference Manual” dökümanından yararlanılarak yazılmıstır.

Zaman zaman içinde kendi yorumlarım ve örneklerim bulunmaktadır.

Giris

Mod Security Nedir?

Mod Security, Web uygulamaları için gelistirilmis açık kaynak kodlu güvenlik duvarıdır “Web Application Firewall (WAF)”. Mod Security web sunucusuna gömülü sekilde çalısır.

Kullandıgınız ve ya yazdıgınız web uygulamaları için saldırı tespit ve engelleme görevini üstlenir.

Neden Kullanırız?  Yararları Nelerdir?

1. Mod Seucirty HTTP trafigini son derece detaylı dinler (Bunu ileride auditlog kavramında görecegiz). Apachenin loglarını göz önünde tutarsak istek içerigi ve cevap içerigi gibi ibarelerin loglanmadıgını görürüz. Oysa Mod Security HTTP trafigi üzerinde her türlü veriyi kayıt altına alma yetenegine sahiptir. Hatta bu logları gruplamanıza ve ya daha okunur sekilde yazdırmanıza yardımcı olur. Bir çok log analiz standartını desteklemektir. Özellikle kendi içinde guarding log sitilinide bulundurmaktadır.

2. Mod Security`nin bir avantajıda gerçek zamanlı veri analizi yapmasıdır. Bu ne demektir?

Kullanıcıların uygulamalarınız üzerinde ve ya web sunucunuza baglandıgı andan itibaren gelen giden veriler üzerinde istediginiz kontrolleri yapmanız demektir.

3. Saldırı tespit ve önleme için anında müdahaleler yapmanıza yarayan kurallar yazabilirsiniz.

Mod Security web uygulamalarınıza erismek isteyen saldırılara karsı anında tepki verir.

Bunu çogunlukla üç yolla yapar :

a. Negatif Güvenlik Modeli (Negative Security Model):

Anormal istekleri, sıra dısı hareketleri ve genel web uygulama ataklarını izler. Kısacası bir çok detaya bakıp (ip adress, oturum, kullanıcı hesabı) bunların sonucuna göre kuralların islenmesi saglanır.

b. Pozitif Güvenlik Modeli (Positive Security Model):

Bu modeli uyguladıgınızda, sadece geçerli tanımladıgınız istekler kabul edilir ve bunun dısındakiler tümüyle reddedilir. Bu yaklasım agır ve nadiren güncellenen uygulamalarla çok iyi çalısır.

c. Bilinen Zayıflıklar ve Açıklar (Known weaknesses and Vulnerabilities):

Mod Security`nin kural dili sayesinde, dısarıdan gelen saldırılara karsı sunucunuza kurallar yardımı ile birlikte yamalar yapmanızı saglar. Bu yamalar sunucunun kendi açıklarından ziyade üçüncü parti yazılımlardan kaynaklanan açıklardır. Bu yazılımlardan kaynaklanan açıklar yazılım sahibi tarafından güncellenene kadar mod Security ile yamalar olusturabilirsiniz. Yani dısarıdan gelen zararlı istekleri azaltmaya yarar. Web uygulamalarının açıklarını düzeltmek bir çok kurumda haftaları buluyor. Mod Security sayesinde uygulamanın kaynak koduna dokunmadan (çogu zaman erismeksizin) dısarıdan kurallar ekleyerek güvenlik yamalarınızı olusturabilirsiniz.

4. Mod Security kural moturu (SecRuleEngin) çok esnek kurallar yazmamızı saglar. Bu motor aynı zamanda Mod Security`nin asıl amacını tasır. Aynı zamanda HTTP islem dataları üzerinde bize özel bir programlama dili sunar. –ki bu dil normal firewall kullanıcıları ve ya web uygulaması gelstirenler için çokta yabancı degildir (Özellikle regular expression – düzenli ifadeler, PCRE kütüphanesi kullanılır). Bir diger hususta zincir kurallar olusturabilmenizdir. Bsunu bir nevi if kurallarına benzeterek yapılan kural takımıda diyebiliriz. Buda sizin daha kompleks kurallar yazmanız anlamına gelir.

5. Yukarıda da söyledigimiz gibi Mod Security gömülü bir firewall uygulamasıdır. Bunun anlamıda kurulu olan web sunucunuza istediginiz zaman ilave edebilir ve devre dısı bırakabilirsiniz. Mod Security`nin bu kullanım sekli ile daha önce var olan networkünüzde herhangi bir degisiklik yapmanıza gerek kalmaz. Ayrıca kural dosyalarının Web sunucunuzla bir bagı olmadıgından tasınabilirligi gayet kolaydır. Ayrıca SSL tarfiginide analiz etme yetenegine sahiptir. Bunu SSL üstünden geçen veriler çözüldükten hemen
sonra hayata geçirir. Bir çok isletim sistemiyle birlikte gayet uyumlu çalısır. Genel kullanıcıları FreeBSD, Linux, Windows, Solaris, OpenBSD, NetBSD, AIX, Mac OS X ve HP-UX.

6. Mod Security apachenin Mod proxy uygulaması ile birliktede çalısabilir.

Devamı için :

ModSecurity_2.1.0_Turkish

This week in Las Vegas, the PCI Virtualization Special Interest Group (PCI SIG) is meeting to figure out how to handle the growing use of this computing market. Long overdue, the group still is neglecting important aspects for web application firewall (WAF) specifics. There have been countless discussions, articles and commentary about PCI in general, yet the WAF guidelines remain simple: get one, use it and make sure it integrates with other measures. Technically, this is the web application protection requirement 6.6 option 2.

What’s missing is ruleset flexibility and control, which also happen to be the biggest points of contention with WAF technology today. A little variety in deployment is also handy in a virtualized setting for ease of deployment – a distributed WAF if you will, or dWAF. Specifically:

Detection and Protection

Foundational security using black, white and grey listings for application requests and responses must be possible. To make sure pre-set policy enforcements are not activated or deactivated without approval from an administrator, deployment and policy refinement through establishing rulesets must be possible in a shadow monitoring or detection only mode. Once the shadow monitoring ruleset is stable, only then should it be allowed to deploy in an enforcement mode on the dWAF. This allows complete transparency for the administrator into the real-world effect of this ruleset, while at the same time allowing layered rulesets to be tested without compromising existing policy enforcement. Avoiding false positives and relaxed established defenses are essential for a real-world, usable dWAF in a cloud.

Automated learning and ruleset suggestions based on intelligent algorithms or recommendations from a static source code analyzer or web vulnerability scanner are also desirable from a manageability view. Again, this only holds true if the administrator retains full control over activation / deactivation of each ruleset. Without this control, wanted traffic may become blocked and policy settings would become compromised.

Application Shielding

Pro-active security functions are highly recommended to reinforce any application in a cloud. Detection is simply not enough for today’s web application security. Features like transparent secure session management, URL encryption and form-field virtualization will provide strong deterrence to attack, while saving application development and deployment time. These features are effective because session management, URL encryption and form-field virtualization is done at the dWAF level and not in the application itself.

An authentication framework support that enables businesses to consolidate their applications under one management schema is also desirable for a dWAF. This enables users to handle the authentication in front of their applications rather than behind, which adds another perimeter of security. A consolidation of all applications with dedicated rights-management ability is also a strong usability function that will make an administrator’s life easier.

More info here: www.artofdefence.com

Great article on the 16^th from SearchSOA.com by Rob Barry. He interviews a developer at Mozilla Labs – Joe Walker – about a few of the OWASP Top 10 and how to develop around them. Walker’s focus as a developer is on creating / patching / managing security threats to apps. What’s missing from Barry’s article, however, is the incredible pain this approach causes companies right now.

Refactoring code once it’s in use (particularly WebApps and cloud services) is incredibly expensive, time consuming and difficult. Source code scanners play a role in easing some of this pain, although web application firewalls (WAF’s) are a much more practical fix, AND, linking the scanner software directly with the WAF cuts down the need for application downtime.

If done right, the scanner detects software vulnerabilities and feeds any findings directly into the WAF. For our distributed WAF (dWAF) solution, hyperguard, all security lapses identified by a scanner are immediately presented to the administrator through dynamic ruleset suggestions. Conflicting dWAF rulesets, which may leave holes in web application shielding, are prevented. In plain English, this means that development, testing and deployment of new application security policies can happen in real-time without ever relaxing the established defenses or risking false positives. ‘Patches’ are applied through the dWAF until regular maintenance cycles can be scheduled to refactor the actual application code.

Fancy going from a SQL Injection on Microsoft SQL Server to a full GUI access on the DB? Take a few SQL Injection tricks, add a couple of remote shots in the registry to disable Data Execution Prevention, mix with a little Perl that automatically generates a debug script, put all this in a shaker with a Metasploit wrapper, shake well and you have just one of the attack modules of sqlninja!

Sqlninja is a tool targeted to exploit SQL Injection vulnerabilities on a web application that uses Microsoft SQL Server as its back-end. Its main goal is to provide a remote access on the vulnerable DB server, even in a very hostile environment. It should be used by penetration testers to help and automate the process of taking over a DB Server when a SQL Injection vulnerability has been discovered. Have a look at the flash demo and then feel free to download it.

Features

The full documentation can be found in the tarball and also here, but here’s a list of what the Ninja does:

• Fingerprint of the remote SQL Server (version, user performing the queries, user privileges, xp_cmdshell availability, DB authentication mode)
• Bruteforce of ’sa’ password (in 2 flavors: dictionary-based and incremental)
• Privilege escalation to sysadmin group if ’sa’ password has been found
• Creation of a custom xp_cmdshell if the original one has been removed
• Upload of netcat (or any other executable) using only normal HTTP requests (no FTP/TFTP needed)
• TCP/UDP portscan from the target SQL Server to the attacking machine, in order to find a port that is allowed by the firewall of the target network and use it for a reverse shell
• Direct and reverse bindshell, both TCP and UDP
• DNS-tunneled pseudo-shell, when no TCP/UDP ports are available for a direct/reverse shell, but the DB server can resolve external hostnames (check the documentation for details about how this works)
• Evasion techniques to confuse a few IDS/IPS/WAF
• Integration with Metasploit3, to obtain a graphical access to the remote DB server through a VNC server injection

Platforms supported

Sqlninja is written in Perl and should run on any UNIX based platform with a Perl interpreter, as long as all needed modules have been installed. So far it has been successfully tested on:

• Linux
• FreeBSD
• Mac OS X

Sqlninja does not run on Windows.

http://sqlninja.sourceforge.net/

Os dejo el cartel y el calendario del 31 Campeonato Mundial de Lucha de Brazos:

XXXI CAMPEONANTO MUNDIAL DE LUCHA DE BRAZOS

Parco Delta del Po, Rosolina Mare (Rovigo) ItalIA 2009

Calendario de eventos:

• Sábado 5 y Domingo 6 de septiembre. Acogida de los equipos
• Lunes 7 de septiembre en el CENTRO DE CONGRESOS ROSOLINA MARE:

9:00-10:00 h.. Registro de equipos

10:00-17:00 h. Elección de árbitros

17:00-19:00 h. Encuentros continentales.

• Martes 8 de septiembre en el CENTRO DE CONGRESOS ROSOLINA MARE:

8:00-18:00 h. Vencedores de cada país

19:00-21:00 h. Encuentro congresual de la Federación Mundial de Lucha de Brazos.

• Miércoles 9 de septiembre en el PALACIO DE CULTURA Y DEPORTES PORTO: VIRO

10:00-10:30 h. Ceremonia de Apertura

10:30 h. Comienza la competición.

Categoría Juvenil mano izquierda

Masters mano izquierda.

Gran Master y Senior mano izquierda.

Discapacitados mano izquierda.

Ceremonia de entrega de premios.

• Jueves 10 de septiembre en el PALACIO DE CULTURA Y DEPORTES PORTO: VIRO

10:00 h Comienza la competición.

Categoría Juvenil mano derecha.

Masters mano derecha.

Gran Master y Senior mano derecha.

Discapacitados mano derecha.

Ceremonia de entrega de premios

• Viernes 11 de septiembre en el PALACIO DE CULTURA Y DEPORTES PORTO: VIRO

10:00 h. Categorías mano izquierda

Ceremonia de entrega de premios

• Sábabo 12 de septiembre en el PALACIO DE CULTURA Y DEPORTES PORTO: VIRO

10:00 h. Categorías mano derecha

Ceremonia de entrega de premios

• Domingo 13 de septiembre: Despedida de los equipos.

31th WORLD ARMWRESTLING CHAMPIONSHIP

Parco Delta del Po, Rosolina Mare (Rovigo) Italy 2009 Schedule of Events:

• Saturday 5th and Sunday 6th September Team Arrivals
• Monday 7th September CONGRESS CENTER ROSOLINA MARE

9:00 a.m. to 1:00 p.m. Team Registration

10:00 a.m. to 5:00 p.m. Referee Seminar

5:00 p.m. to 7:00 p.m. Continental Meetings

• Tuesday 8th September CONGRESS CENTER ROSOLINA MARE

8:00 a.m. to 6:00 p.m. Country Weigh-ins

7:00 p.m. to 9:00 p.m. Congress Meeting – W.A.F. congress

• Wednesday 9th September PALACE OF CULTURE AND SPORT – PORTO VIRO

10:00 a.m. to 10:30 a.m. Opening Ceremonies

10:30 a.m. Start of Competition

Youth Left Hand Classes (13)

Left Hand Masters (9)

Left Hand Grand Masters (3)

Left Hand Senior Grand Masters (3)

Left Hand Disabled (6)

Finals-Awards Ceremony (34 classes)

• Thursday 10th September PALACE OF CULTURE AND SPORT – PORTO VIRO

10:00 a.m. Start of Competition

Youth Right Hand Classes (13)

Right Hand Masters (9)

Right Hand Grand Masters (3)

Right Hand Senior Grand Masters (3)

Right Hand Disabled (6)

Finals-Awards Ceremony (34 classes)

• Friday 11th September PALACE OF CULTURE AND SPORT – PORTO VIRO

10:00 a.m. Left Hand classes

Finals-Awards Ceremony (18 classes)

• Saturday 12th September PALACE OF CULTURE AND SPORT – PORTO VIRO

10:00 a.m. Right Hand Classes

Finals-Closing Ceremony (18 classes)

• Sunday 13th September Team Departures

Más información sobre el campeonato en la página oficial de Braccio di Ferro:

http://www.bracciodiferroitalia.it/19-mondiale-2009/

I recently read Web security is about scalability, a very interesting post by Jeremiah Grossman of White Hat Security. He discusses the importance of scalability in overcoming today’s Web security challenges. I would like to add some of my thoughts.

It has taken the industry over 10 years to realize that when dealing with Web application vulnerabilities, they must also deal with the scalability issues these applications face. This needs to happen in parallel with normal security testing. As Jeremiah highlights the incredible scaling needed today:

“Consider that there are 240+ million websites, millions more added every month, an unknown number of Intranet Web applications, 17+ million developers, and over one billion people on the Web. Any solution capable of making a real difference must be valued by its potential worldwide impact.”

Testing a web application on a single system (how most are tested before being sent out into the world) without taking into account scalability is costly. Once that application hits it’s performance limit it usually means a redesign and rewrite of core elements to make it more scalable, changing how and what is important to test. Think of the OWASP top 10 on Jeremiah’s scale!

Cluster computing, or cloud computing, presents a remedy to developing, testing and scaling web applications in a much more practical sense.

Flip the coin to protecting the applications once they’re live and in action, and Jeremiah’s scalability point becomes painfully apparent. Web application firewall’s (WAF) are the industry standard for this purpose, however they are predominantly hardware. Hardware doesn’t scale – you have to buy another box. More boxes, more resource drain, less virtualized resources and on and on.

The article Jeremiah references in his post (check here for the white paper), outlines my view of what the market needs from a WAF.

I was just browsing through net and I came across this article. I was a little shocked on reading just the title. Why would anyone want to leave GNU software ? .. So it sparked my interest and I spent next 30 minutes reading the whole article (or rather technical viewpoint of KDE team). That did not convince me though in anyway.

I agree that autotools are very old but so is gcc and so are other basic tools that come with all distros. Reading the article convinced me of one thing, not many people on the KDE team know much about autotools. They have used one small part (Makefile) of it but they don’t know what exactly the autotools are and how they work. I even somehow got a feeling that many KDE developers are scared of autotools. Reason: autotools have a longer and hard learning curve. It is true, I agree. I was able to write a CMakeLists.txt in just a day, right from the scratch without any book or help except the online documentation available at their web-site, while with autoconf, the story was different, even after 2 days of work, I was unable to came with with anything. Autoconf manual felt like a classic GNU manual written in the spirit of GNU by people who are extremely technical. It pinned me, it binned me and it made my heart bleed. Are most of KDE developers scared of autotools ? I don’t know and after reading their reasoning , I will say yes. Most of them wanted a short and less painful path to software building: here come Scons and CMake.

I was also just put off by the technical-expertise either required as a prerequisite or being used to read the manual but was I scared …… hell no…. . Say no to the hell and yes to the reasoning and rationality. There glows the bulb on my head, the people who write these kind of manuals are very good at basics , they are the people who have gotten their fundamentals straight, with experience. Reading their manuals always gives you an insight into the things. This is what exactly what you will learn from Newsgroups.

I am not saying that KDE people need to switch back to autotools. No, I am not agreeing on that. All I am saying is, switching to a different tools needs to be based on purely technical reasons, not on the basis that people can’t learn them because they are scared. I really wonder they are not trying waf, which actually does not try to fix the problems of other tools but rather built as a software-construction framework.

I, myself, want to use waf but then I have to learn Python in order to debug my scripts which I don’t want to do. If I ever get time to learn a new language, I will learn Common Lisp. So rather I will start learning autotools again and will see what people are scared of.

Copyright © 2006, 2007, 2008 Arnuld Uttre, #331/type-2/sector-1, Naya Nangal, Distt. – Ropar, Punjab (INDIA) – 140126

Verbatim copying and distribution of this entire article are permitted worldwide, without royalty, in any medium, provided this notice, and the copyright notice, are preserved.

My piece from Meeting of Styles, Belfast on the Peace Line
with Smug, Gaz Mac, Waf & Tesda.

Strange to be painting in an area and on a surface with so much significance.
It seemed like already the graffiti had become a small part of the story of the wall as the taxi drivers had begun to incorporate it in their tour guide speel as they ship car loads of tourists to and fro all day long.

Full Wall Here

Big thanks to Dris, Rask & Plum.

La Federación Italiana de Lucha de Brazos(S.B.F.I). y el Delta Parco del Po (Regione Veneto) se enorgullecen de invitarles oficialmente a participar en XXXI W.A.F. Campeonato Mundial de Lucha de Brazos que se desarrollará en Rosolina Mare y Porto Viro (Rovigo) junto a Venecia, en el norte de Italia, a partir del domingo 6 y hasta el domingo, 13 de septiembre de 2009.

I wanted to cover some WAF topics I haven’t seen covered much. Most WAF vendors talk about the security their product provides in terms of blocking attacks. I would like to delve into these WAF Blockings as well as mention some ideas for alternative uses for your WAF through it’s interactions with web clients.

Web Application Firewalls are interesting bits of technology. Depending on the product and deployment method you chose, they can transparently protect your web infrastructure using various protections by generating blocks when threats are identified. Depending on the product, they can Vulcan mind meld with your Apache instance, live as another F5 device in your network, take over a slotin your XBeam, or live life as a network appliance inside your datacenters.

This intelligent device COULD interact with the client in additional ways outside generating BLOCKs. For example: developers could leverage a WAF to provide additional protections, send notices to connect clients under specific conditions, or even prompt a client for confirmation before performing a specific function if certain criteria are met. After all the BLOCK a WAF generates doesn’t have to be a BLOCK at all, at least not in the context of traditional firewalls or even active-response IPS devices.

If WAF interaction with the client is a concern because you’re trying to keep your WAF invisible to the bad guys, you should know that that’s not a realistic expectation.

WAF’s block threats to your web applications identified through various security methods, but what does that mean?

There are a few options, largely dependent on the vendor and deployment method (transparent bridge, proxy, router, offline sniffing): TCP Reset, Request/Response DROP, out of band Reset via 3rd party. There’s no hard-fast requirement to only use a TCP Reset that’s sent to client and server, like IPS or active-response causing the TCP session/connection to be terminated, but this is controlled by deployment method.
The DROP method is like a virtual trapdoor inside the WAF where malicious traffic falls into a dark pit, never to be seen again.

Some WAF products can send a web coded response back to the web user inside their active session indicating their request could not be completed, some WAF can be configured to quarantine an IP Address or terminate a web session, in addition to dropping the client request or server response. The use of WAF generated error pages to interrupt and/or stop the web session alongside Request/Response dropping is more graceful than TCP Reset. Depending on your environment, TCP Resetting could create unexpected results on your web servers and typically this requires your WAF to be operating in Proxy mode.

In traditional transparent WAF deployments, these BLOCKs generated by a WAF are typically nothing more than a standard error page or a redirect to a logout sequence coded within the web application being protected.  Some WAF’s allow you to customize the page, insert scripting, and push it seamlessly to the end-user inside the existing SSL session. Alternatively, the client could be redirected to a destination within the protected application to log out their session, collect additional information, or open a support ticket (although the last one of those I saw, was more for looks than functionality).

If the WAF can generate web pages in response to client interactions inside an existing SSL session, the client would be interacting with the WAF. The Imperva Application Defence Center (ADC) has an interesting web fraud paper on enabling clients to interact with what I would describe as a security control panel, to help with CRSF/XRSF attacks and web fraud. I have played around with this a little and found some interesting uses – sorry saving that info for my next contracting gig!

The idea of using policies to trigger BLOCKs takes on a new meaning, if the WAF can be leveraged to a generate unique or controlled web pages when a specific policy is triggered or even redirect a user to a specific function inside an application if certain criteria are met, before continuing on inside an application. Don’t get me wrong, TCP Resets are good too – but this path offers much more robust options for a company from multiple perspectives.

Now the WAF can be used to not only BLOCK pure security-centric threats but also control the application behavior and client interaction if something fraudulent, abusive, or irregular is detected. For example you could leverage the behavior deviation capabilities of your WAF (profile violations) and construct a temporary input validation error handling process inside your WAF while your coders developed the handling inside the application. This would be a straight forward use of the acquired knowledge of the WAF, a simple error page containing the prohibited characters, and a method for the client to have a “do over” on the prior page.

Once again, the WAF is providing additional capabilities that an IDS/IPS cannot!

The traditional network security approach to securing your web servers and database servers is more than likely going to get you in trouble some day. Think about it. Network Security preaches deny everything and permit only what you need. Great, open up port 443 and send encrypted traffic to your web server. KaBOOM gotcha!

Think about your Web Application Firewall and the reasons for your investment in web application security.
Regardless of the technology you have selected, here are four protections your WAF investment needs to be providing:

#1 Enforce decryptable web communications.
This might seem counter-intuitive but first and foremost, if your WAF can’t see it – then the WAF can’t intelligently PROTECT your assets! You need to disable any encryption not supportedby your WAF. It’s a long-standing double-edge sword securing web communications but still being able to inspect the communications. No more pre-shared or temporary key SSL sessions, sorry Diffe-Hellman, most WAF’s only support pure RSA. In addition, this is a good time to make sure your servers negotiate at a respectable bit length.

#2 Enable Correlation.
Attack signatures are great, but correlation is better. If your WAF doesn’t offer some form of correlation of multiple signatures and security events before triggering an alert, you might consider picking one up that does. Web Intelligence is a good product, but it’s not an F5, Breach, or Imperva WAF, and that difference could cost you.

#3 Serve & Protect, becomes Learn & Protect.
The best offense is a good defense. If your WAF knows what the application it’s protecting looks like or even better, how it behaves, then the application’s very own structure, coding, and URL/parameter make-up becomes it’s shield against malicious attacks. You don’t need to wait for a signature to protect your web application from new SQL Injection or XSS or Fuzzing attacks, if the WAF is stopping anything that doesn’t conform to expected behavior!

#4 Assess THEN Customize.
When you build a new house, you might expect to have certain things done specific to your requirements before you ever set foot inside the house but you’ve at least looked at the blueprints and seen sketches of the final product. For a WAF guarding a Web Application, custom rules really should be the last thing you do, and ideally AFTER you validate existing protections aren’t enough through penetration testing or code scanning. The major WAF vendors support the inclusion of vulnerability assessments in their products for custom policy creation.

Obviously enabling any of these are subject to your risk exposure / tolerance, but I wouldn’t advocate running for any length of time without these protections regardless of the organization or the other protections you may in place to guard your web applications.

Consider what every online entity is up against, there is more money to be made hacking your protected assets by nefarious (hopefully external) sources than you have resources or funding – short of government entities. If that wasn’t bad enough there are newly coded applications and updates released every minute than there are security fixes going in. If you’re not fully leveraging what you have and not securing as you go, then your company is leaving something undone for the bad guys to come along and exploit.

How is your WAF being used? Is it being used? Need help getting more out of your WAF?

I had an email asking what placeholders I usefor logging platform integration. Rather than reply in a comment or email, I thought I’d just make a post out of the response.

Looking at placeholders, here are some of the ones I use the most:

• ${Alert.dn}  this is the alert id
• ${Alert.createTime} this is the time the ALERT was created (note this can be misleading)
• ${Alert.description} this is bound to the alert, so you may see “Distributed” or “Multiple” appended due to aggregation of events
• ${Event.dn} this is the event (violation) id
• ${Event.createTime} this is the time the EVENT was created (this is when the event happened}
• ${Event.struct.user.user} this is the username from a web or database action
• ${Event.sourceInfo.sourceIP}
• ${Event.sourceInfo.sourcePort}
• ${Event.sourceInfo.ipProtocol}
• ${Event.destInfo.serverIP}
• ${Event.destInfo.serverPort}
• ${Event.struct.networkDirection} which way is the traffic flowing that triggered the event?
• ${Rule.parent.displayName} this is the name of the Policy that was triggered

There are other placeholders you can leverage, but these are the core I start with. I like these because they’re used on the web gateway AND the database gateway. This lets me have a consistent intelligence feed to my log monitoring platform and my SIEM product.

The trick here is that I can see how may events roll up underneath a single Alert. In the syslog feed, I can track the duration of an attack as well as tell you when I last saw the activity, because I track Alert.createTime and Event.createTime.

There are lots of options for how you build your syslog feed:

• You may be interested in the response time of the query or web page
• Perhaps the response size is of concern to you
• You may treat threats differently depending on where they occur in a database table or URL
• You may be interested in the SOAP action or request

Last but not least, in addition to security events you can also push system level events in the same manner using different placeholders.

• Configuration events can be syslog’d on complete with the user making the change
• Gateway disconnect messages can be sent via syslog (snmp might be better, but you need to load the custom OIDs)
• Excessive CPU or traffic levels can be sent via syslog

How are you using placeholders?

I received some emails overnight on the Imperva DIY Syslog posting asking when to use the alert placeholders versus the event placeholders.

For anyone not familiar with the Imperva SecureSphere platform, the system has a handy feature that provides aggregation of events on the SecureSphere management server detected by the gateways. This works whether you’re using the web or database gateways but for today I want to focus on the relationship between the data coming from the gateways and the aggregated data on the manager,  I’ll let ImperViews get into the other details - you can read more in the Imperva documentation.

The first thing you have to take note of is the Imperva hierarchy for violations/events and alerts. When the Imperva detects a condition that meets the criteria of a policy, whether that’s correlation, signature, profile, custom, etc., a violation is triggered on the gateway and fed to the management server. Everything in the management server for reporting and monitoring builds off this violation/event detail from the gateway, the gateway is where the enforcement and detection takes place so that should make sense. This is how we know the gateway is taking action on our behalf!

Assuming you haven’t disabled aggregation on the SecureSphere settings, each violation is aggregated into an alert. There are several criteria that the management server uses when aggregating a violation, so you’ll want to check the documentation for your version. The basic idea is that the SecureSphere manager will aggregate similar violations against a server group, an IP Address, a URL, a policy, or some combination of thereof in a 12 hour window. An alert in SecureSphere will have at least one violation/event tied to it, but depending on your aggregation settings it may have more.

So???

So! When you push security events to an external log monitor, you have to decide if you just want the initial Alert information or if you want each violation that occurs! If you build the Action Interface using ALERT Placeholders you’ll only get the Alert data with no additional details in the underlying violation/event stream. This could be problematic, if you’re trying to figure out if something is still going on because remember the SecureSphere aggregates violations under a single Alert for up to 12 hours!

In addition to using the correct placeholders, you also have to enable the “Run on every event” checkbox in the Action Interface/Action Set.

I tend to mix the Alert and Event placeholders so that I get relevant Event details wrapped in the Alert context. I see no reason to make my logging solution work extra hard to establish the same correlation of the Events into Alerts that SecureSphere does automatically.

How do you manage your SecureSphere alerts and events?