evitar mapeos de red

Sebastian Veloso Varas sveloso en sevelv.cl
Vie Sep 19 14:01:20 CLT 2008


Horst H. von Brand escribió:
> Sebastian Veloso Varas <sveloso en sevelv.cl> wrote:
>   
>> Horst H. von Brand escribió:
>>     
>>> Sebastian Veloso Varas <sveloso en sevelv.cl> wrote:
>>>       
>>>> Horst H. von Brand escribió:
>>>>         
>>>>> Sebastian Veloso Varas <sveloso en sevelv.cl> wrote:
>>>>>           
>
> [...]
>   
>>>>>>           Primero que todo, que tipo de scans estas realizando por nmap
>>>>>> u otra herramienta hacia la red 10? Yo sugiero que controles los tipos
>>>>>> de ataques con PortScan Attack Detector psad
>>>>>> (http://cipherdyne.org/psad/). Una de las "debilidades" de Iptables es
>>>>>> esta.
>>>>>>             
>
>   
>>>>> Cual debilidad? Si el port esta disponible, esta disponible. Y por muy
>>>>> creativo que te pongas en ocultarlo a "usuarios ilegitimos", cualquiera
>>>>> se puede hacer pasar por usuario legitimo facilmente y pasar igual.
>>>>>           
>
>   
>>>>> Ocultar ports disponibles "para scans" de nada sirve, por lo demas:
>>>>> Supongo que habran visto el incesante martilleo a SSH, incluso a
>>>>> maquinas que no tienen SSH. Para un atacante con suficientes recursos
>>>>> a la mano (botnet) es mas rentable simplemente tirarse en picada
>>>>> contra todo lo que tenga direccion IP que darse el trabajo de revisar
>>>>> antes.
>>>>>           
>
>   
>>>> No me refiero a los ports abiertos, mas bien me refiero evitar el ataque
>>>> en si.
>>>>         
>
>   
>>> Bloquea acceso al port. Asegurate que los programas que dan a la red sean
>>> solo los necesarios, esten al dia, bien configurados. Cualquier otra cosa
>>> es falsa sensacion de seguridad (si, es bastante facil que se te cuele un
>>> malandrin a la red local; despues de eso, toda la proteccion contra "el
>>> frio e impersonal mundo de Internet" vale hongo). Sin contar que (segun a
>>> que estadistica quieras creer) entre un 85 y 95% de los ataques tienen
>>> alguna componente interna...
>>>       
>
>   
>> Si pero creo que lo estas enfocando mas a la solucion de red,
>>     
>
> "Solucion de red" no hay. Si estas en red, eres alcanzable (esa es la idea
> de la red!); si lo alcanzable es vulnerable, estas matriculado (o lo estaras
> pronto). Solo es valido en el (improbable) caso en que tienes estricto
> control sobre la red desde la cual es alcanzable.
>
>   
>>                                                               y no tan
>> aplicativa (aunque esa tarea me dirás, debe ser corregida en el servicio
>> publicado y no en el firewall =) ).
>>     
>
> Bingo!
>
>   
>>                                     Muchos errores y vulnerabilidades
>> las explotan por fallas de aplicacion, por ende, obviamente a parte de
>> mantener los servicios publicados lo mas seguros.
>>     
>
> No "muchos", "todos"! Salvo los casos de configuracion idiota, que no son
> tan infrecuentes tampoco...
>
>   
>>>>        La idea de un firewall aparte de la publicacion segura de
>>>> servicios, es mantener un mecanismo capaz de repeler ataques a dichas
>>>> maquinas; los fabricantes de firewalls implementan distintas formas de
>>>> hacerlo, mediante reglas de control de conexiones para evitar ataques
>>>> indebidos o tecnologias propietarias que realicen esta funcion.
>>>>         
>
>   
>>> No. /Cobran/ por eso, lo usan como justificacion para que les compres sus
>>> (sobrevaluadas) "soluciones", y lo usan como herramienta para mantener
>>> cautivos a los clientes. De pocazo sirve, en la practica.
>>>       
>
>   
>> A veces, por muy sobreevaluadas, se nota la diferencia y efectividad
>> entre ellas.....
>>     
>
> No creo que haya tanta. Salvo que tengas una red de Giga, un tarro de lo
> mas picante se la puede sin problemas corriendo un Linux configurado como
> la gente.
>
>   


Me refería a las tecnologias de filtrado y seguridad de las
competencias, mas que sobreevaluado en prestaciones o throughput. Cada
propietario de productos de seguridad tiene sus mecanismos
personalizados en el mercado para entregar seguridad en nuestras redes y
servicios.



>>>> Un mecanismo mas eficaz de seguridad medianamente eficaz siempre, a mi
>>>> parecer, debe ser un arquitectura de denegacion de acceso indebidos
>>>> (firewall)
>>>>         
>
>   
>>> No. La mejor manera de impedir accesos no debidos es que /no existan/ los
>>> accesos. Cualquier otra cosa es (cuando mucho) una mitigacion (mas o menos
>>> debil) del problema. Ver los comentarios arriba.
>>>       
>
>   
>>>>            y un mecanismo de prevención de ataques y riesgos de las redes
>>>> (IDS/IPS).
>>>>         
>
>   
>>> Prevencion de ataques conocidos? Corregir lo atacado. Prevenir ataques
>>> desconocidos? Auditoria del codigo, pruebas, configuracion cuidadosa,
>>> monitoreo. IPS? Puedes meterte en lios legales si inicias "accion
>>> defensiva"... 
>>>       
>
>   
>> Está claro que lo obvio es permitir solamente lo necesario hacia el
>> exterior. El firewall estrictamente debe trabajar asi. Pero que pasa en
>> el caso de  que por ejemplo por un error de aplicacion (ya sea un error
>> de programacion, o un bug sin intencion) no sea percibido por el
>> sysadmin?
>>     
>
> Si esta en la red, estas frito. No hay filtro que te pueda salvar si hay
> acceso.
>
>   
>>           O simples tecnicas como p.ej evitar denegacion de servicios
>> (de la mano con una buena configuracion del servidor obviamente)? Pienso
>> que si mientras mas "obstaculos" le pones al individuo que quiere
>> acceder de la forma que sea a un sistema, menos riesgos se corre;
>>     
>
> Cierto. Lo que digo es que no puedes /confiar/ en eso, y por tanto debes
> concentrarte en otras partes.
>
>   
>> inclusive como administrador sirve para estar al tanto de que esta
>> ocurriendo o de que forma me estan tratando de atacar (tal como un
>> Honeypot).
>>     
>
> Lo de "saber de que forma me intentan atacar" es morbo, nada mas. Para
> revistas de farandula, salvo que tengas los recursos para realmente hacer
> algo al respecto.
>   


No creo que haya algo de malo saber y mediante los simples logs de los
sistemas de seguridad determinar que no estan tratando de vulnerar.
Aunque muchos los dejan pasar por alto, o los dejan de archivo en los
reportes diarios de  seguridad (tipico en empresas de servicios jejeje)
en mi caso personal me ha ayudado a determinar acciones correctivas de
suma importancia.

-- 

Sebastián Veloso Varas
Seguridad y Comunicaciones
E-Mail : sveloso en sevelv.cl
Móvil : 9-4968717
WebSite : http://www.sevelv.cl



Más información sobre la lista de distribución Linux