Can't set drop all output.
I followed one of these tutos http://www.linode.com/wiki/index.php/CentOS_IPTables_sh .
My OS is Debian Lennny, iptables v1.4.2.
My iptables -L
iptables -L

Chain INPUT (policy ACCEPT)

target prot opt source destination

ACCEPT all -- anywhere anywhere

ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED

ACCEPT tcp -- anywhere anywhere tcp dpt:xxxx

ACCEPT icmp -- proxy.provider.net anywhere

ACCEPT icmp -- proxy.p19.provider.net anywhere

ACCEPT icmp -- proxy.rbx.provider.net anywhere

ACCEPT icmp -- proxy.rbx2.provider.net anywhere

ACCEPT icmp -- ping.provider.net anywhere

ACCEPT tcp -- cache.provider.net anywhere tcp dpt:ssh

DROP all -- anywhere anywhere



Chain FORWARD (policy ACCEPT)

target prot opt source destination



Chain OUTPUT (policy ACCEPT)

target prot opt source destination

ACCEPT all -- anywhere anywhere

ACCEPT udp -- anywhere anywhere udp dpt:domain

ACCEPT tcp -- anywhere anywhere tcp dpt:domain

ACCEPT tcp -- anywhere anywhere multiport dports www,https

ACCEPT icmp -- anywhere anywhere icmp echo-request

ACCEPT tcp -- anywhere anywhere tcp dpt:ssh

ACCEPT tcp -- anywhere anywhere tcp dpt:xxxx


As soon as I add “iptables -A OUTPUT -j DROP” server lock me out and I have to reboot to be able log back. The ssh port is open in both INPUT and OUTPUT what's wrong?

When you set the OUTPUT chain to drop packets it won't allow the outbound traffic related to your SSH connection to pass. Your inbound SSH connection has 2 way traffic - the traffic you send in and the server's responses.

You could change the OUTPUT policy from accept to deny as long as you have rules to allow your SSH traffic. That way only the traffic you explicitly allow will pass. Was that what you were trying to do?

Take the INPUT chaine as an example. I allow the ssh access to port 22 for provider :
iptables -A INPUT -i eth0 -p tcp -m tcp --dport 22 --source cache.provider.net -j ACCEPT
and another specific port for anybody else :
iptables -A INPUT -i eth0 -p tcp -m tcp --dport xxxx -j ACCEPT
And I drop all the rest “iptables -A INPUT -j DROP”.
The firewall is dropping all packets but respect the previous rules.

I'd like to do the same for Chain OUTPUT, I want to drop all packets except of these who are declared before I use “iptables -A OUTPUT -j DROP” .

You can see the two entries on the end of the output chain: “iptables -A OUTPUT -p tcp -m tcp --dport 22 -j ACCEPT”
and “iptables -A OUTPUT -p tcp -m tcp --dport 1845 -j ACCEPT” .
The same is done here => http://www.linode.com/wiki/index.php/CentOS_IPTables_sh for the ssh & sftp.

The preferred way to do it is to have a default policy of DROP for your chain - then you don't need to set the last output rule to drop. The way you have it set up (without RELATED or ESTABLISHED rules for output) will cause the problems you're having. A good source for examples is the netfilter site:
http://www.netfilter.org/documentati...entation-howto
http://www.frozentux.net/iptables-tu...-tutorial.html

Hi gilead.
To change the default policy to “iptables -P OUTPUT -j DROP” is locking the user out after flushing the firewall => “iptable –flush” . The “ iptables -A OUTPUT -j DROP” is more flexible and is doing the same job.
I've finally fixed the prob with port setting, the output chaine is filtering the source packets and not the destination. I've changed the destination port “dport” to the source port “sport” and things works.
The command look like:
iptables -A OUTPUT -p tcp -m tcp --sport 22 -j ACCEPT

iptables -A OUTPUT -p tcp -m tcp --sport xxxx -j ACCEPT

You don't run the flush command manually - you run it as part of a script so that the other commands are added immediately afterward. Adding the output drop rule isn't more flexible or you wouldn't be locked out. Glad you have something that works though

lamachine has the best solution. using -P to change the policy makes the default DROP if you set it that way. This means that anything NOT matching a rule in the ruleset will be DROPPED! If you do this on your outgoing, you need to make allowances for your ssh, yum (or apt, or appropriate update utility), and anything else that has a legitimate need to connect to the internet. This policy will effectively sever this system's ability to connect out. MAKE SURE you include "iptables -A OUTPUT -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT" replacing eth0 with the interface of choice. You can also add a -s directive if you wish for added security, such as -s 192.168.20.0/24 or the appropriate network address and cidr. This will limit traffic outgoing to related and established connections from the incoming side as long as it is related or established to an address in the local subnet. Remember that anytime you make a chain's default policy DROP you must specify what is allowed. If it is not specified, it will drop. Also remember to specify -s (address)/(cidr) and (if desired) -mac --mac-source (mac) which will make spoofing a little harder. Specifying a mac source and -s IP on the same line means the two must match, and must come from within the same network. Remember that if it passes through another router, the frame is decapsulated to layer 3 and loses its data link header, and the source mac address, and gets re-assigned the new mac address during encapsulation back downstream. Inasmuch, the -mac --mac-source directive is really only useful for internal network within the same gateway.

1 members found this post helpful.

You need to clarify the scenario you have in mind when you say best. Here, no Linux box goes to production without a default deny policy. We want all traffic dropped except for what is explicitly allowed (for the INPUT, OUTPUT and FORWARD chains in the filter table) because it stops us accidentally allowing someone to connect. The requirement to specify what is allowed in a default deny setup is exactly what makes it useful here.

The procedure for getting a box production ready here includes producing a security document and demonstrating adherence to the organisation's security policy (which includes an iptables policy of default deny). We use a master iptables script to set up the firewall which sets the policy and from there we can add exceptions in further scripts. The extra scripts have no requirement to include a general drop statement.

Although a default allow policy with a drop at the end of the script achieves the same result for packets there are procedural risks. With scripts modified by different people over a period of time it would be easy for a rule to be inserted at the wrong point in the chain which would allow unauthorised traffic.

I agree and that is how I run my system: default drop on all chains. I also use explicit allowances. If the allowance is for one computer (an example is my admin machine to my linux server) I specify the rule with the -s IP and -m mac --mac-source MAC of the allowed machine. This is a very specific rule which allows only one machine to access the service covered by that rule. Personally, I put this rule in a separate user-defined chain, and -j CHAIN for any ports or services that I want only allowed to this system. You can also create other chains in this same manner, allowing only what you wish, and pointing a policy to that chain. Remember, user-defined chains should be established to ALLOW connections, since the defaults are in DENY mode.

It does make for a lot of work and maintenance, but the work pays for itself in terms of security. iptables is pretty powerful, and can even support conntrack, or connection tracking, for services that may use different ports. This is very useful for bittorrent or other services.

Remember, build in whatever security you can. By specifying an allowed IP and MAC you limit what computer can get through. Specify them on the same rule and it makes spoofing a little harder, since the hacker has to correctly spoof both the IP and MAC of the victim machine. This information is not always available to the hacker. But bear in mind that iptables is stored in a plaintext file, and if you are rooted, then the hacker knows exactly which combination to spoof for later reference to his buddies. Nothing is foolproof, but you don't want to go around making their lives any easier than you have to, right?

And truth be told, gilead is right. Simply inserting a DROP rule at the end of the chain is not as secure. This is because the default rule is ALLOW. If there is no rule that fits the bill, then the ALLOW rule will apply. However, "iptables -A INPUT -j DROP" and its output equivalent does create a rule match for incoming and outgoing traffic, all of the traffic. Because of this, you still have to go through and specify ALLOW's everywhere in the chains, just so that a rule catches the traffic and allows it without further processing through the ruleset.