Re: my debian does not read my own iptables script

Dear Ansgar,

You are absolutely correct.

I installer ftp-proxy and dnsmasq, and then everything suddenly works.

Thank you very much. You've saved me.

--- Pada Sab, 31/1/09, Ansgar Wiechers <lists@planetcobalt.net> menulis:

> Dari: Ansgar Wiechers <lists@planetcobalt.net>
> Topik: Re: my debian does not read my own iptables script
> Kepada: debian-firewall@lists.debian.org
> Tanggal: Sabtu, 31 Januari, 2009, 1:41 AM
> On 2009-01-31 Patrik Hasibuan wrote:
> > Firstly, thank you very much for you reply.
>
> You're welcome.
>
> > It still does not give any change. So I start from a
> very simple,
> > namely: "Just opening some ports I need".
> But which opened are not
> > mentioned in my script.
> >
> > But the port of 21,23,53,10883 are always close. I
> don't mention port
> > of 111,113 and 515 in my iptables-script and I want
> they're be closed
> > but in fact they are stay open. Sigh...!!!
>
> There seems to be a misunderstanding about the nature of
> ports here.
> Ports don't magically turn "open", because
> you don't filter them on the
> firewall. A port is only in the state "open" if
> some daemon has a
> listening socket bound to it. For instance, port 111/tcp on
> your machine
> is probably open, because you're running the portmap
> daemon.
>
> If you want port 21/tcp to be open, you have to run a
> service listening
> on that port (usually an FTP server). On port 23/tcp
> you'd normally run
> a telnet server (although I'd strongly recommend
> against doing so, since
> SSH is a far better option). On ports 53/tcp and 53/udp
> you'd normally
> be running your DNS server, and so on.
>
> Besides, why is your firewall running port-mapper, identd
> and print
> spooler anyway? A firewall is a security device and should
> be running as
> little services as possible. I also strongly recommend
> running a custom
> (stripped-down) kernel.
>
> [...]
> > This is my complete script:
> > #!/bin/bash
> > #Zero...zero...from beginning
> > iptables -F
> > iptables -t nat -F
> > iptables -t mangle -F
> >
> > iptables -X
> > iptables -t nat -X
> > iptables -t mangle -X
> >
> > echo "0" > /proc/sys/net/ipv4/ip_forward
> >
> > #route add default gateway 219.83.114.177
> >
> > #Basic policy
> > iptables -P INPUT DROP
> > iptables -P FORWARD ACCEPT
> > iptables -P OUTPUT ACCEPT
>
> First problem. Never flush your chains before setting the
> default
> policies. If you do, you have a (however short) period of
> time where
> your firewall may be wide open. Always initialize your
> firewall in the
> order I lined out in my previous posting.
>
> Second problem. Don't set policies to ACCEPT without a
> good reason.
> Setting the OUTPUT chain to ACCEPT is arguably okay,
> because as long as
> your firewall isn't compromised, the traffic
> originating from it can be
> considered trustworthy. And if it becomes compromised you
> have bigger
> problems than some outbound connections. However, this
> reasoning does
> *not* apply to the FORWARD chain. That chain handles all
> packets that
> your firewall transfers between your LAN and the Internet.
> Set the
> policy to ACCEPT and your LAN is wide open to the world.
> Don't do that.
>
> > iptables -A INPUT -m state --state INVALID -j DROP
> > iptables -A INPUT -p tcp -m state --state
> NEW,ESTABLISHED -j ACCEPT
>
> This is the actual culprit. You're accepting all
> inbound TCP connections
> to any port. Don't do that.
>
> > iptables -A OUTPUT -p tcp -m state --state
> NEW,ESTABLISHED -j ACCEPT
>
> This rule is pointless, since you're accepting
> everything in the OUTPUT
> chain anyway.
>
> > iptables -A FORWARD -p tcp -m state --state
> NEW,ESTABLISHED -j ACCEPT
>
> Same as with the INPUT chain. Only worse. Never allow all
> inbound TCP
> connections to your LAN. Ever. That's a big no-no.
>
> You probably meant to write these rules instead of the
> three above:
>
> iptables -A INPUT -m state --state ESTABLISHED,RELATED -j
> ACCEPT
> iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j
> ACCEPT
> iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j
> ACCEPT
>
> These will allow all traffic belonging to already
> established
> connections, but won't allow to actually establish any
> connection. You
> do that by accepting NEW connections to particular ports.
>
> > iptables -t nat -P PREROUTING ACCEPT
> > iptables -t nat -P POSTROUTING ACCEPT
> > iptables -t nat -P OUTPUT ACCEPT
> >
> > echo "1" > /proc/sys/net/ipv4/ip_forward
> >
> > #Log....them
> > iptables -A INPUT -j LOG
> > iptables -A OUTPUT -j LOG
> > iptables -A FORWARD -j LOG
>
> Because your ruleset is already accepting all traffic at
> this point,
> incoming/outgoing packets will never reach these rules, so
> they won't
> log anything.
>
> > iptables -A INPUT -p tcp -m multiport --source-port
> 20,22,23,53,10883 -j ACCEPT
> > iptables -A INPUT -p udp -m multiport --source-port
> 20,22,23,53,10883 -j ACCEPT
> > iptables -A INPUT -p tcp -m multiport --sport 21 -j
> ACCEPT
> > iptables -A INPUT -p udp -m multiport --sport 21 -j
> ACCEPT
> >
> > iptables -A OUTPUT -p tcp -m multiport
> --destination-port 20,22,23,53,10883 -j ACCEPT
> > iptables -A OUTPUT -p udp -m multiport
> --destination-port 20,22,23,53,10883 -j ACCEPT
> > iptables -A OUTPUT -p tcp -m multiport --dport 21 -j
> ACCEPT
> > iptables -A OUTPUT -p udp -m multiport --dport 21 -j
> ACCEPT
>
> Thes rules will allow your users to establish connections
> (you should
> add "-m state --state NEW" to them, though).
> However, it looks to me
> like you got your perspective wrong. Why are you accepting
> inbound
> connections TO your firewall with those source ports? And
> why outbound
> connections FROM your firewall TO those destination ports
> on some other
> server?
>
> Also your FORWARD chain seems rather useless. You don't
> seem to be
> passing any particular traffic between a LAN and the
> Internet, and your
> not NATing the traffic either.
>
> Perhaps you should elaborate a little on your setup and
> what you
> actually want to achieve.
>
> 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
> debian-firewall-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmaster@lists.debian.org

Menambah banyak teman sangatlah mudah dan cepat. Undang teman dari Hotmail, Gmail ke Yahoo! Messenger sekarang! http://id.messenger.yahoo.com/invite/

--
To UNSUBSCRIBE, email to debian-firewall-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org