On 2008-11-08 daniel wrote: > Ansgar Wiechers wrote: >> On 2008-10-31 daniel wrote: >>> iptables -A OUTPUT -p udp --dport 53 -j ACCEPT >>> iptables -A INPUT -p udp --sport 53 -m state --state ESTABLISHED,RELATED -j >>> ACCEPT >> >> You need TCP for fully functional DNS as well. > > Why do I need TCP for fully functional DNS? > TCP must be used for zone transfers.
TCP is also used when the response to a name lookup exceeds 512 bytes (the size of a UDP packet). > In the rule iptables -A INPUT -p udp --sport 53 -m state --state > ESTABLISHED,RELATED -j ACCEPT, the module state is not necessary, > because it uses UDP, although it works. > > So, the correct form is: > iptables -A INPUT -p udp -j ACCEPT Wrong. netfilter does keep track even of UDP connections, so a rule checking for state ESTABLISHED,RELATED will match only those packets that relate to some other connection. Which usually is what you want at that point. >> You should also allow some ICMP types. > > I think so. What ICMP types would you set? I usually allow these types: iptables -N ICMP iptables -A ICMP -p icmp --icmp-type destination-unreachable -m state \ --state RELATED -j ACCEPT iptables -A ICMP -p icmp --icmp-type source-quench -m state \ --state RELATED -j ACCEPT iptables -A ICMP -p icmp --icmp-type parameter-problem -m state \ --state RELATED -j ACCEPT iptables -A ICMP -p icmp --icmp-type time-exceeded -m state \ --state RELATED -j ACCEPT iptables -A ICMP -p icmp --icmp-type echo-reply -m state \ --state ESTABLISHED -j ACCEPT iptables -A ICMP -p icmp --icmp-type echo-request -m state --state NEW \ -m limit --limit 10/s --limit-burst 50 -j ACCEPT >> [...] >>> iptables -A INPUT -p tcp -m multiport --dports 22,80 -m state --state NEW >>> -j ACCEPT >>> iptables -A OUTPUT -p tcp -m multiport --sports 22,80 -m state --state >>> ESTABLISHED,RELATED -j ACCEPT >> >> What reasons are there to have --sport in the ESTABLISHED,RELATED rule? >> Making rules too specific will adversely affect maintenance. > > I agree with you. But I think if a process on that host (i.e. trojan > horse on the door 12345) tries to connect to an external host, it will > not work. > Is it correct? To a degree. First of all: when a trojan horse is running on your system, your security is already compromised and you should immediately take the box off the 'net, investigate how the incident happened, and then reinstall the system. That said, yes, with those rules a process probably won't be able to connect outbound. However, that's not because of the ports specified there, but because the rule in the OUTPUT chain allows only packets of already established connections, and the rule in the INPUT chain allows only new inbound connections. Of course I'm assuming here that a) no other rules in either chain allows packets in or out, and b) the default policies for both chains are set to DROP. If you're worried about response packets from connections to some program listening on port 12345 being allowed by an ESTABLISHED,RELATED rule: I'd suggest you rather ask yourself why the connection to port 12345 could be established in the first place. Regards Ansgar Wiechers -- "The Mac OS X kernel should never panic because, when it does, it seriously inconveniences the user." --http://developer.apple.com/technotes/tn2004/tn2118.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
