Marzo 2007Nos vamos acercando a la recta final del desarrollo de los proyectos, así que habrá que ir comentando un poco como va la cosa. ¿Recuerdan que se comentó que se usarían reglas del firewall en conjunción con ulogd para monitorizar los paquetes que nos interesan? Pues bueno, eso resultó ser un completo fracaso, dado que los plugins de salida que ofrecía ulogd no nos daba toda la información sobre el payload del paquete que nosotros necesitamos (o necesitábamos o pensamos necesitar Total, que hubo que descartarlo y buscarse otra solución (sobre lo cual juraría haber posteado ya en este nuestro blog, pero bueno, debe ser un momento de deja vú o como se diga Nuestro salvador en este aspecto ha sido tcpdump. Este programa es un programa analizador de tráfico de red, en consola. Un wrapper de libpcap, si mal no lo tengo entedido. La cuestión es que durante las últimas dos semanas moví mi foco de trabajo de la interfaz gráfica hacia las entrañas del daemon de reconocimiento de secuencias. Y he hecho un buen trabajo creo, pues he creado la infraestructura que permite tratar la información ofrecida por tcpdump, convertirla a un formato sencillo de utilizar y enviarlo a un sistema de autómatas para la detección de secuencias. Del algoritmo concreto que usarán estos autómatas se encargará Miguel Ángel, pues yo vuelvo a mis interfaces para integrar la comunicación entre el daemon y la interfaz de configuración, hacer un icono de notificación que viva alegremente en el área de notificación (no tan trivial como debería) y supongo que algo más. Así que nada, más noticias pronto.
luisro | General | 27 Marzo, 10:20pm
SharpKnocking.NetfilterFirewall es el namespace donde están todas las clases que he realizado para interactual con iptables. El siguiente fragmento de código es usado para insertar al principio de la cadena input una regla que redirija todos los paquetes a una cadena llamada SharpKnocking-INPUT donde están las reglas que aceptarín o denegarán el paquete en función de si le hemos dado acceso o no. Es un ejemplo de como usar la librería para alterar las reglas del firewall.
//Create rule for adding a new chain NetfilterRule rule = new NetfilterRule(); //Create new chain command NewChainCommand cmd = new NewChainCommand(); cmd.ChainName = this.chainName; //Set in the rule rule.Command = cmd; //Execute FirewallManager.instance.ApplyRule(rule); //Execute in default table named filter this.ruleSet.ExecRule(rule); //Create insert rule to redirect INPUT packets to our chain rule = new NetfilterRule(); //Create insert command InsertRuleCommand iCmd = new InsertRuleCommand(); iCmd = new InsertRuleCommand(); iCmd.RuleNum = 1; iCmd.ChainName = "INPUT"; rule.Command = iCmd; //Create jump option to redirect to our chain JumpOption jopt = new JumpOption(); jopt.Target = RuleTargets.CustomTarget; jopt.CustomTarget = CustomRuleTargets.UserDefinedChain; jopt.CustomTargetName = this.chainName; //Add to rule rule.Options.Add(jopt); //Execute FirewallManager.instance.ApplyRule(rule); //Execute in default table named filter this.ruleSet.ExecRule(rule); //Create rule rule = new NetfilterRule(); //Create append rule command AppendRuleCommand acmd = new AppendRuleCommand(); acmd.ChainName = this.chainName; //Set in the rule rule.Command = acmd; //Create option to accept loopback traffic InInterfaceOption inOpt = new InInterfaceOption(); inOpt.Interface = "lo"; //Add to rule rule.Options.Add(inOpt); //Create jump option with accept target jopt = new JumpOption(); jopt.Target = RuleTargets.Accept; //Add to rule rule.Options.Add(jopt); //Execute FirewallManager.instance.ApplyRule(rule); //Execute in default table named filter this.ruleSet.ExecRule(rule); //Create rule to accept new or related connections rule = new NetfilterRule(); //Create append rule command acmd = new AppendRuleCommand(); acmd.ChainName = this.chainName; //set in the rule rule.Command = acmd; //Load state extension with -m option MatchExtensionOption meop = new MatchExtensionOption(); meop.Extension = MatchExtensions.State; //Add to rule rule.Options.Add(meop); //The previous option causes the extension to be instantiated //Create jump option to ACCEPT //Execute De tal modo que al ejecutar un programa con ese trozo de código para inicializar las líneas nos quedaría el siguiente conjunto de reglas (muestro la salida del comando iptables-save):
# Generated by iptables-save v1.3.5 on Fri Mar 23 18:06:53 2007 *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] : OUTPUT ACCEPT [0:0] :SharpKnocking-INPUT - [0:0] -A INPUT -j SharpKnocking-INPUT -A SharpKnocking-INPUT -i lo -j ACCEPT -A SharpKnocking-INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A SharpKnocking-INPUT -j DROP COMMIT # Completed on Fri Mar 23 18:06:53 2007 Así es como vamos a dejar las reglas del cortafuegos al inicio (también podríamos conservar las existentes e insertar nuestra cadena delante de las existentes). Sobre la marcha podremos ir añadiendo las ips aceptadas antes del drop final de la cadena y puede que incluyamos la opción de insertar nuestrar reglas sin eliminar las existentes.
mangelp | General | 22 Marzo, 10:55am
NetfilterFirewall es el nombre del proyecto, dentro de la solución que hemos creado en monodevelop, donde estamos programando lo necesario para gestionar las reglas a través de iptables. En el momento actual la librería es capaz de crear una jerarquía de objetos que representa al siguiente fichero de configuración de iptables en el formato de iptables-restore:
# Generated by iptables-save v1.3.5 on Thu Jan 18 12:30:46 2007 *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] : OUTPUT ACCEPT [3561:2787384] :RH-Firewall-1-INPUT - [0:0] -A INPUT -j RH-Firewall-1-INPUT -A FORWARD -j RH-Firewall-1-INPUT -A RH-Firewall-1-INPUT -i lo -j ACCEPT -A RH-Firewall-1-INPUT -p icmp -m icmp --icmp-type any -j ACCEPT -A RH-Firewall-1-INPUT -p esp -j ACCEPT -A RH-Firewall-1-INPUT -p ah -j ACCEPT -A RH-Firewall-1-INPUT -d 224.0.0.251 -p udp -m udp --dport 5353 -j ACCEPT -A RH-Firewall-1-INPUT -p udp -m udp --dport 631 -j ACCEPT -A RH-Firewall-1-INPUT -p tcp -m tcp --dport 631 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT -A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited COMMIT # Completed on Thu Jan 18 12:30:46 2007 Aún queda mucho camino por recorrer. Netfilter permite definir dos puntos de extensión para las reglas del firewall (match extensions y "target extensions") y yo he implementado la lógica para soportar eso programáticamente pero sólo he definido algunas de las extensiones que vienen en el paquete de netfilter (porque son bastantes). Así que cualquier regla que las use no podrá ser manipulada adecuadamente y de momento habrá que limitarse a crear reglas con las extensiones soportadas. Estas clases no dependen de otras partes del proyecto así que podrían ser usadas fácilmente por otros proyectos. Si se diera el caso ayudaría mucho a mejorarla que alguien se pusiera a utilizarla. Por lo pronto vamos a centrarnos en la captura y análisis de paquetes para la detección de llamadas y la modificación de reglas para permitir/denegar accesos a los servicios. Me despido y sigo picando código. Saludos.
mangelp | Mono, SharpKnocking | 7 Marzo, 5:22pm
Después de mucho tiempo, más información sobre el progreso de SharpKnocking. Hemos decidido que usaremos ulogd para hacer el registro de paquetes en modo OPRINT, luego este registro de paquetes lo monitorizaremos (salvo desinformación extrema) con un StreamReader en la parte del servidor. En el payload de los paquetes irá el número de paquete, y posiblemente la IP de la fuente encriptada con una clave, aunque tenemos que ver como lo haremos. Para probarlo he ido a meter las reglas en iptables para hacer el fordward a ulogd, pero hoy nuestro firewall preferido tiene un mal día. Pero bueno seguimos en la brecha a ver si lo tenemos a tiempo.
luisro | General | 6 Marzo, 6:38pm
|
Main
Categorías
Posts Recientes
Archivos de Blog
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||
)
)