Le 28/04/2015 10:31, Lukas Grunwald a écrit : > Hi, > > On 27.04.2015 16:40, Thibaut Pouzet wrote: >> Hello Lukas, >> >> I'm not sure disabling conntrack on the firewall is a good solution to >> this problem... Or a good idea either. > > It is , it´s the only solution to be able to scan in a useful time frame. > First you need to understand how TCP/IP works and how your network > landscape looks like, then you will see ;-) I don't understand what you are telling me there
> >> Surely this is a solution that >> works, but if I was willing to disable it, I would not have seeked help >> here in the first place. > > You have to understand how connection tracking is working, and why this > will not provide you any benefit here. > For every TCP-SYN your netfilter is allocating a connection, if you scan > one host with all TCP you will allocate 65535 places in the table. > If you next firewall is dropping that packet, you need to wait until the > timout is cleaning the table. > > That is why you need to understand how this is working. If you scann > without filling up the table, you might miss many vulnerabilities. I disagree on this point. If I fill the table, "random" packets will be dropped on the firewall, and this is a case where I might miss vulnerabilities as payloads might be dropped while they should not be. What you're telling me here seems to be in contradiction with what you are telling below, so I don't really understand your answer anyway. This might be coming from the fact that English is not my native language. > >> >> We managed today to tune nmap through a scan-config to be less >> aggressive, but this is only nmap, and another tool might still be too >> aggressive. I was looking for a more global configuration, something >> like the "low impact" scanning profile you can see in Qualys for >> instance. > Sure you can limit the amount of sessions, but this will limit the > amount of results as well. > Let me have my cake and eat it, too will not work in this scenario. > >> >> Cheers, >> > > Anyway, I found an acceptable solution (for us) within iptables itself with this sort of rules : iptables -t raw -A PREROUTING -i $IFACE_1 -o $IFACE_2 -s 192.168.0.1 -d 192.168.1.1 -j NOTRACK iptables -t filter -A FORWARD -i $IFACE_1 -o $IFACE_2 -s 192.168.0.1 -d 192.168.1.1 -j ACCEPT iptables -t raw -A PREROUTING -i $IFACE_2 -o $IFACE_1 -s 192.168.1.1 -d 192.168.0.1 -j NOTRACK iptables -t filter -A PREROUTING -i $IFACE_2 -o $IFACE_1 -s 192.168.1.1 -d 192.168.0.1 -j ACCEPT It transforms the firewall into an ACL engine only for this specific flow, and keeps the rest of the firewalling stateful and clean. This is not an OpenVAS-related solution, but this might help someone in the future... Cheers, -- Thibaut Pouzet Lyra Network Ingénieur Systèmes et Réseaux (+33) 5 31 22 40 08 www.lyra-network.com _______________________________________________ Openvas-discuss mailing list [email protected] https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/openvas-discuss
