On Sep 09, 2010, Sim?n wrote: > Hi, > I have that rule: > > Chain INBOUND (1 references) > target prot opt source destination > ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state > RELATED,ESTABLISHED > ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 state > RELATED,ESTABLISHED > > But I have sent, in my mail, only the LOG rules because the warning was > about this. > Sorry, but I see now that I didn't send the explanation of warning: :-[ > > [-] You may just need to add a default logging rule to the INPUT chain on > xxxx. For more information, see the file "FW_HELP" in > the psad sources directory or visit: > > http://www.cipherdyne.org/psad/docs/fwconfig.html > > I have received this warning only one time. Perhaps it was a temporary > error of iptables or psad, no?
Did you happen to receive that email after a reboot? If so, it is possible that psad is not being executed until after the iptables policy is instantiated (by the init scripts). If you manually restart psad with the init script do you receive the warning? Thanks, --Mike > Regards. > > El 09/09/10 14:17, Michael Rash escribió: > > On Aug 30, 2010, Sim?n wrote: > > > >> Hi, > > Hello, > > > >> I have received this warning today: "[psad-status] firewall setup > >> warning on xxxxxx!". It's the first time and I use psad for over a year. > >> My iptables LOG policy is the next: > >> _________________________________________________________________________________________ > >> $ sudo iptables -L > >> > >> Chain INPUT (policy DROP) > >> target prot opt source destination > >> ...... > >> LOG_FILTER all -- anywhere anywhere > >> LOG all -- anywhere anywhere LOG > >> level info prefix `Unknown Input' > >> > >> Chain FORWARD (policy DROP) > >> target prot opt source destination > >> ...... > >> LOG_FILTER all -- anywhere anywhere > >> LOG all -- anywhere anywhere LOG > >> level info prefix `Unknown Forward' > >> > >> Chain OUTPUT (policy DROP) > >> target prot opt source destination > >> ...... > >> LOG_FILTER all -- anywhere anywhere > >> LOG all -- anywhere anywhere LOG > >> level info prefix `Unknown Output' > >> > >> Chain LOG_FILTER (5 references) > >> target prot opt source destination > >> > >> Chain LSI (52 references) > >> target prot opt source destination > >> LOG_FILTER all -- anywhere anywhere > >> LOG tcp -- anywhere anywhere tcp > >> flags:FIN,SYN,RST,ACK/SYN limit: avg 1/sec burst 5 LOG level info > >> prefix `Inbound ' > >> LOG tcp -- anywhere anywhere tcp > >> flags:FIN,SYN,RST,ACK/RST limit: avg 1/sec burst 5 LOG level info > >> prefix `Inbound ' > >> LOG icmp -- anywhere anywhere icmp > >> echo-request limit: avg 1/sec burst 5 LOG level info prefix `Inbound ' > >> LOG all -- anywhere anywhere limit: > >> avg 5/sec burst 5 LOG level info prefix `Inbound ' > >> ...... > >> > >> Chain LSO (0 references) > >> target prot opt source destination > >> LOG_FILTER all -- anywhere anywhere > >> LOG all -- anywhere anywhere limit: > >> avg 5/sec burst 5 LOG level info prefix `Outbound ' > >> ...... > >> > >> _________________________________________________________________________________________ > >> > >> Isn't it correct? > > It looks to me as though you don't have any iptables rules that accept > > packets > > based on connection state. For example, in the INPUT chain, you should have > > a rule like this: > > > > # iptables -nL INPUT |grep state |grep ACCEPT > > ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state > > RELATED,ESTABLISHED > > > > This will accept all packets that are part of established connections. > > > > Thanks, > > > > --Mike > > > >> Regards. > > ------------------------------------------------------------------------------ > > This SF.net Dev2Dev email is sponsored by: > > > > Show off your parallel programming skills. > > Enter the Intel(R) Threading Challenge 2010. > > http://p.sf.net/sfu/intel-thread-sfd > > _______________________________________________ > > psad-discuss mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/psad-discuss > > ------------------------------------------------------------------------------ > This SF.net Dev2Dev email is sponsored by: > > Show off your parallel programming skills. > Enter the Intel(R) Threading Challenge 2010. > http://p.sf.net/sfu/intel-thread-sfd > _______________________________________________ > psad-discuss mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/psad-discuss ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ psad-discuss mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/psad-discuss
