> 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
No comments:
Post a Comment