LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Newbie
User Name
Password
Linux - Newbie This Linux forum is for members that are new to Linux.
Just starting out and have a question? If it is not in the man pages or the how-to's this is the place!

Notices

Reply
 
Search this Thread
Old 08-19-2009, 07:13 AM   #1
PMP
Member
 
Registered: Apr 2009
Location: ~
Distribution: RHEL, Fedora
Posts: 381

Rep: Reputation: 58
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.
 
Old 08-19-2009, 07:58 AM   #2
teebones
Member
 
Registered: Aug 2005
Location: /home/teebones
Distribution: sometimes this, sometimes that..
Posts: 500

Rep: Reputation: 56
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..

Last edited by teebones; 08-19-2009 at 08:24 AM.
 
Old 08-19-2009, 08:36 AM   #3
PMP
Member
 
Registered: Apr 2009
Location: ~
Distribution: RHEL, Fedora
Posts: 381

Original Poster
Rep: Reputation: 58
Quote:
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

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.
 
Old 08-19-2009, 08:51 AM   #4
linuxlover.chaitanya
Senior Member
 
Registered: Apr 2008
Location: Nagpur, India
Distribution: Cent OS 5/6, Ubuntu Server 10.04
Posts: 4,627

Rep: Reputation: Disabled
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?
 
Old 08-19-2009, 08:57 AM   #5
teebones
Member
 
Registered: Aug 2005
Location: /home/teebones
Distribution: sometimes this, sometimes that..
Posts: 500

Rep: Reputation: 56
Quote:
Originally Posted by PMP View Post
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.
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)

Last edited by teebones; 08-19-2009 at 08:59 AM.
 
Old 08-19-2009, 09:00 AM   #6
PMP
Member
 
Registered: Apr 2009
Location: ~
Distribution: RHEL, Fedora
Posts: 381

Original Poster
Rep: Reputation: 58
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
 
Old 08-19-2009, 09:13 AM   #7
PMP
Member
 
Registered: Apr 2009
Location: ~
Distribution: RHEL, Fedora
Posts: 381

Original Poster
Rep: Reputation: 58
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?
 
Old 08-19-2009, 10:04 AM   #8
teebones
Member
 
Registered: Aug 2005
Location: /home/teebones
Distribution: sometimes this, sometimes that..
Posts: 500

Rep: Reputation: 56
Quote:
Originally Posted by PMP View Post

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)

Last edited by teebones; 08-19-2009 at 10:18 AM.
 
Old 08-21-2009, 08:57 AM   #9
TimothyEBaldwin
Member
 
Registered: Mar 2009
Posts: 249

Rep: Reputation: 27
Quote:
Originally Posted by teebones View Post
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)
Wrong, it is the first match of REJECT, DROP, ACCEPT that matters. DENY has no documented meaning.
 
Old 08-21-2009, 09:18 AM   #10
TimothyEBaldwin
Member
 
Registered: Mar 2009
Posts: 249

Rep: Reputation: 27
Quote:
Originally Posted by teebones View Post
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")
It's REJECT, not DENY.

Quote:
Originally Posted by teebones View Post
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..
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.
 
Old 08-21-2009, 11:30 AM   #11
Hangdog42
LQ Veteran
 
Registered: Feb 2003
Location: Maryland
Distribution: Slackware
Posts: 7,785
Blog Entries: 1

Rep: Reputation: 414Reputation: 414Reputation: 414Reputation: 414Reputation: 414
Quote:
-A OUTPUT -p tcp -m tcp --dport 22 -j DROP
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.
 
Old 08-21-2009, 11:55 AM   #12
TimothyEBaldwin
Member
 
Registered: Mar 2009
Posts: 249

Rep: Reputation: 27
Quote:
Originally Posted by Hangdog42 View Post
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.
 
Old 08-22-2009, 08:46 AM   #13
teebones
Member
 
Registered: Aug 2005
Location: /home/teebones
Distribution: sometimes this, sometimes that..
Posts: 500

Rep: Reputation: 56
Quote:
Originally Posted by TimothyEBaldwin View Post
It's REJECT, not DENY.
yes, i ment REJECT..
My failure to write that (somehow i mixup those two, while i ment the other, i say/write the other.. )
 
Old 08-22-2009, 08:49 AM   #14
teebones
Member
 
Registered: Aug 2005
Location: /home/teebones
Distribution: sometimes this, sometimes that..
Posts: 500

Rep: Reputation: 56
Quote:
Originally Posted by TimothyEBaldwin View Post
Wrong, it is the first match of REJECT, DROP, ACCEPT that matters. DENY has no documented meaning.
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 )

Last edited by teebones; 08-22-2009 at 08:50 AM.
 
  


Reply

Tags
block, iptables, ssh


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Linux firewall with application dependant blocking of outgoing connections??? Delphin Linux - Security 21 03-16-2009 07:36 AM
apf blocking all outgoing ssh bytez Linux - Software 1 03-04-2007 02:57 AM
Blocking outgoing TCP F M J Linux - Networking 13 09-06-2005 12:59 AM
Blocking outgoing traffic from a specific port billy3 Linux - Security 10 09-24-2004 08:10 PM
Kernel 2.4.26, slack 8.0: blocking outgoing traffic coindood Linux - Networking 3 06-03-2004 10:15 PM


All times are GMT -5. The time now is 11:14 AM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration