Re: secured server policies
On Sat, Nov 08, 2008 at 11:28:43PM +0100, SZALAY Attila wrote: 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. unless EDNS is used (or enforced) - RFC 2671. -- paolo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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]
Re: secured server policies
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. You should also allow some ICMP types. [...] 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. 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
Alexandr Shurigin wrote: hello huys I have trouble. i readed and readed and think better i ask professionals :) I have server which must have shared only 80 and 22 ports. all other ports i want to close by iptables. Which rules i must use ? Thanks. have a good day :) -- С уважением, Александр Шурыгин icq 254106594 email: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] phone: +7 902 265 81 66 Hello There are some ways to do that and it depends of many things. For example: # Deny all iptables -P INPUT DROP iptables -P OUTPUT DROP iptables -P FORWARD DROP #Allowing incoming http traffic iptables -A INPUT -p tcp --dport 80 -j ACCEPT #Allowing outgoing established and related http traffic iptables -A OUTPUT -p tcp --sport 80 -m state --state ESTABLISHED,RELATED -j ACCEPT #Allowing incoming ssh traffic iptables -A INPUT -p tcp --dport 22 -j ACCEPT #Allowing outgoing established and related ssh traffic iptables -A OUTPUT -p tcp --sport 22 -m state --state ESTABLISHED,RELATED -j ACCEPT #If you want to update your server from the Internet you should allow #dns communication and outgoing http traffic iptables -A OUTPUT -p udp --dport 53 -j ACCEPT iptables -A INPUT -p udp --sport 53 -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A OUTPUT -p tcp --dport 80 -j ACCEPT iptables -A INPUT -p tcp --sport 80 -m state --state ESTABLISHED,RELATED -j ACCEPT You could use the multiport module and here it is another example: 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 There are many possibilities and a think you should read this material, it is very good: http://www.sns.ias.edu/~jns/files/iptables_ruleset http://linuxgazette.net/108/odonovan.html If you have any questions, please, put it here. Bye. Daniel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
secured server policies
hello huys I have trouble. i readed and readed and think better i ask professionals :) I have server which must have shared only 80 and 22 ports. all other ports i want to close by iptables. Which rules i must use ? Thanks. have a good day :) -- С уважением, Александр Шурыгин icq 254106594 email: [EMAIL PROTECTED] phone: +7 902 265 81 66
Re: secured server policies
Alexandr Shurigin escribió: hello huys I have trouble. i readed and readed and think better i ask professionals :) I have server which must have shared only 80 and 22 ports. all other ports i want to close by iptables. Which rules i must use ? Thanks. have a good day :) -- С уважением, Александр Шурыгин icq 254106594 email: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] phone: +7 902 265 81 66 Hello: one posibility ... iptables -P INPUT DROP iptables -t filter -A INPUT -p tcp -m tcp --dport 22 -j LOG --log-prefix 'TRY UNKNOW SSH ACCESS ' --log-level 4 itpables -t filter -A INPUT -s 0/0 -d your.local.ip -p tcp --sport 1024:65535 --dport 80 -j ACCEPT itpables -t filter -A INPUT -s your.ip.client. -d your.local.ip -p tcp --sport 1024:65535 --dport 22 -j ACCEPT iptables -j DROP make sure that the the following modules are loaded (minimal like): /sbin/modprobe ip_tables /sbin/modprobe iptable_filter /sbin/modprobe ipt_LOG These rules working well on 2.6.18 kernel. I hope that my help him util. (Huh?) PS: i'm not a professional. PS2: sorry for my english. Bye. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
