rx_fugitivo-x

TXDNS TXDNS es un software escaneador de dns, la manera de la cual funciona es implementando miles de consultas al servidor forzando el resultado para que nos de una respuesta positiva, el objetivo de este software es exponer los nombres de dominio a traves de distintas tecnicas: Errores tipograficos Rotacion TLD Ataque de diccionario Fuerza Bruta Para descargar el software puedes ir al sitio oficial: http://txdns.net/content/download.htm El siguiente tutorial esta preparado con fines educativos y como poder defendernos de un ataque.

V.P.N. Redes Privadas Virtuales, son redes remotas que se conectan entre sí de forma segura, usando para esto un medio inseguro como puede ser Internet. Fundamentalmente existen dos tipo de conexiones VPN Red a Red, es un tunel conformado entre dos redes, en cada punta del tunel hay un servidor que se comunica con el otro, una vez autenticado, se forma una red entre ellos y los ordenadores conectados a cada uno de ellos podrán compartir recursos entre sí. RoadWarrior, en este caso, clientes remotos por medio de una aplicación instalada en sus equipos se conectan al servidor, previa asignación de una Ip con la cual se incorporan a la red local. Openvpn, es la aplicación, existente en los repositorios de Ubuntu, que permite la impelmentación de estas redes privadas virtuales. Para poder realizar la instalación y configuración de la aplicación Openvpn, antes de nada habrá que descargar los paquetes necesarios a tal efecto. En este caso, si ambas máquinas funcionan bajo Linux habrá que instalar Openvpn en ambas y configurar una como servidor y otra como cliente. En el caso de que el servidor funcione bajo Linux pero el cliente sea una máquina Windows, habrá que instalarle el cliente adecuado para poder establecer la red virtual. Es necesario instalar de los repositorios openvpn y openssh sudo apt-get install openvpn openssh A continuación, luego de efectuada la instalación, se debe generar la clave privada, esta clave tienen que poseerla tanto el servidor como el cliente, con lo cual, tras generarla en el servidor, hay que colocarla en el directorio correcto del mismo y a su vez copiarla al cliente mediante un medio que no comprometa la seguridad de la clave, tal como por ssh, se hace con los comandos: sudo openvpn --genkey --secret secret.key sudo cp secret.key /etc/openvpn/ sudo scp secret.key ip_del_servidor:/etc/openvpn/ Configuración host to host, se utiliza para que el intercambio de paquetes entre dos máquinas se realice de forma encriptada. Para ello se crea una interfaz virtual con una IP privada a cada extremo. Se tomará como ejemplo la 192.168.2.1 como la IP del servidor y la 192.168.2.2 como la IP del cliente. Cualquier paquete que viaje entre ambas direcciones lo hará encriptado. En el servidor, para editar el archivo /etc/openvpn/server.conf, ejecutamos sudo nano /etc/openvpn/server.conf En el archivo se deben colocar al menos las líneas siguientes: #/etc/openvpn/server.conf # dispositivo de tunel dev tun # ifconfig ip_del_servidor ip_del_cliente ifconfig 192.168.2.1 192.168.2.2 # Clave del servidor secret /etc/openvpn/secret.key #puerto (por defecto el puerto de VPN es el 1194) port 1194 #usuario bajo el cual se ejecutará la VPN ;user nobody ;group nobody # opciones, comprimir con lzo, ping cada 15 segs, verbose 1 (bajo) comp-lzo ping 15 verb 1 En el cliente, para editar el archivo /etc/openvpn/cliente.conf, ejecutamos: sudo nano /etc/openvpn/cliente.conf En el archivo se deben colocar la menos las siguiente líneas: #/etc/openvpn/cliente.conf # IP publica del servidor. En caso de no tener una IP pública fija, optar por opciones como dyndns. remote pfc-server.dyndns.org # puerto port 1194 # dispositivo tunel dev tun # ifconfig ip_del_cliente ip_del_servidor tun-mtu 1500 ifconfig 192.168.2.2 192.168.2.1 # Clave privada, secret.key # Una posible ruta para la key en Windows comentada. #secret "c:Archivos de programabranded vpnconfigkey.txt" secret /etc/openvpn/secret.key # enable LZO compression comp-lzo # ping cada 10 segs ping 10 # compresión lzo comp-lzo # verbose moderado, callar mas de 10 mensajes iguales verb 4 mute 10 Para iniciar el servicio es necesario ejecutar: En el servidor sudo openvpn --config /etc/openvpn/server.conf En el cliente sudo openvpn --config /etc/openvpn/cliente.conf Para permitir el libre tráfico, es conveniente configurar Iptables, ejecutando: sudo echo "1" > /proc/sys/net/ipv4/ip_forward sudo iptables -A INPUT -i tun0 -j ACCEPT sudo iptables -A OUTPUT -i tun0 -j ACCETP sudo iptables -A FORWARD -i tun0 -j ACCEPT En caso de estar el servidor detrás de un router, es necesario redireccionar el puerto 1194 a este, ya que los pedidos llegaran a la ip pública y el router las descartará al no tener ningún servicio corriendo. Una vez funcionando todo, es conveniente crear los scripts con las ordenes para iniciar openvpn y para activar iptables Creando con nano un archivo de texto, por ejemplo: sudo nano vpnstart Y poniendo las líneas: Servidor #!/bin/bash echo Script para inicio de opnevpn openvpn --config /etc/openvpn/server.conf Cliente #!/bin/bash echo Script para inicio de opnevpn openvpn --config /etc/openvpn/cliente.conf Guardarlo como vpnstart.sh Hacerlo ejecutable dandole permisos de ejecución: sudo chmod +x vpnstart.sh Asi para cada grupo de ordenes, copiandolos luego a un directorio de archivos ejecutables, como por ejemplo: sudo cp vpnstart.sh /usr/bin/vpnstart.sh o sudo cp vpnstart.sh /usr/local/bin/vpnstart.sh

Squid es un Servidor Intermediario (Proxy) de alto desempeño, que puede funcionar como Servidor Intermediario (Proxy) y caché de contenido de Red para los protocolos HTTP, FTP, GOPHER y WAIS, Proxy de SSL, caché transparente, WWCP, aceleración HTTP, caché de consultas DNS, filtración de contenido y control de acceso por IP y por usuario. Consiste básicamente en un programa principal como servidor, un programa para búsqueda en servidores DNS, programas opcionales para reescribir solicitudes y realizar autenticación y algunas herramientas para administración y y herramientas para clientes. Al iniciar Squid da origen a un número configurable (5, de modo predefinido a través del parámetro dns_children) de procesos de búsqueda en servidores DNS, cada uno de los cuales realiza una búsqueda única en servidores DNS, reduciendo la cantidad de tiempo de espera para las búsquedas en servidores DNS. No puede ser utilizado como Servidor Intermediario (Proxy) para protocolos como SMTP, POP3, TELNET, SSH, IRC, etc. Si se requiere intermediar para cualquier protocolo distinto a HTTP, HTTPS, FTP, GOPHER y WAIS se requerirá hacer uso de un servidor SOCKS como Dante No se instala por defecto, pero se encuentra en los repositorios de Ubuntu, por lo que puede ser instalado a través de Synaptic, Aptitude o apt-get Configuración Squid utiliza el archivo de configuración localizado en /etc/squid/squid.conf, y se puede editar con el siguiente comando, en modo consola (terminal) sudo gedit /etc/squid/squid.conf Para editar al menos los siguientes parámetros: http_port cache_dir Al menos una Lista de Control de Acceso Al menos una Regla de Control de Acceso httpd_accel_host httpd_accel_port httpd_accel_with_proxy Parámetro http_port Los Puertos Registrados recomendados para Servidores Intermediarios (Proxies) pueden ser el 3128 y 8080 a través de TCP. # You may specify multiple socket addresses on multiple lines. # Default: http_port 3128 http_port 3128 http_port 8080 Si se desea incrementar la seguridad, puede vincularse el servicio a una IP que solo se pueda acceder desde la red local. Considerando que el servidor utilizado posee una IP 10.140.111.1, puede hacerse lo siguiente: # You may specify multiple socket addresses on multiple lines. # Default: http_port 3128 http_port 10.140.111.1:3128 http_port 10.140.111.1:8080 Parámetro cache_mem. El parámetro cache_mem establece la cantidad ideal de memoria para lo siguiente: Objetos en tránsito. Objetos frecuentemente utilizados (Hot). Objetos negativamente almacenados en el caché. De modo predefinido se establecen 8 MB. Si se posee un servidor con al menos 128 MB de RAM, 16 MB es el valor para este parámetro: cache_mem 16 MB Parámetro cache_dir: El parámetro cache_dir se utiliza para establecer que tamaño se desea que tenga el caché en el disco duro para Squid. De modo predefinido Squid utilizará un caché de 100 MB, de modo tal que encontrará la siguiente línea: cache_dir ufs /var/spool/squid 100 16 256 Mientras más grande sea el caché, más objetos se almacenarán en éste y por lo tanto se utilizará menos el ancho de banda. La siguiente línea establece un caché de 700 MB: cache_dir ufs /var/spool/squid 700 16 256 Los números 16 y 256 significan que el directorio del caché contendrá 16 directorios subordinados con 256 niveles cada uno. Parámetro ftp_user. Al acceder a un servidor FTP de manera anónima, de modo predefinido Squid enviará como clave de acceso Squid@. Puede establecerse una dirección de correo especificada como clave de acceso: ftp_user [email protected] Controles de acceso. Las Listas de Control de Acceso definen una red o bien ciertas máquinas en particular. A cada lista se le asignará una Regla de Control de Acceso que permitirá o denegará el acceso a Squid. Listas de control de acceso, se establecen con la siguiente sintaxis: acl [nombre de la lista] src [lo que compone a la lista] Si se desea establecer una lista de control de acceso que abarque a toda la red local, basta definir la IP correspondiente a la red y la máscara de la sub-red. Por ejemplo, si se tiene una red donde las máquinas tienen direcciones IP 10.140.111.n con máscara de sub-red 255.255.255.0, podemos utilizar lo siguiente: acl miredlocal src 10.140.111.0/255.255.255.0 Más conveniente es definir una Lista de Control de Acceso especificando un archivo localizado en cualquier parte del disco duro, y la cual contiene una lista de direcciones IP.: acl permitidos src /etc/squid/permitidos El archivo /etc/squid/permitidos contendría algo como siguiente: 10.140.111.2 10.140.111.3 10.140.111.4 10.140.111.5 10.140.111.6 En caso de querer restringir el acceso de una pc, basta con eliminarla de la lista. Listas de control de acceso: Bloqueo de Dominios de Destino. Es conveniente definir una Lista de Control de Acceso especificando los dominios bloqueados en un archivo localizado en cualquier parte del disco duro, y la cual contiene una lista de los dominios: acl bloqueados dstdomain /etc/squid/bloqueados El archivo /etc/squid/bloqueados contendría algo como siguiente: www.microsoft.com www.ibm.com www.hotmail.com Reglas de Control de Acceso. Las Reglas de control de Aceso definen si se permite o no el acceso hacia Squid. Se aplican a las Listas de Control de Acceso. Deben colocarse en la sección de reglas de control de acceso definidas por el administrador, es decir, a partir de donde se localiza la siguiente leyenda: # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS La sintaxis básica es la siguiente: http_access [deny o allow] [lista de control de acceso] En este ejemplo la regla que establece acceso permitido a Squid a la Lista de Control de Acceso denominada permitidos: http_access allow permitidos La expresión !, significa no. Pueden definirse así respecto de dos listas de control de acceso, lista1 y lista2, que se permite el acceso a Squid a lo que comprenda lista1 excepto aquello que comprenda lista2: http_access allow lista1 !lista2 Esta regla es útil cuando se tiene un gran grupo de IP dentro de un rango de red al que se debe permitir acceso, y otro grupo dentro de la misma red al que se debe denegar el acceso. Aplicando Listas y Reglas de control de acceso. Considerando como ejemplo que se dispone de una red 10.140.111.0/255.255.255.0, si se desea definir toda la red local, utilizaremos la siguiente línea en la sección de Listas de Control de Acceso: acl todalared src 10.140.111.0/255.255.255.0 Listas de Control de Acceso: definición de una red local completa # Recommended minimum configuration: acl all src 0.0.0.0/0.0.0.0 acl manager proto cache_object acl localhost src 127.0.0.1/255.255.255.255 acl todalared src 10.140.111.0/255.255.255.0 A continuación procedemos a aplicar la regla de control de acceso: http_access allow todalared Reglas de control de acceso: Acceso a una Lista de Control de Acceso. # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS http_access allow localhost http_access allow todalared http_access deny all La regla http_access allow todalared permite el acceso a Squid a la Lista de Control de Acceso denominada todalared, la cual está conformada por 10.140.111.0/255.255.255.0. Esto significa que cualquier máquina desde 10.140.111.1 hasta 10.140.111.254 podrá acceder a Squid. Si solo se desea permitir el acceso a Squid a ciertas direcciones IP de la red local, deberemos crear un archivo que contenga dicha lista, en modo consola ejecutar sudo gedit /etc/squid/listas/redlocal Incluir las direcciones IP que desea confirmen la Lista de Control de acceso; 10.140.111.1 10.140.111.4 10.140.111.17 10.140.111.19 10.140.111.21 Denominaremos a esta lista de control de acceso como redlocal: acl redlocal src /etc/squid/listas/redlocal Listas de Control de Acceso: definición de una red local completa # Recommended minimum configuration: acl all src 0.0.0.0/0.0.0.0 acl manager proto cache_object acl localhost src 127.0.0.1/255.255.255.255 acl redlocal src /etc/squid/listas/redlocal Aplicar la regla de control de acceso: http_access allow redlocal Reglas de control de acceso: Acceso a una Lista de Control de Acceso. # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS http_access allow localhost http_access allow redlocal http_access deny all La regla http_access allow redlocal permite el acceso a Squid a la Lista de Control de Acceso denominada redlocal, la cual está conformada por las direcciones IP especificadas en el archivo /etc/squid/listas/redlocal. Esto significa que cualquier máquina no incluida en /etc/squid/listas/redlocal no tendrá acceso a Squid. Parámetro chache_mgr. De modo predefinido, si algo ocurre con el caché, se envia un mensaje de aviso a la cuenta webmaster del servidor, puede especificarse una distinta si se considera conveniente; cache_mgr [email protected] Caché con aceleración. Cuando un usuario hace petición hacia un objeto en Internet, este es almacenado en el caché de Squid. Si otro usuario hace petición hacia el mismo objeto, y este no ha sufrido modificación alguna desde que lo accedió el usuario anterior, Squid mostrará el que ya se encuentra en el caché en lugar de volver a descargarlo desde Internet. Proxy Acelerado En la sección HTTPD-ACCELERATOR OPTIONS deben habilitarse los siguientes parámetros: httpd_accel_host virtual httpd_accel_port 0 httpd_accel_with_proxy on Para crear el directorio cache, en modo consola ejecutamos; sudo /usr/local/squid/sbin/squid -z Iniciar, reiniciar y añadir el servicio al arranque del sistema. Para iniciar por primera vez Squid en modo consola: sudo service squid start Para reiniciar en modo consola ejecutar: sudo service squid restart Para que Squid se inicie de manera automática al inicio el sistema, en modo consola ejecutar: sudo chkconfig squid on Cualquier error al inicio de Squid solo significa que hubo errores de sintaxis, errores de teclado o de las rutas hacia los archivos de las Listas de Control de Acceso. Para realizar el diagnóstico de problemas indicándole a Squid que vuelva a leer configuración, lo cual devuelve los errores que existen en el archivo /etc/squid/squid.conf, en modo consola ejecutar: sudo service squid reload En caso de errores graves que no permiten iniciar el servicio, examinar el contenido del archivo /var/log/squid/squid.out ejecutando en consola: less /var/log/squid/squid.out Ajustes para el muro corta-fuegos. Re-direccionamiento de peticiones a través de iptables y Firestarter. Para dar salida transparente hacia Internet a ciertos servicios yo al mismo tiempo re-direccionar peticiones hacia servicio HTTP para pasar a través del el puerto donde escucha peticiones Squid (8080), de modo que no haya salida alguna hacia alguna hacia servidores HTTP en el exterior sin que ésta pase antes por Squid, los protocolos HTTPS, FTP, GOPHER ni WAIS, deben ser filtrados a través del NAT. El re-direccionamiento se hace a través de iptables. Suponiendo que la red local se accede a través de una interfaz eth1, el siguiente esquema ejemplifica un re-direccionamiento: sudo /sbin/iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 80 -j REDIRECT --to-port 8080 Lo anterior, que requiere un guión de cortafuegos funcional en un sistema con dos interfaces de red, hace que cualquier petición hacia el puerto 80 (servicio HTTP) hecha desde la red local hacia el exterior, se re-direccionará hacia el puerto 8080 del servidor. Utilizando Firestarter, la regla anteriormente descrita se añade en el archivo /etc/firestarter/user-post. sudo gedit /etc/firestarter/user-post y se agrega la línea /sbin/iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 80 -j REDIRECT --to-port 8080