LinuxQuestions.org
Share your knowledge at the LQ Wiki.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Security
User Name
Password
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.

Notices

Reply
 
Search this Thread
Old 03-29-2012, 09:10 AM   #1
jnojr
Member
 
Registered: Sep 2007
Location: San Diego, CA
Posts: 175

Rep: Reputation: 15
iptables question


Will including these lines:

Quote:
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
do what I think it will?

Some examples of really locked down firewall rules included a line to allow certain traffic in or out, and then another to allow RELATED, ESTABLISHED traffic the other way. I'm thinking that my blanket rules ought to obviate the need for all of the others, but... maybe there's a reason nobody else does it this way?
 
Old 03-29-2012, 09:19 AM   #2
kakaka
Member
 
Registered: Sep 2003
Posts: 382

Rep: Reputation: 86
It's difficult to answer the question, or really understand what you're asking, if you've abstracted your question from a specific context. As it is, I feel I can only try to answer it at that very general level. You might want to ask yourself this, if the two rules you show were the only rules, how would any connection ever be established? Then try to apply the answer to that question in your specific context.
 
Old 03-29-2012, 09:34 AM   #3
jnojr
Member
 
Registered: Sep 2007
Location: San Diego, CA
Posts: 175

Original Poster
Rep: Reputation: 15
Quote:
Originally Posted by kakaka View Post
It's difficult to answer the question, or really understand what you're asking, if you've abstracted your question from a specific context. As it is, I feel I can only try to answer it at that very general level. You might want to ask yourself this, if the two rules you show were the only rules, how would any connection ever be established? Then try to apply the answer to that question in your specific context.
In the interests of being specific, let's remove the assumptions:

Quote:
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp --dport 22 -j ACCEPT
COMMIT
Will ssh work, yes or no?

I don't have console access to my testbed right now, and don't want to try until I have OOB access again :-)
 
Old 03-29-2012, 10:14 AM   #4
Noway2
Senior Member
 
Registered: Jul 2007
Distribution: Ubuntu 10.10, Slackware 64-current
Posts: 2,124

Rep: Reputation: 776Reputation: 776Reputation: 776Reputation: 776Reputation: 776Reputation: 776Reputation: 776
Quote:
I don't have console access to my testbed right now, and don't want to try until I have OOB access again :-)
In this case you need to be very careful. I would even caution whether or not the advantages of adding a firewall outweigh the possible disadvantages. Remember that unlike Windows, Linux only opens ports when there are server processes running and unlike Windows a firewall does not provide an inherent added layer of protection. You would be better served focus your efforts on securing SSH itself, which the firewall will not protect.

Having said that, there are a couple of things you can do to help prevent completely locking yourself out.
1 - Given that your remote access, set your policy to accept instead of drop and used a drop all rule at the end of your list. The distinction is that you can flush the table rules without locking yourself out while still achieving the same benefit.
2 - have SSH listen on multiple ports and open a secondary SSH for testing purposes. Then experiment with restricting on the other.
3 - I believe your rules are missing part of the syntax related to state-full monitoring. I have provided the rules I use for SSH control below. Note that I am also using rate limiting which is established with the first two rules. Note that I use the conntrack --cstate to monitor the state relationship. This is the part that I think is missing in your configuration. I also restrict the range of IP addresses from which I will allow SSH connnections, though this isn't strictly necessary. Alternatively, you could forget the state portion and just open the ports as required. Similarly, you will want to consider why you are placing restrictions on the OUTPUT chain. Consider how a new OUTPUT connection will be established, such as checking for package updates if you limit yourself to related and established traffic.

Code:
-A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --name DEFAULT --rsource -j DROP
-A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name DEFAULT --rsource
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -s <my-access-ip-range> -i eth0 -p tcp -m tcp --dport 22 -j ACCEPT
 
1 members found this post helpful.
Old 03-29-2012, 01:25 PM   #5
kakaka
Member
 
Registered: Sep 2003
Posts: 382

Rep: Reputation: 86
Beyond not locking yourself out though, as a comment on the general concept of port security, I would suggest never using a standard port number for something like ssh.

Yes, in some cases it's possible for someone from outside a system to do "port scans", then "probe" ports that are shown as somewhat accessible, to try to determine what service the port might provide.

But using a non-standard port, is an attempt to try to make things as difficult as possible for would be attackers. A log scanner that looks for log phrases that may represent potential attacks, and promptly reports, them can be helpful too.
 
Old 03-29-2012, 01:54 PM   #6
Noway2
Senior Member
 
Registered: Jul 2007
Distribution: Ubuntu 10.10, Slackware 64-current
Posts: 2,124

Rep: Reputation: 776Reputation: 776Reputation: 776Reputation: 776Reputation: 776Reputation: 776Reputation: 776
Quote:
Originally Posted by kakaka View Post
Beyond not locking yourself out though, as a comment on the general concept of port security, I would suggest never using a standard port number for something like ssh.

Yes, in some cases it's possible for someone from outside a system to do "port scans", then "probe" ports that are shown as somewhat accessible, to try to determine what service the port might provide.

But using a non-standard port, is an attempt to try to make things as difficult as possible for would be attackers. A log scanner that looks for log phrases that may represent potential attacks, and promptly reports, them can be helpful too.
This is a matter of opinion and my opinion on this particular method is that "security through obscurity" is dubious at best. The only true benefit to this approach is that it helps cut down on the clutter because what traffic remains is at least slightly more sophisticated than the common riffraff. It also adds to the complexity that you must endure because every operation, including SCP, must now be prefixed with the port number. My recommendation for securing SSH is to use key based authentication and turn off direct root login, which will make you highly resistant to compromise via SSH.

For a good explanation of different methods, try this link: http://la-samhna.de/library/brutessh.html (somebody else recommended this link in another recent post but I am having trouble finding it at the moment. Credit and thanks goes to that individual). There is also the security references section of this forum that discusses dealing with brute force SSH.
 
Old 03-29-2012, 04:28 PM   #7
kakaka
Member
 
Registered: Sep 2003
Posts: 382

Rep: Reputation: 86
Quote:
Originally Posted by Noway2 View Post
This is a matter of opinion and my opinion on this particular method is that "security through obscurity" is dubious at best. The only true benefit to this approach is that it helps cut down on the clutter because what traffic remains is at least slightly more sophisticated than the common riffraff. It also adds to the complexity that you must endure because every operation, including SCP, must now be prefixed with the port number. My recommendation for securing SSH is to use key based authentication and turn off direct root login, which will make you highly resistant to compromise via SSH.

For a good explanation of different methods, try this link: http://la-samhna.de/library/brutessh.html (somebody else recommended this link in another recent post but I am having trouble finding it at the moment. Credit and thanks goes to that individual). There is also the security references section of this forum that discusses dealing with brute force SSH.
My comment was not meant to be a comprehensive statement of security, or a suggestion as to a stand alone security mechanism, as you may have mistakenly assumed; merely a comment on an added degree of security. Despite all the physical "Security" they have, Presidents and Potentates have still been assassinated, and information has been smuggled out of the highest security facilities. Given those facts, no one and nothing is truly secure, security is just a matter of degree. I feel that one of the things at which any Human being is an absolute Blue Ribbon, Gold Medalist, is over looking things. No real surprise then, that over time, people expose previously unanticipated vulnerabilities in different approaches to security, even the most "sophisticated" approaches to security. Having additional layers of security, even those that are just intended to slow down attackers, makes things more difficult, has been known to help. No point in giving prospective attackers a well known port to attack.
 
Old 03-29-2012, 06:36 PM   #8
Noway2
Senior Member
 
Registered: Jul 2007
Distribution: Ubuntu 10.10, Slackware 64-current
Posts: 2,124

Rep: Reputation: 776Reputation: 776Reputation: 776Reputation: 776Reputation: 776Reputation: 776Reputation: 776
Quote:
Originally Posted by kakaka View Post
My comment was not meant to be a comprehensive statement of security, or a suggestion as to a stand alone security mechanism, as you may have mistakenly assumed; merely a comment on an added degree of security. <snip> Having additional layers of security, even those that are just intended to slow down attackers, makes things more difficult, has been known to help. No point in giving prospective attackers a well known port to attack.
Yes, I interpreted your statement as an endorsement of the idea that using a port other than 22 provides SSH security. My apologies for jumping to this conclusion as this is obviously not what you intended. It is unfortunate, but it is a is a commonly held fallacy that changing the port provides security. My concern was that the OP not adopt this belief.
 
Old 04-05-2012, 10:14 AM   #9
jnojr
Member
 
Registered: Sep 2007
Location: San Diego, CA
Posts: 175

Original Poster
Rep: Reputation: 15
Quote:
Originally Posted by Noway2 View Post
Code:
-A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --name DEFAULT --rsource -j DROP
-A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name DEFAULT --rsource
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -s <my-access-ip-range> -i eth0 -p tcp -m tcp --dport 22 -j ACCEPT
I just wanted to leave my thanks... that conntrack rule appears to be just what the doctor ordered. I haven't had a chance to thoroughly test everything yet, but it's looking good!
 
Old 04-05-2012, 02:16 PM   #10
salasi
Senior Member
 
Registered: Jul 2007
Location: Directly above centre of the earth, UK
Distribution: SuSE, plus some hopping
Posts: 3,903

Rep: Reputation: 775Reputation: 775Reputation: 775Reputation: 775Reputation: 775Reputation: 775Reputation: 775
Quote:
Originally Posted by Noway2 View Post
For a good explanation of different methods, try this link: http://la-samhna.de/library/brutessh.html (somebody else recommended this link in another recent post but I am having trouble finding it at the moment. Credit and thanks goes to that individual).
While it was possibly me - I always recommend that page, because it does discuss the various options without being partisan in favour of the author's favourite solution, which is what you see in many places across 't interwebs - I'll also point out that the link is in the 'Security References'.

Quote:
Originally Posted by Noway2 View Post
The only true benefit to this approach is that it helps cut down on the clutter because what traffic remains is at least slightly more sophisticated than the common riffraff.
This mirrors my thoughts on the subject. If someone can port scan your server, and knows how to do it (the 'script kiddies', who seem to be the bulk of this traffic, don't today, but either an enhanced script or a more intelligent cracker might), a non-standard port just gives you a few seconds extra. This isn't very worthwhile.

Quote:
2 - have SSH listen on multiple ports and open a secondary SSH for testing purposes. Then experiment with restricting on the other.
That's a good idea, and one that I haven't used before, so thanks for that.
 
Old 04-05-2012, 02:21 PM   #11
sundialsvcs
Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 5,382

Rep: Reputation: 1109Reputation: 1109Reputation: 1109Reputation: 1109Reputation: 1109Reputation: 1109Reputation: 1109Reputation: 1109Reputation: 1109
Quote:
Originally Posted by Noway2 View Post
... I would even caution whether or not the advantages of adding a firewall outweigh the possible disadvantages. Remember that unlike Windows, Linux only opens ports when there are server processes running and unlike Windows a firewall does not provide an inherent added layer of protection. You would be better served focus your efforts on securing SSH itself, which the firewall will not protect.
I respectfully question what you have said here. 'iptables' rules control both incoming and outgoing connections, at a level of detail and control that is well below that of "ports." The process may open a particular port, but will never be able to (as the case may be) send and/or receive any information through it which does not conform to the rules. An external process may attempt to communicate to a port but the communication will not succeed -- and the process making the attempt may or may not be allowed to know.

You certainly should secure your ssh, and I am of the opinion that you should do so especially through the requirement of digital certificates: no passwords. But you still should practice the "principle of least access" with regard to your TCP/IP communication. If a particular client has a bona-fide reason to connect to this-or-that port, the request is granted, but the default action is that "everything which is not permitted is denied."

I think it's a waste of time to try to be "obscure" about SSH or about anything else. The protocols are too well-known.
 
Old 04-05-2012, 02:50 PM   #12
Noway2
Senior Member
 
Registered: Jul 2007
Distribution: Ubuntu 10.10, Slackware 64-current
Posts: 2,124

Rep: Reputation: 776Reputation: 776Reputation: 776Reputation: 776Reputation: 776Reputation: 776Reputation: 776
Quote:
Originally Posted by sundialsvcs View Post
I respectfully question what you have said here. 'iptables' rules control both incoming and outgoing connections, at a level of detail and control that is well below that of "ports." The process may open a particular port, but will never be able to (as the case may be) send and/or receive any information through it which does not conform to the rules. An external process may attempt to communicate to a port but the communication will not succeed -- and the process making the attempt may or may not be allowed to know.

You certainly should secure your ssh, and I am of the opinion that you should do so especially through the requirement of digital certificates: no passwords. But you still should practice the "principle of least access" with regard to your TCP/IP communication. If a particular client has a bona-fide reason to connect to this-or-that port, the request is granted, but the default action is that "everything which is not permitted is denied."

I think it's a waste of time to try to be "obscure" about SSH or about anything else. The protocols are too well-known.
My statement regarding the risks versus rewards of a firewall was meant in the context of the OP's concern about having only remote access at this point in time and getting locked out. For this interim period, if getting locked out is a concern and having physical access is planned for the near future, I would consider forgoing the firewall temporarily until the risk is mitigated(*).

I completely agree with you on the reasons behind and purpose of a firewall. In Linux server applications, the firewall does take on a different role than in Windows environments, where it is a necessary primary layer of defense to have one before even connecting a machine to a public network least it get compromised within minutes. In Linux it serves a more secondary role of both preventing unintended access to ports and, as you stated, provide a stealthy means of preventing connections and a possibly even a form of process ACL. While it wasn't the OPs questions, there also seems to be some "common wisdom", that I attribute to the Windows mentality that equates using a firewall application with being secure, as demonstrated the plethora of posts that ask, "is this IPTables rule set strong and will it keep me safe from hackers?"

(*) A couple of weeks ago, I was making some adjustments to the main firewall for my home network while working remotely and accidentally killed the SSH connection I was using to gain access by deleting the allow rule. Thankfully, I was able to recover by using a VPN connection to gain access to restore my connections. This required creating some tunnel connections because VPN connections aren't allowed this kind of access. The point to my story being is that having a backup connection when working remotely can be a good move. It doesn't have to be something with a lot of direct functionality, just enough to get you a connection to restore your primary interface while being well protected (layers).
 
  


Reply


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
iptables question j.smith1981 Linux - Security 3 01-06-2011 02:16 PM
tc / iptables question drmongolia Linux - Networking 4 10-26-2009 03:08 AM
iptables question pinoyskull Linux - Security 4 08-16-2007 07:32 AM
iptables question vijeesh Linux - Newbie 2 08-06-2006 03:20 AM
iptables question iomari Linux - Security 4 01-13-2005 12:14 AM


All times are GMT -5. The time now is 06:15 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