I have a server that allows incoming traffic for SSH and some other things. I need to set up a rule that will drop/reject all traffic from a particular server except ssh.
How can I do that.
Something like this first in your ruleset:
-A INPUT -i eth0 -p tcp -s 10.0.1.0/24 –sport 1024:65535 -d 10.0.1.90/32 ! –dport 22 -j DROP
substitute your appropriate ips and interface
We have a simple configuration so we could get by with this
-A RH-Firewall-1-INPUT -m state –state NEW -m tcp -p tcp –dport 22 -j ACCEPT
-A RH-Firewall-1-INPUT -s “SOURCIPADDRESS” -j REJECT –reject-with icmp-host-prohibited
it doesn’t scale well but servies the purpose.
You’re leaving SSH open to the world with that. If this is a box behind a firewall, then it’s not _as much of a concern_ … otherwise you’re opening that server up to SSH brute force attempts.
Your existing configuration is probably set up to drop/reject if traffic does not match any of your rules, so you’ve nearly solved the
“blocking all other traffic” from server2. But you really should put a specific rule on server1 with source as server2 and dest port 22
-s server2 -p tcp –dport 22 -j ACCEPT
Best of luck,
Or move the SSH port to a non-standard one?
Moving the port to a non-standard port is better than nothing … but only be a very slight bit. It might work on the least knowledgeable script kiddies who only look at port 22, but it will do nothing to hide the fact that it is an open to the world SSH port on an nmap scan, etc.
Three much better options are:
1. Use a –source in the IPTABLES rules if you only connect from a limited number of places.
2. Some kind of VPN (like openvpn)
3. Port Knocking: http://www.portknocking.org/view/faq
2 and 3 can both be open from everywhere, and all 3 do not show as an open SSH port from remote scans, which is what you want.
Depends on what problem you’re trying to solve…
If you’re being targetted by an attacker then, yes, a port scan will expose the port anyway. BUT if you’re just seeing random internet noise then simply changing the port will stop this because your random zombie doesn’t port scan before hand (it takes too long, especially if you DROP traffic to all other ports).
This means that you’re not wasting CPU cycles negotiating SSL; you’re not wasting disk space on logs, CPU on fail2ban or similar, resources on accepting connections etc etc.
Since I moved my port a year ago the number of random attacks on my host has dropped to zero.
It’s a very very small win, but it is a win :-)
Thanks for the warning. I am aware of that, but some things an administrator has no control over. They are behind a firewall and we take some further precautions, but I
can get this restricted any further.
We do a better job for those things that are outside of our firewall. And this is some of what we do.