Re: [CentOS] [Fwd: Re: iptables]
On Monday 17 May 2010 09:58, Len Kuykendall wrote: Date: Thu, 29 Apr 2010 00:13:43 +0200 From: gavro...@gavroche.pl To: centos@centos.org Subject: Re: [CentOS] [Fwd: Re: iptables] On Fri, Apr 23, 2010 at 06:08:45PM -0400, Robert Spangler wrote: On Friday 23 April 2010 15:20, cahit Eyigünlü wrote: how or why i have redesigned it to this and it seems like worked : See big problems in your future. :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] Anyone with a little bit of security awareness would never set the default policy to ACCEPT and the reason is below. You would think RH would know better. -A INPUT -j RH-Firewall-1-INPUT -A FORWARD -j RH-Firewall-1-INPUT -A RH-Firewall-1-INPUT -i lo -j ACCEPT -A RH-Firewall-1-INPUT -i eth0 -j ACCEPT With this rule above you just opened up you complete system to what ever it is connected to. That is why it is working. I am hoping this box doesn't have Internet access. -A RH-Firewall-1-INPUT -p icmp --icmp-type any -j ACCEPT -A RH-Firewall-1-INPUT -p 50 -j ACCEPT -A RH-Firewall-1-INPUT -p 51 -j ACCEPT -A RH-Firewall-1-INPUT -p udp --dport 5353 -d 224.0.0.251 -j ACCEPT -A RH-Firewall-1-INPUT -p udp -m udp --dport 631 -j ACCEPT -A RH-Firewall-1-INPUT -p tcp -m tcp --dport 631 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 8443 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 25 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 21 -j ACCEPT /etc/sysconfig/iptables 40L, 1617C Even if you didn't have the line with '-i eth0 -j ACCEPT' you system was still open to everyone because at this point if none of the rules apply and the firewall falls back to the policy setting to decide what to do with a packet. Since all your policies are set to ACCEPT the packet is accepted and the hacker is in. For this reason one would think RH would do a little more and set the default policies to DROP. It is so easy to miss the reject or drop statements at the end and the policy would catch them for you. I know some will argue that RH did what they needed to do, but they could go that extra step don't you think. Absolutely agree with you. It would save us from threads like that because people would need to read about iptables and stop to ask silly questions. -- Dominik Zyla Setting the default policy to DROP is not always the best approach, especially if you do remote administration. What happens when you are connected remotely and execute: # iptables -F You are either jumping in the car to drive to the server or on the phone trying to reach someone local to assist because the default DROP policy just killed your session. Why would you ever do a '-F' remotely? Change the rules and something is not working then you should just restart/reload the firewall. Everything that worked before the change will still be working again and the rules that wasn't working will be removed. In my opinion a better option for creating a default DROP policy is to add the following rule (INPUT chain in this example) as the last entry in a chain: -A INPUT -j DROP Now you have a chain that performs like one with a default DROP policy but does not kill your remote session if all rules are flushed. As I state above opinions very but forget that rule or comment it out by mistake and your system is left wide open to everyone because your default rules is set to 'ACCEPT' everything. To each his own. I set the default policy to DROP and I also place the DROP rule at the end of all my chains. The policy is my safety net in case I would happen to remove the DROP rule at the end of a chain by mistake. When working remotely you have to be extra careful because should you lock yourself out it could be a long night. -- Regards Robert Linux User #296285 http://counter.li.org ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] [Fwd: Re: iptables]
Date: Thu, 29 Apr 2010 00:13:43 +0200 From: gavro...@gavroche.pl To: centos@centos.org Subject: Re: [CentOS] [Fwd: Re: iptables] On Fri, Apr 23, 2010 at 06:08:45PM -0400, Robert Spangler wrote: On Friday 23 April 2010 15:20, cahit Eyigünlü wrote: how or why i have redesigned it to this and it seems like worked : See big problems in your future. :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] Anyone with a little bit of security awareness would never set the default policy to ACCEPT and the reason is below. You would think RH would know better. -A INPUT -j RH-Firewall-1-INPUT -A FORWARD -j RH-Firewall-1-INPUT -A RH-Firewall-1-INPUT -i lo -j ACCEPT -A RH-Firewall-1-INPUT -i eth0 -j ACCEPT With this rule above you just opened up you complete system to what ever it is connected to. That is why it is working. I am hoping this box doesn't have Internet access. -A RH-Firewall-1-INPUT -p icmp --icmp-type any -j ACCEPT -A RH-Firewall-1-INPUT -p 50 -j ACCEPT -A RH-Firewall-1-INPUT -p 51 -j ACCEPT -A RH-Firewall-1-INPUT -p udp --dport 5353 -d 224.0.0.251 -j ACCEPT -A RH-Firewall-1-INPUT -p udp -m udp --dport 631 -j ACCEPT -A RH-Firewall-1-INPUT -p tcp -m tcp --dport 631 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 8443 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 25 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 21 -j ACCEPT /etc/sysconfig/iptables 40L, 1617C Even if you didn't have the line with '-i eth0 -j ACCEPT' you system was still open to everyone because at this point if none of the rules apply and the firewall falls back to the policy setting to decide what to do with a packet. Since all your policies are set to ACCEPT the packet is accepted and the hacker is in. For this reason one would think RH would do a little more and set the default policies to DROP. It is so easy to miss the reject or drop statements at the end and the policy would catch them for you. I know some will argue that RH did what they needed to do, but they could go that extra step don't you think. Absolutely agree with you. It would save us from threads like that because people would need to read about iptables and stop to ask silly questions. -- Dominik Zyla Setting the default policy to DROP is not always the best approach, especially if you do remote administration. What happens when you are connected remotely and execute: # iptables -F You are either jumping in the car to drive to the server or on the phone trying to reach someone local to assist because the default DROP policy just killed your session. In my opinion a better option for creating a default DROP policy is to add the following rule (INPUT chain in this example) as the last entry in a chain: -A INPUT -j DROP Now you have a chain that performs like one with a default DROP policy but does not kill your remote session if all rules are flushed. Len _ Hotmail is redefining busy with tools for the New Busy. Get more from your inbox. http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_2___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] [Fwd: Re: iptables]
On Fri, Apr 23, 2010 at 06:08:45PM -0400, Robert Spangler wrote: On Friday 23 April 2010 15:20, cahit Eyigünlü wrote: how or why i have redesigned it to this and it seems like worked : See big problems in your future. :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] Anyone with a little bit of security awareness would never set the default policy to ACCEPT and the reason is below. You would think RH would know better. -A INPUT -j RH-Firewall-1-INPUT -A FORWARD -j RH-Firewall-1-INPUT -A RH-Firewall-1-INPUT -i lo -j ACCEPT -A RH-Firewall-1-INPUT -i eth0 -j ACCEPT With this rule above you just opened up you complete system to what ever it is connected to. That is why it is working. I am hoping this box doesn't have Internet access. -A RH-Firewall-1-INPUT -p icmp --icmp-type any -j ACCEPT -A RH-Firewall-1-INPUT -p 50 -j ACCEPT -A RH-Firewall-1-INPUT -p 51 -j ACCEPT -A RH-Firewall-1-INPUT -p udp --dport 5353 -d 224.0.0.251 -j ACCEPT -A RH-Firewall-1-INPUT -p udp -m udp --dport 631 -j ACCEPT -A RH-Firewall-1-INPUT -p tcp -m tcp --dport 631 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 8443 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 25 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 21 -j ACCEPT /etc/sysconfig/iptables 40L, 1617C Even if you didn't have the line with '-i eth0 -j ACCEPT' you system was still open to everyone because at this point if none of the rules apply and the firewall falls back to the policy setting to decide what to do with a packet. Since all your policies are set to ACCEPT the packet is accepted and the hacker is in. For this reason one would think RH would do a little more and set the default policies to DROP. It is so easy to miss the reject or drop statements at the end and the policy would catch them for you. I know some will argue that RH did what they needed to do, but they could go that extra step don't you think. Absolutely agree with you. It would save us from threads like that because people would need to read about iptables and stop to ask silly questions. -- Dominik Zyla pgpzWRvOYHuPS.pgp Description: PGP signature ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] [Fwd: Re: iptables]
---BeginMessage--- cahit Eyigünlü a écrit : how could i add / remove iptable rules on cet os 5.4 final for tcp / udp base on ports If you don't want to mess with iptables, take a look at the firewall configuration tool system-config-securitylevel-tui. I think there's a graphical app also, but I've never used it. If you only need to open/close ports on a tcp/udp basis, this tool will do the job. Right now looking for an example. In my own documentation, I have some screenshots of the tool. Here, for example (second screenshot), opening port 67 for UDP requests : http://www.microlinux.fr/doc_en_stock/dhcp.html Or here (first screenshot), opening port 53 for both TCP and UDP requests : http://www.microlinux.fr/doc_en_stock/dns.html If you want more complicated stuff, you'll have to dive into iptables, though. Cheers, Niki ---End Message--- ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] [Fwd: Re: iptables]
Thanks also i found this editinig the : edit /etc/sysconfig/iptables is a good way for solution problem solved thanks for everybody's attention 2010/4/23 Niki Kovacs cont...@kikinovak.net cahit Eyigünlü a écrit : how could i add / remove iptable rules on cet os 5.4 final for tcp / udp base on ports If you don't want to mess with iptables, take a look at the firewall configuration tool system-config-securitylevel-tui. I think there's a graphical app also, but I've never used it. If you only need to open/close ports on a tcp/udp basis, this tool will do the job. Right now looking for an example. In my own documentation, I have some screenshots of the tool. Here, for example (second screenshot), opening port 67 for UDP requests : http://www.microlinux.fr/doc_en_stock/dhcp.html Or here (first screenshot), opening port 53 for both TCP and UDP requests : http://www.microlinux.fr/doc_en_stock/dns.html If you want more complicated stuff, you'll have to dive into iptables, though. Cheers, Niki ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] [Fwd: Re: iptables]
Thanks also i found this editinig the : edit /etc/sysconfig/iptables is a good way for solution problem solved thanks for everybody's attention I guess you missed the second line of text in that file, so probably you will be oblivious to it having changed when it does:) ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] [Fwd: Re: iptables]
cahit Eyigünlü a écrit : Thanks also i found this editinig the : edit /etc/sysconfig/iptables is a good way for solution problem solved thanks for everybody's attention Your attention has to come back. Editing /etc/sysconfig/iptables is *not* the solution. Just! Read! ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] [Fwd: Re: iptables]
how or why i have redesigned it to this and it seems like worked : [r...@lin ~]# vi /etc/sysconfig/iptables # Firewall configuration written by system-config-securitylevel # Manual customization of this file is not recommended. *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :RH-Firewall-1-INPUT - [0:0] -A INPUT -j RH-Firewall-1-INPUT -A FORWARD -j RH-Firewall-1-INPUT -A RH-Firewall-1-INPUT -i lo -j ACCEPT -A RH-Firewall-1-INPUT -i eth0 -j ACCEPT -A RH-Firewall-1-INPUT -p icmp --icmp-type any -j ACCEPT -A RH-Firewall-1-INPUT -p 50 -j ACCEPT -A RH-Firewall-1-INPUT -p 51 -j ACCEPT -A RH-Firewall-1-INPUT -p udp --dport 5353 -d 224.0.0.251 -j ACCEPT -A RH-Firewall-1-INPUT -p udp -m udp --dport 631 -j ACCEPT -A RH-Firewall-1-INPUT -p tcp -m tcp --dport 631 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 8443 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 25 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 21 -j ACCEPT /etc/sysconfig/iptables 40L, 1617C 2010/4/23 Niki Kovacs cont...@kikinovak.net cahit Eyigünlü a écrit : Thanks also i found this editinig the : edit /etc/sysconfig/iptables is a good way for solution problem solved thanks for everybody's attention Your attention has to come back. Editing /etc/sysconfig/iptables is *not* the solution. Just! Read! ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] [Fwd: Re: iptables]
how or why i have redesigned it to this and it seems like worked : Post your ip and root user/pass, we'll fix that and your mail client:P ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] [Fwd: Re: iptables]
On Fri, 23 Apr 2010, Joseph L. Casale wrote: how or why i have redesigned it to this and it seems like worked : Post your ip and root user/pass, we'll fix that and your mail client:P ** please ** take this catfight offlist -- Russ herrold ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] [Fwd: Re: iptables]
On Friday 23 April 2010 15:20, cahit Eyigünlü wrote: how or why i have redesigned it to this and it seems like worked : See big problems in your future. :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] Anyone with a little bit of security awareness would never set the default policy to ACCEPT and the reason is below. You would think RH would know better. -A INPUT -j RH-Firewall-1-INPUT -A FORWARD -j RH-Firewall-1-INPUT -A RH-Firewall-1-INPUT -i lo -j ACCEPT -A RH-Firewall-1-INPUT -i eth0 -j ACCEPT With this rule above you just opened up you complete system to what ever it is connected to. That is why it is working. I am hoping this box doesn't have Internet access. -A RH-Firewall-1-INPUT -p icmp --icmp-type any -j ACCEPT -A RH-Firewall-1-INPUT -p 50 -j ACCEPT -A RH-Firewall-1-INPUT -p 51 -j ACCEPT -A RH-Firewall-1-INPUT -p udp --dport 5353 -d 224.0.0.251 -j ACCEPT -A RH-Firewall-1-INPUT -p udp -m udp --dport 631 -j ACCEPT -A RH-Firewall-1-INPUT -p tcp -m tcp --dport 631 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 8443 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 25 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 21 -j ACCEPT /etc/sysconfig/iptables 40L, 1617C Even if you didn't have the line with '-i eth0 -j ACCEPT' you system was still open to everyone because at this point if none of the rules apply and the firewall falls back to the policy setting to decide what to do with a packet. Since all your policies are set to ACCEPT the packet is accepted and the hacker is in. For this reason one would think RH would do a little more and set the default policies to DROP. It is so easy to miss the reject or drop statements at the end and the policy would catch them for you. I know some will argue that RH did what they needed to do, but they could go that extra step don't you think. -- Regards Robert Linux User #296285 http://counter.li.org ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
