[Cialug] IPTables Concept

[Chris K.]

Thanks for the response Josh.

I have made some progress but I am stumped on the ssh connection 
currently, considering the super-restrictive outbound rules.

Here is what I currently have:

# Flush all chains
/sbin/iptables --flush

# Allow unlimited traffic on the loopback interface
/sbin/iptables -A INPUT -i lo -j ACCEPT
/sbin/iptables -A OUTPUT -o lo -j ACCEPT

# Set default policies
/sbin/iptables --policy INPUT DROP
/sbin/iptables --policy OUTPUT DROP
/sbin/iptables --policy FORWARD DROP

# Rules for services hosted on server
/sbin/iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j ACCEPT
/sbin/iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

Now when I try to ssh to it, I get the following:
workstation:~# ssh -vv user at silo.icbm.com
OpenSSH_4.3p2 Debian-5, OpenSSL 0.9.8c 05 Sep 2006
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to edge [192.168.1.1] port 22.

And there it just hangs.

Now, if I change
/sbin/iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
to
/sbin/iptables -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

I am able to login via ssh, but this rule violates the spirit of this 
exercise by allowing any traffic out of the server.
I think my shortcoming is understanding exactly how ssh establishes 
connections.

Anyone have thoughts?  Or better yet, an outbound rule to only allow the 
traffic for ssh back out once a connection is made?  :)

Thanks Everyone!
Chris K.

Josh More wrote:
> 1) Yes, iptables is capable of this.  It's quite easy to do, in fact.
>
> 2) iptables is port-specific, and ssh is encrypted anyway.  There is no
> difference between ssh and rsync data over ssh.  It should "just work"
>
> 3) The worst that can happen with a firewall like this (if you're not
> doing routing) is that you lose access to the server.
>
> Also, I recommend putting the ssh configs in the firewall rules, just
> so you have a single spot of administration.
> It will make your life easier.  If I were you, I would make sure I have
> console access and turn on the deny-all rule first.
> Then test to make sure it works.  Then open up each one, one by one,
> and test as you go.
>
> In the end, run nmap against it from inside and outside, and make sure
> it does what you expect.
>
> If you need a reference, "Red Hat Linux Firewalls" is a good overview
> for iptables.
> http://www.amazon.com/Red-Linux-Firewalls-Bill-McCarty/dp/0764524631
> It is not Red Hat specific.
>
> Once it's built, check out "Troubleshooting Linux Firewalls" for
> further reference.
> It's very well written. 
> http://www.amazon.com/Troubleshooting-LinuxR-Firewalls-Michael-Shinn/dp/0321227239
>
> Hope this helps,
>
>
>
>
>  
>
>