Will including these lines:

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?

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:

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 :-)

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.

1 members found this post helpful.

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.

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.

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.

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!

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'.

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.

That's a good idea, and one that I haven't used before, so thanks for that.

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).