Blocking outgoing ssh using iptables
 

I want to block all the outgoing ssh form my machine, i.e my machine will not be able to ssh to any outside machine using iptables.

The distro is RHEL,

I added the following entry in the iptables but unfortunately it didnt worked,

-A OUTPUT -p tcp -m tcp --dport 22 -j DROP

Please suggest where I am going wrong.

Generic advice: it's better to block everything incoming, and then open the ports wanted. (more secure)
(see point 2 for more info)

note: i'm not covering the basics of forwarding etc.. that requires additional rule sets to get that working correctly.
i'm discussing solely a one machine config (server connected to the internet (e.g. colocation machine).
1)
INPUT = outside (internet e.g.) towards machine.
OUTPUT = from machine itself towards outside.

with that in mind, you need the INPUT, not the OUTPUT rule

Connections comming towards the sshd, should be blocked, the output doesn't matter. Cos if input is blocked, then the ssh shall never respond to the incoming connection from the outside world.

-A INPUT -p tcp -m tcp --dport 22 -j DROP

And if you want a specific ip adress to be able to connect remotely:

-A INPUT -p tcp -m tcp -d xxx.xxx.xxx.xxx --dport 22 -j ACCEPT

xxx.xxx.xxx.xxx= is the remote ip address of the machine who needs access

2.
Also make sure you have in the top config part of the firewal these rules, which prevents all ports towards the machine (input) to be dropped, unless openend (either for a specific address or publically), but allow outgoing connections by default.
This makes handling the firewall easier, cos you only need to open ports for the input, and automatically it works, no need to add an output rule along with it (cos it's already openend). And the server itself can perform tasks, as downloading updates, etc.. if it would be blocked.. lol, the server itself has also no access, unless opened.
see the point of opening all output, but dropping all input. by default. ;) if you utilize this, you can skip the first example code in point 1, cos it's already dropped. Example two applies only then, as for all services.

:OUTPUT ACCEPT [0:0]
:INPUT DROP [0:0]

3)
Also these rules are handy for some daemons (it opens subports if the deamon uses it, once the initial connection is validated, you allowed. Only for the source who's making connection, not for other people connecting.. it's per session)

-A INPUT -m state --state ESTABLISHED -j ACCEPT
-A INPUT -m state --state RELATED -j ACCEPT


4)
complete (drafty) example could be:

#my short effective firewall config

#Defining basic behaviors:
*filter
:FORWARD ACCEPT [0:0]
:INPUT DROP [0:0]
:OUTPUT ACCEPT [0:0]

#Which service should i allow access to?

#auto opening subports when a deamon i've gained access to, needs it
-A INPUT -m state --state ESTABLISHED -j ACCEPT
-A INPUT -m state --state RELATED -j ACCEPT

#my services i want to open:

#end of config

5) differences between the three states (DROP, ACCEPT, DENY)

ACCEPT = ALLOW access completely on that port(s). defined by the rule (publically or for certain ip's)
DROP = DENY access silently (meaning not response at all)
DENY = DENY access, but with verbose (meaning it responses back with an error message to the machine trying to connect, e.g. "access denied, no access on the port")

DROP is more secure, cose the remote party would never know if there is a service running behind a specified port, cos no output is returned at all... from the server. So more hacker proof.
If they should get an error message (because you've used DENY instead of drop) then they KNOW a service is running behind that port, and it's more appealing to try a bypass/hack etc..

Well I agree say I have a machine A, I want to achieve that A should not be able to ssh to any other machine but other machine can ssh to A.

But if I Use INPUT I will be blocking other machines to ssh to A and this is what I do not want.

This is should actually work. Have you changed the ssh port at the server?

iptables -A OUTPUT -p tcp –dport 22 -j DROP

Have you saved and re applied the settings?

Oh ok, i missunderstood you :)

in that case, you're rule should work. If it's not, try this

ditch the -m part in your line

(-m module load)

maybe you should list your firewall of the specified machine, without revealing the ipaddresses, or hostname..
(so it stays anonymous to us, on which machine it is)

I tries dropping the -m part Doesnt work,

I did saved the iptables and restarted it, unfortunately it is not working unable to understand why

Well I got it working

I was adding this line below
-A OUTPUT -p tcp -m state --state NEW,ESTABLISHED -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 22 -j DROP

but when I reverse the order of these line it works

-A OUTPUT -p tcp -m tcp --dport 22 -j DROP
-A OUTPUT -p tcp -m state --state NEW,ESTABLISHED -j ACCEPT

Now why exactly is this happening?

I'll try to explain it to you (without special cases), it's quite complicated to explain without going too techie. ;)


Reading is from top to bottom. (that's how IPTABLES also reads the rules during start)

thus, in your working config, it says basically, first drop 22
then allow other connections going out.

if you would reverse this, it says, allow all (including ssh), then the restrictive rule, is not working. Because it conflicts with the first line (allow all)

reason why:

in generic rules, not defining which port, which protocol etc, ACCEPT is more powerful then DROP or DENY, because it OPENS things (IPTABLES vision, is that OPENING things, is a special assignment, DROPPING DENYING is standard reason to have a firewall in the first place)
That way, you see that if you first open everything, then dropping some lateron, is not effective, cause OPENING (without specifying the ports or protocols, like in your line underneath) is then leading the blockades under it. That the reason most people use a global init config of either blocking everything on a certain route, or ACCEPTING it.)
so those rules a read globale (systemwide), lateron you can specify custom rules with the -A lines.

global rules are set in the top of the config beginning with a ":"

e.g.
:OUTPUT [0:0] DROP

I hope my explaining helps you understand, again it's quite difficult to explain it. (hence there are numerous books about firewalling with IPTABLES, not for no reason ;))

besides English is not my Native language (but my second)

Wrong, it is the first match of REJECT, DROP, ACCEPT that matters. DENY has no documented meaning.

It's REJECT, not DENY.

Not responding is a giveaway that a firewall is there, a non-firewalled host will respond with an error if the port is not in use. REJECT will not respond differently depending on weather the port in in use, but can be made to mimic an non-firewalled system.

I'm not sure iptables is really the way to go about doing this. Unless I'm very mistaken, for outgoing SSH connections, there is no "standard" port that is used that can be blocked like this. SSH simply uses a random high level port. You're probably better off limiting access to the ssh command than in messing with iptables.

No, whilst the local port number is high and random, the remote port number is typically 22, which is what that iptables rule checks. However one can run SSH servers on non-standard ports, and install their own copy of an SSH client.

yes, i ment REJECT.. ;)
My failure to write that (somehow i mixup those two, while i ment the other, i say/write the other.. )

no, wrong here, read/interpreted my writing more closely ;)
All rules have a DROP/ACCEPT or REJECT in them, beginning with an -A.
so, their is no first match as YOU wrote.. could be anything of those three ;)
And thus his example should work according to your explanation, however it didn't, reason, cos there is a catch.
(as i tried to explain. Althoug i might be a bit unclear in the explaining.. or we mean the same thing, but tell it differently, and that why we don't follow eachother ;))