FileZilla Server Autoban Application

Estándar

Automatic Tool to Update the IP Filter Disallowed

Users of Filezilla Server for Windows…congratulations, with this application your IP Disallowed Filter will be updated everyday from login/password errors readed from daily service logs.

I love Filezilla Server for Windows but native autoban options are not enough for me. In my web server clients not have FTP accounts, but i use a few for different reasons. I was bored to see the logs every day, every minute with people try hack the FTP Server with different user/password combinations. I don´t understand how filezilla server dont have a black list manager to control ip´s from logs.

But i decide to make my own updater tool. It´s very simple.

Te console application read the “same day” log file (making a copy, log file is blocked by Filezilla Service) , stores the ip´s with login errors and update XML configuration file, IP Filter Disallowed item.

But this its unsuccesful if service was not restarted…i do it also.

By this way i schedule the exe to execute about 23:55 every day, having the ftp server “IP Filter Disallowed” list updated.

Are you interested on this ?

You can try my tool download exe file from the github project repository, and also you can download the project and change it for free.

FileZilla Server Autoban IP Disallowed Updater

FileZilla Server Autoban IP Filter Disallowed Updater Project

Note: In newer version i will develop an min error count variable from same IP to be filtered. Sometimes a customer try to enter his FTP account with errors, maybe the filter only has to been fired if login error happens more than x times.

Evitar ataques SQL Injection en IIS7 con SQL Server

Estándar

En este post hablaremos sobre un tema que interesa a cualquiera que desarrolle o trabaje con bases de datos en una aplicación web, los ataques con inyección SQL.

¿Que es un ataque con inyección SQL (SQL injection)?

En principio los ataques SQL injection son combinaciones de técnicas para conocer datos sobre la configuración de un servidor web y de su base de datos, de forma que, de manera mas o menos directa, se pueda conseguir acceso a la misma, para usarla en beneficio del atacante, bien borrando datos, copiandolos y vendiendolos posteriormente o manipulandolos para conseguir algún objetivo, como puede ser la propagación de un virus desde esa misma página.

Los ataques consisten en la adición de sentencias SQL especiales que, ejecutadas en el servidor, le den al atacante información tecnica sobre la base de datos y posteriormente acceso de algún tipo.

¿Son evitables todos los ataques  SQL Injection?

Un servidor web publico siempre podrá ser accedido por cualquier usuario que acceda a la página o conecte a través de un programa informático, con lo que siempre estará expuesto. Incluso en servidores internos de redes empresariales podemos tener problemas con cualquier usuario, por eso son importantes el uso de todas las técnicas que vamos a ver en este post.

Es probable que nos dejemos alguna ya que vamos a hablar sobre servidores IIS y SQL Server, podeis dejar vuestras aportaciones en los comentarios si teneis alguna para otras bases de datos o servidor web.

¿Cualquier base de datos es susceptible de un ataque SQL Injection?

En principio las mas usadas en aplicaciones web como Mysql, Oracle, SQL Server y Access (increible que todavia se use para webs) son susceptibles de ser atacadas para conseguir el acceso, cada una con sus diferentes sintaxis, pero en general las técnicas son similares.

Técnicas de defensa ante ataques SQL Injection

1. Páginas de error personalizadas

No hay que ponerselo fácil a los atacantes de nuestras webs.

Al principio de un ataque se usan diferentes sentencias para que la página proporcione errores de sintaxis al intentar ejecutarlas y de esa manera conocer que versión de base de datos usa nuestra aplicación, para ser más precisos en las siguientes oleadas. Si queremos ver los errores cuando estamos desarrollando, pero queremos que sean invisibles al resto de usuarios, podemos generar una página de error personalizada que solo muestre los detalles a una determinada IP o si estas logado en un panel de control de la propia web, mientras que el resto de usuarios veran un bonito mensaje creado por ti sin detalles sobre el error.

2. Uso de procedimientos almacenados.

Una de nuestras experiencias contra ataques de inyeccion SQL fue en un cliente que ya tenia la aplicacion web funcionando y nos llamo para realizar un proyecto de SEO. La web tenia distintas funcionalidades, aunque basicamente era un buscador de textos cientificos. Nuestra sorpresa llego cuando al revisar el código en ASP muchas llamadas a la base de datos se realizaban de manera directa haciendo “select ” con parametros querystring (GET) en vez de usar procedimientos almacenados contra SQL Server.

¿Que implica ejecutar selects con parametros?

Los select con parametros son la puerta de entrada a los ataques SQL injection ya que salvo excepciones que ya veremos mas abajo, su uso deja abierta la puerta para que poniendo un simple punto y coma “;” todo lo que venga detras en el querystring sea ejecutado en la base de datos.

/pagina.asp?id=1;update users set name=’codigo javascript con enlace a un virus’

si en el script pagina.asp usamos una select abierta podemos hacer que la base de datos ejecute la sentencia detrás del ; en este caso cambiando el valor de un campo en toda la tabla de usuarios por un codigo javascript que nos lleve a una pagina con virus, que fue lo que ocurrió en este cliente. Todos los que trabajamos con bases de datos usamos nombres muy parecidos en muchas aplicaciones, por comodidad y sencillez de mantenimiento, con lo que determinadas tablas suelen tender a tener el mismo nombre en muchas webs haciendo mas fácil un ataque dirigido en este sentido.

¿Cual es la ventaja de los procedimientos almacenados?

En el caso de los procedimientos los parametros entran por separado y ademas “tipados”, esto significa que si el servidor espera un valor numerico (int) al recibir el “update …” fallará y no se ejecutará. Y en el caso de varchars podria incorporar el texto en un update, pero nunca se ejecutaría directamente minimizando el riesgo.

¿Tiene alguna debilidad un procedimiento almacenado?

Si, en general en el momento que un procedimiento almacenado se hace “dinámico”, es decir, que no ejecuta directamente siempre la misma operación, sino que recibe en un parámetro la sentencia sql y la ejecuta de manera interna. En este caso el problema es el mismo que en las selects abiertas.

Siempre hay que usar procedimientos parametrizados (ejemplo en ASP):

set cmd=Server.CreateObject(“ADODB.Command”)
Set Cmd.ActiveConnection = wConn
Cmd.CommandType = adCmdStoredProc
Set rs= Server.CreateObject(“ADODB.Recordset”)
Cmd.CommandText = “PROCEDIMIENTO_ALMACENADO”
Cmd.Parameters(“@ID”) = request.QueryString(“id”)
set RS=Cmd.Execute()

3. Filtros en la configuración de la web.

En el caso de IIS7 podemos generar un filtro bastante efectivo en toda la página web haciendo uso del archivo web.config, colocando unas cuantas lineas que protejan los parametros hacia ASP y ASP.NET.

Debajo de <system.webServer> colocaremos este código que dejamos, esto filtra en las URL todas las palabras clave listadas, que , salvo excepciones, son usadas solo en entornos de base de datos. Si el servidor IIS encuentra una coincidencia, muestra el error 404 de no encontrado cuando el atacante intente acceder a la página con esos parametros o URL.

<security>
<requestFiltering>
<filteringRules>
<filteringRule name=”SQLInjection2″ scanQueryString=”true”>
<appliesTo>
<add fileExtension=”.asp” />
<add fileExtension=”.aspx” />
</appliesTo>
<denyStrings>
<add string=”–” />
<add string=”/*” />
<add string=”alter” />
<add string=”begin” />
<add string=”create” />
<add string=”cursor” />
<add string=”delete” />
<add string=”drop” />
<add string=”fetch” />
<add string=”insert” />
<add string=”kill” />
<add string=”open” />
<add string=”select” />
<add string=”sys” />
<add string=”table” />
<add string=”union” />
<add string=”update” />
<add string=”top” />
<add string=”iif” />
<add string=”from” />
<add string=” or ” />
<add string=” in ” />
<add string=”chr” />
<add string=”asc(” />
<add string=”curdir” />
<add string=”len(” />
<add string=”ascii” />
<add string=”substring” />
<add string=”length” />
<add string=”@version” />
<add string=”exists” />
</denyStrings>
</filteringRule>
</filteringRules>
</requestFiltering>
</security>

el problema es que puede haber excepciones en las que haya palabras clave que podamos usar en alguna URL, lo que haria que tuviesemos que quitarlas de este filtro inicial.

4. Función de limpieza

Puede no ser técnicamente muy acertada, pero sin duda es muy efectiva, ya que nos permite dejar pasar en primera instancia determinadas palabras y luego filtrarlas en parametros según nuestra conveniencia, en ASP seria tal que así:
function clear_param(texto)

dim texto_final
texto_final=replace(texto, “SELECT”, “”)
texto_final=replace(texto_final, “‘”, “”)
texto_final=replace(texto_final, “UPDATE”, “”)
texto_final=replace(texto_final, “DELETE”, “”)
texto_final=replace(texto_final, “DROP”, “”)
texto_final=replace(texto_final, “UNION “, “”)
texto_final=replace(texto_final, “%”, “&#37;”)
texto_final=replace(texto_final, “%00”, “”)
texto_final=replace(texto_final, ” TOP “, “”)
texto_final=replace(texto_final, ” GROUP “, “”)
texto_final=replace(texto_final, “=”, “”)
‘texto_final=replace(texto_final, “>”, “&#62;”)
‘texto_final=replace(texto_final, “<“, “&#60;”)
texto_final=replace(texto_final, “IIF”, “”)
texto_final=replace(texto_final, “FROM”, “”)
texto_final=replace(texto_final, ” OR “, “”)
texto_final=replace(texto_final, ” AND “, “”)
texto_final=replace(texto_final, ” IN “, “”)
texto_final=replace(texto_final, ” CHR “, “”)
texto_final=replace(texto_final, ” ASC(“, “”)
texto_final=replace(texto_final, ” CurDir “, “”)
texto_final=replace(texto_final, “LEN(“, “”)
texto_final=replace(texto_final, “SHELL”, “”)
texto_final=replace(texto_final, “ASCII”, “”)
texto_final=replace(texto_final, “SUBSTRING”, “”)
texto_final=replace(texto_final, “LENGTH”, “”)
texto_final=replace(texto_final, “version”, “”)
texto_final=replace(texto_final, “exists”, “”)
clear_param=texto_final

End function

una función de este tipo servirá para limpiar un querystring en el caso de que por alguna razón debamos usarlo directamente sobre una select, para complementar el filtro en web.config:

clear_param(request.QueryString(“id”))

5. Bloqueo de IP´s

Como medio de disuasión es interesante si el atacante no es demasiado habil ya que burlar un bloque de Ip es relativamente sencillo con programas para navegación anónima, pero tambien sirve como bandera del ” te hemos visto y estamos preparados” lo que puede hacer que ese hacker se interese por otras webs más faciles que la nuestra. En la página de errores personalizados podemos tener una función que guarde un log con el error y la IP que lo ha producido, si además guardamos los parametros querystring que han producido el fallo podemos identificar los intentos de hacking a la web y la IP del atacante.

Todas estas técnicas de prevención de ataques SQL injection son aplicables en otros lenguajes, servidores web y bases de datos, usando en cada caso su propia sintaxis.

Si te ha servido este post o se nos olvida algo, por favor, deja un comentario y cuéntanos tu experiencia.