> 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
