iptables sanity check

[n0cmonkey]

This seems to do what I want, but I want to make sure it is. The syntax for this stuff makes little sense, and getting this to work has been a PITA.

iptables -I INPUT 1 -s $machine2 -p TCP --dport 22 -m state --state NEW,ESTABLISHED -i eth1 -j ACCEPT

Basically, I want this rule to allow SSH from $machine2 (an ssh gateway) to the system iptables is running on. It should allow new and established connections, and keep track of state.

Is this doing what I want? Is there something more I could add, or something I should change?

Thanks in advance!

 

[Nothinman]

It looks ok to me, but I'm far from a netfilter guru.

Just realize that -I is insert and -A is append, so when you run that it'll become the first rule.

 

[Haden]

It's not usual to use NEW,ESTABLISHED in one rule. Maybe you want:
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT # accept connections we established or related ones (e.g. ftp)
iptables -A INPUT -m state -p tcp --dport 22 --state NEW -s $machine1 -j ACCEPT # accept ssh from machine1
iptables -A INPUT -j DROP # drop everything else

 

[Nothinman]

True, although I would assume that if the conntrack module accepts the combination that it would also be smart enough to do the right thing with it.

 

[n0cmonkey]

The real rules use -A, I guess I posted a test one instead.

It's SSH. There isn't anything "RELATED" involved, that I'm aware of. It's bad enough I have to create multiple rules for multiple sources, I don't think it should be bad to have NEW and ESTABLISHED in the same rule. Especiallly since the ESTABLISHED connections should be restricted in the same manner as the NEW connections.

Thanks for the commends guys!

 

[nweaver]

I usually change my port, adding 2 digits (i.e.2299 or something). I get a lot less login attempts (zero in 10 months in fact) after changing that.

 

[n0cmonkey]

Originally posted by: nweaver
I usually change my port, adding 2 digits (i.e.2299 or something). I get a lot less login attempts (zero in 10 months in fact) after changing that.

Standards are there for a reason. And we already do this. I just made it 22 so people knew what I was trying to allow.

 

[nweaver]

I figured that might be the case....

My company sometimes does small security audits, and yet we forget to do things like deny root SSH access...creating usernames that are the same as computername/DNS name. No password/simple password on commenly named accounts. It makes me laugh when they get hacked (and they do, eventually.

 

[n0cmonkey]

Originally posted by: nweaver
I figured that might be the case....

My company sometimes does small security audits, and yet we forget to do things like deny root SSH access...creating usernames that are the same as computername/DNS name. No password/simple password on commenly named accounts. It makes me laugh when they get hacked (and they do, eventually.

We're constantly auditted. We do alright.

 

[nweaver]

we are also "constantly auditted"...by the live IP's on our test lab machines and the script kiddies

 

[n0cmonkey]

Originally posted by: nweaver
we are also "constantly auditted"...by the live IP's on our test lab machines and the script kiddies

Korea and China audit us constantly. We've also got plenty of internal and internalish audits going on.

 

[nweaver]

lol. What is amazing is that a fully patched XP box, not running auto updates lasts about 2 days after patch tuesday before it's gone belly up. We also have an odd setup, as our test lab has very little firewalling on our live IP's for the test lab. The firewall between test lab and corp is pretty tight though.