Re: secured server policies
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. See -- http://www.freesoft.org/CIE/Topics/77.htm 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 You should also allow some ICMP types. I think so. What ICMP types would you set? [...] 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? Regards Ansgar Wiechers I'm not an expert. :) I'm sorry, my English is not good... Regards Daniel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: secured server policies
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]
Re: secured server policies
On Sat, 2008-11-08 at 19:03 +, 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. See -- http://www.freesoft.org/CIE/Topics/77.htm No, it's not exactly true. You need tcp in the case when the answer is too big to fit in an UDP packet. If this happen, the client should reconnect using tcp. From rfc 1035: 4.2.1. UDP usage Messages sent using UDP user server port 53 (decimal). Messages carried by UDP are restricted to 512 bytes (not counting the IP or UDP headers). Longer messages are truncated and the TC bit is set in the header. smime.p7s Description: S/MIME cryptographic signature
Re: secured server policies
SZALAY Attila wrote: On Sat, 2008-11-08 at 19:03 +, 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. See -- http://www.freesoft.org/CIE/Topics/77.htm No, it's not exactly true. You need tcp in the case when the answer is too big to fit in an UDP packet. If this happen, the client should reconnect using tcp. From rfc 1035: 4.2.1. UDP usage Messages sent using UDP user server port 53 (decimal). Messages carried by UDP are restricted to 512 bytes (not counting the IP or UDP headers). Longer messages are truncated and the TC bit is set in the header. Thanks for your explanation. I will read more the RFC's. :) Daniel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: secured server policies
Ansgar Wiechers wrote: 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. Hummm, I thought that ESTABLISHED,RELATED worked with SYN, SYN/ACK, etc... Please, do you know where do I learn more about that? [...] 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. Very good explanation. Thanks. Regards Ansgar Wiechers -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: secured server policies
On 2008-11-08 daniel wrote: Ansgar Wiechers wrote: On 2008-11-08 daniel wrote: 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. Hummm, I thought that ESTABLISHED,RELATED worked with SYN, SYN/ACK, etc... Please, do you know where do I learn more about that? Unless you are capable of reading (and understanding) the netfilter source code, I'd suggest to start with the iptables man-page and the documentation on netfilter.org, and then experiment on your own. Logging rules will allow you to check what is or isn't matched as well as follow the route of packets going through the chains. IMHO practice (in a test environment) is the best way to get a feel for how netfilter works. 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]