Seguridad informática

Profesor: José Luis García Cerpas

Alumno: Eduardo Antonio Quiroz Salas Registro: 17310258

Tarea 3.6: Métodos de remediación

Fecha: 04/06/2021
Introducción
Sufrir ataques informáticos está a la orden del día: según Google, más de un 15%
de los usuarios de internet han denunciado haber experimentado el robo de sus
cuentas de email o de sus redes sociales y muchos otros nunca llegan a
reportarlo. Google dice que puso en práctica lo aprendido para evitar el abuso de
67 millones de cuentas vulnerables. A través de esas cuentas, sus clientes no sólo
acceden a Gmail, sino también a otros servicios, como YouTube.
Métodos más comunes de hacking
Ataque de contraseña: Al acceder a la contraseña de una persona, un atacante
puede acceder a datos y sistemas confidenciales o críticos, incluida la capacidad de
actualizar y controlar dichos datos y sistemas. Los atacantes de contraseñas utilizan
una miríada de métodos para identificar una contraseña individual, incluyendo el
uso de ingeniería social, obtener acceso a una base de datos de contraseñas,
probar la conexión de red para obtener contraseñas no cifradas, o simplemente
adivinando.
El último método mencionado se ejecuta de una manera sistemática conocida como
"ataque de fuerza bruta". Un ataque por fuerza bruta emplea un programa para
probar todas las variantes y combinaciones posibles de información para adivinar la
contraseña.
¿Cómo podemos protegernos de éstos ataques?
 Bloqueos de cuenta después de intentos fallidos: Implementar un bloqueo de
cuenta después de varios intentos fallidos de inicio de sesión no es efectivo,
ya que hace que tu servidor sea presa fácil de ataques de denegación de
servicio. Sin embargo, si se realiza con retrasos progresivos, este método se
vuelve mucho más efectivo.
 Hacer que el usuario root sea inaccesible a través de SSH: Los intentos de
fuerza bruta de SSH a menudo se llevan a cabo en el usuario raíz de un
servidor. Asegúrate de hacer que el usuario root sea inaccesible a través de
SSH editando el archivo sshd_config. Establece las opciones ‘DenyUsers
root’ y ‘PermitRootLogin no’.
 Modificar el puerto predeterminado: La mayoría de los ataques SSH
automáticos se intentan en el puerto predeterminado 22. Por lo tanto, ejecutar
sshd en un puerto diferente podría ser una forma útil de lidiar con los ataques
de fuerza bruta.
 Usa CAPTCHA: Todos nos acostumbramos a ver CAPTCHA en Internet. A
nadie le gusta tratar de darle sentido a algo que parece haber sido
garabateado por un niño de dos años, pero herramientas como CAPTCHA
hacen que los bots automáticos sean ineficaces.
  Limita los inicios de sesión a una dirección IP especificada o rango: Si
permites el acceso solo desde una dirección IP o rango designado, los
atacantes de fuerza bruta deberán trabajar arduamente para superar ese
obstáculo y obtener acceso a la fuerza.
 Emplear autenticación de 2 factores (2FA): La autenticación de dos factores
es considerada por muchos como la primera línea de defensa contra los
ataques de fuerza bruta. La implementación de una solución de este tipo
reduce en gran medida el riesgo de una posible violación de datos.
 Usa URL de inicio de sesión únicas: Crea URL de inicio de sesión únicas
para diferentes grupos de usuarios. Esto no detendrá un ataque de fuerza
bruta, pero la introducción de esa variable adicional hace que las cosas sean
un poco más desafiantes y le lleven más tiempo al atacante.
 Controla los registros de tu servidor: Asegúrate de analizar tus archivos de
registro diligentemente. Los administradores saben que los archivos de
registro son esenciales para mantener un sistema. Lo más obvio es una
política de contraseña segura. Cada aplicación web o servidor público debe
exigir el uso de contraseñas seguras. Por ejemplo, las cuentas de usuario
estándar deben tener al menos ocho letras, un número, letras mayúsculas y
minúsculas y un carácter especial. Además, los servidores deben requerir
cambios frecuentes de contraseña.
Inyección SQL: ocurre cuando un atacante inserta código malicioso en un servidor
utilizando el lenguaje de consulta del servidor (SQL), forzando al servidor a entregar
información protegida, enviando código malicioso a un comentario o cuadro de
búsqueda del sitio web no protegido. Cuando un comando SQL utiliza un parámetro
en lugar de insertar los valores directamente, puede permitir que el módulo de
servicio ejecute consultas maliciosas. Además, el intérprete SQL utiliza el parámetro
sólo como datos, sin ejecutarlo como código.
Existen ciertos principios a considerar para proteger nuestras aplicaciones de un
SQL Injection:
No confiar en la entrada del usuario:

 Verificar tanto el tamaño y como el tipo de los datos de las entradas de

usuario:
o Evitando los siguientes tipos caracteres de riesgo para el gestor de
datos:
 El delimitador de consultas: Punto y coma (;)
 Delimitador de datos de tipo cadena de caracteres: Comilla
sencilla (').
 Delimitadores de cometario: Guión doble (--) y "/*..*/" en el
caso de SQL Server.
 Nota: En lugar de evitar los caracteres peligrosos, otro modo
de protegernos es aceptar sólo los caracteres inofensivos.
 o Evitando las cadenas con el inicio de nombres de las tablas y los
procedimientos del sistema: "sys" y "xp_" en el caso de SQL Server.
Así como las siguientes palabras: AUX, CLOCK$, COM1, COM8,
CON, CONFIG$, LPT1, LPT8, NUL y PRN
o Utilizar de preferencia controles con valores predefinidos o discretos
tales como cuadros de lista, cuadros combinados, de verificación,
etc. en lugar de cuadros de texto.
 Verificar cualquier tipo de entrada, no sólo lo introducido en los controles IU
sino también aquellas que no son visibles, como parámetros de entrada y
campos tipo hidden de las páginas web.
 Realizar la verificación en todos los niveles y capas de la aplicación, ya que
si sólo protegemos la capa de presentación somos vulnerables a que un
atacante salte a la siguiente capa y realizar su ataque.

No utilizar sentencias SQL construidas dinámicamente.

Aunque de hecho es mejor utilizar Procedimientos Almacenados siempre que sea

posible, así como también:

 Utilizar Parámetros al llamar Procedimientos Almacenados.

Dim myCommand As SqlDataAdapter = _

New SqlDataAdapter("AuthorLogin", myConnection)
myCommand.SelectCommand.CommandType = _
CommandType.StoredProcedure
Dim parm As SqlParameter = _
myCommand.SelectCommand.Parameters.Add("@LoginId", _
SqlDbType.VarChar,11)
parm.Value = Login.Text

No utilizar cuentas con privilegios administrativos.

 Ejecutar las sentencias SQL o invocar Procedimientos Almacenados con

una cuenta con privilegios mínimos. Nunca emplear 'sa' en el caso de MS
SQL Server. Pero de preferencia además...
 Conceder permisos de ejecución únicamente a Procedimientos
Almacenados propios desde los cuales, a manera de "wraper", se realicen
las consultas a las Tablas de Usuario y llamados a los Procedimientos
Almacenados del Sistema que se requieran en las aplicaciones, y negar el
acceso directo a éstos últimos y a las Tablas de Usuario.
No proporcionar mayor información de la necesaria.

 No exponer al usuario final los mensajes de error devueltos por el gestor de

la base de datos, para no brindar mayor información que sea útil al
atacante.
 Implementar un sistema de gestión de errores que notifique del mismo
únicamente a los administradores de la aplicación y el gestor de la base de
datos. Por ejemplo, para el caso de una aplicación web, establecer en el
archivo de configuración web (Web.Config) el valor del atributo debug del
elemento compilation en False y el atributo mode del elemento
customErrors en On o en su defecto en RemoteOnly.

Secuencia de comandos (XSS): El código malicioso se une al contenido dinámico

que se envía al navegador de la víctima. Normalmente, este código malicioso
consiste en código Javascript ejecutado por el navegador de la víctima, pero puede
incluir Flash, HTML y CSS.
Existen dos tipos de ataques XSS:
 XSSPersistente (StoredXSS): ocurre en aquellas partes donde un usuario
introduce datos que puedne ser vistos por otros usuarios. Es decir, cuando
se hace uso de una base de datos o fichero de texto, cuando se almacena
información. Ejemplos de esto son mensajes en foros, comentarios en wikis,
blogs, etc. Aquí lo que debes hacer es comprobar esa inserción de datos en
busca de palabras y caracteres no permitidos a fin de evitar el ataque XSS.
 XSSReflejado(ReflectedXSS): se da cuando se incluyen los scripts en los
parámetros de una petición web. Por ejemplo, cuando un usuario le pasa un
link a tu web a otro, pero ese link contiene un script, o bien un usuario
introduce un script en uno de esos parámetros. En este caso hay que
comprobar las direcciones y los parámetros que recibes a fin de evitar el
ataque. Esto no es lo mismo que phising, no hay que confundirlo.
La forma de proteger el sitio contra XSS es filtrando los datos de entrada que
introduce el usuario, verificando que no lleven etiquetas no deseadas. para ello, lo
mejor es hacer una lista blanca (una lista de cosas permitidas que puede introducir
el usuario) en vez de una lista negra (cosas no permitidas). En este caso, si usas
listas blancas, si te olvidas de algo, simplemente el usuario no podrá introducirlo, en
el caso contrario, puede que te olvides alguna etiqueta y la página sea vulnerable.
Otra forma de protegerse sería utilizando mod_security de Apache, tendrías que
instalarlo y configurarlo para que filtrase todas esas peticiones, pero es
recomendado mejor hacerlo de la primera manera para poder controlar tu todo el
flujo de una mejor manera por código. Esto te serviría para cualquier lenguaje de
programación.
Conclusiones
Para prevenir un ataque, así como para realizar pruebas de vulnerabilidad contra
el mismo en nuestras aplicaciones, no debemos olvidar que cualquier aplicación
que permita una "entrada" que sirva como vulnerabilidad. En este momento
muchas personas piensan que las vulnerabilidades no son peligrosas, pero están
equivocadas en gran medida. Fue Interesante aprender sobre los ataques más
comunes y su forma de defenderse de dichas amenazas.