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 [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
