Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


How safe is an open port 22, but only AllowUser root@IP?
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

How safe is an open port 22, but only AllowUser root@IP?

I know the best thing is the change the SSH port, and I normally do that on every server. Still, I have a couple of servers that I need to have 22 open on.
I have on thees servers set AllowUsers [email protected]. only using the IP at home, and a private VPN service.

Can ha hacker get access via port 22 so long he is not on my homenetwork or using my VPN?

«1

Comments

  • It's anecdotal I know, but I've done this for years, never had a server compromised.

    Thanked by 3myhken jvnadr netomx
  • raindog308raindog308 Administrator, Veteran

    Nekki said: It's anecdotal I know, but I've done this for years, never had a server compromised.

    Actually, I'm browsing your private tentacle hentai collection right now.

  • drserverdrserver Member, Host Rep

    do a 2 factor auth.

  • I change to a non-standard port ( Obscurity, not security I know ), create a user just for SSH with no sudo rights, disable root login, and set up fail2ban on port 22 and my non-standard port to block more than 3 failed attempts.

  • BlanozBlanoz Member
    edited February 2015

    Changing SSH port is generally done to low down the noise (failed attempts) in the logs. You either have a strong password or an authentication monitor (such as fail2ban). Having both is more desirable. My personal advice is to use key based authentication.

    You should be more concerned about the security of your web-facing applications or servers, rather than considering that someone might break into server over ssh.

    Thanked by 3myhken aglodek netomx
  • @raindog308 said:
    Actually, I'm browsing your private tentacle hentai collection right now.

    Dude, you only had to ask and I'd have shared :-(

  • bsdguybsdguy Member
    edited February 2015

    @myhken

    Frankly, I think you've chosen a unsatisfactory solution. Assume, for some reason your IP changes or you must get at your VPS from somewhere else; then you're f-cked.

    Consider this: A closed port is a closed port, period.
    Moving from 22 to XXXX will keep the noise considerably lower by having gazillions of "click 'kewl 3l1t3 hackzor' button" idiot attacks fail.
    The next layer is the firewall. If you can block something at the firewall that's way better than blocking at application level (like SSH). Simple reason. The firewall deeper down in the plumbing and faster and sees the packets way earlier.
    Only then comes the application layer, e.g. SSH. Having evil packets reaching the app. layer has doors open to diverse kinds of attack, e.g. resource depletion based ones.

    To word it provocatively: Having his packets reach your application basically means the evil guy is already halfway in.

    The "holy rule" is: Get them early and get them cheap.

    And that's one point where your setup is lously because you have SSH do a classical firewall job, namely filtering by source address.

    Second BIG sin: root. Do not do that ever! NEVER!

    Login as a user and sudo to root if and where needed.

    Another tool that may be useful in your scenario is port knocking. It's sometimes decried as "obscurity based" but I personally have often found it very useful and working really well. Hint: If your firewall supports it (most do) then do not use a knocking daemon but do it directly in the firewall itself.
    Using port knocking is about the best way for "I must have SSH on 22" guys. For outsiders it looks like you have no SSH at all, yet authorized people may login from everywhere.

    Thanked by 1aglodek
  • KuJoeKuJoe Member, Host Rep
    edited February 2015

    A word of caution: Even if they can't get access to SSH, just knowing the port number can be a headache. We've had plenty of clients who kept SSH listening on port 22 and had password authentication disabled and get DOS'ed by scripts who kept trying to connect to port 22, not old was it filling up log files but there were so many concurrent connection attempts it was causing the loads to spike over 1000%. Even with fail2ban, CSF, denyhosts, etc... there were so many different IPs that it was just causing more of a load on the VPS. This was a few years ago, but it got to the point where we have a script that stops VPSs that have too many SSH connections before it impacts other clients (although I think the hardware we were using was partly to blame for how much things were impacted by the attacks).

    Something to keep in mind.

    Thanked by 1raindog308
  • @KuJoe said:

    may i ask what do you suggest? I mean from a provider point of view.

  • KuJoeKuJoe Member, Host Rep
    edited February 2015

    @ehad If you're running OpenVZ then Nodewatch has a built in check for SSH attacks. I wrote a simple bash script that checks how many SSH connections a VPS has and if it's too many it will stop the VPS.

    If it's Xen/KVM/Any non-container then I'm not sure the best solution.

    Additionally, I added a button to our Wyvern control panel that randomizes the SSH port for clients automatically since some people are worried about editing config files through command line and since I added it, the number of compromised VPSs reported have dropped to near zero (I'm not sure if it's because of it or not, but it is mighty coincidental and our logs show a lot of new clients hitting that button).

    Thanked by 3ehab Blanoz netomx
  • I run SSH on port 22 without any firewall restrictions. I have pass auth disabled and use 8192-bit keys. Never been a problem.

  • AbdussamadAbdussamad Member
    edited February 2015

    Put the IP based restriction at the firewall level rather than in your authorized_keys or sshd_config file. That way they never even hit SSH.

    iptables -P INPUT DROP iptables -I INPUT -p tcp -s <yourip> --dport=22 -j ACCEPT

    This protects you again ssh zero days as well.

  • There's plenty of decent advice here, but the OP's question hasn't really been answered; how secure is the chosen method to intrusion?

  • Nekki said:

    There's plenty of decent advice here, but the OP's question hasn't really been answered; how secure is the chosen method to intrusion?

    It's very secure of course. Key based authentication defeats 90% of the attackers. IP based restriction covers most of the rest.

  • Had a CentOS 7 VM that I have not figured out all the firewall settings yet, so my nonstandard port is not working. So I have to use port 22 (with the IP restriction)
    But each day there is around 11.000 login attempts.

    But I have now installed fail2ban, and I will see if the number drops.

    Anyone with a really good firewall guide for CentOS 7? I need to open a non standard port, and the commands I have found has not worked. firewall-cmd --permanent --zone=public --add-port=2292/tcp (not my port...) and then firewall-cmd --reload but still, can't get access via SSH.

    On CentOS 6, i just add csf firewall and add the port there, and everything works.

  • The correct answer is: No, a hacker can not get legitimate access via port 22 so long he is not on your homenetwork or using your VPN.

    But he can create quite some havoc and you made it at least considerably easier for a hacker.

    @Abdussamad said:
    It's very secure of course. Key based authentication defeats 90% of the attackers. IP based restriction covers most of the rest.

    Frankly, I was shocked by that statement. Not only was there no mentioning "key based", nor is your assessment reasonable (90%, rest ...).

    And need I remind you of "[email protected]."

    Thanked by 1myhken
  • myhkenmyhken Member
    edited February 2015

    bsdguy said: Frankly, I think you've chosen a unsatisfactory solution. Assume, for some reason your IP changes or you must get at your VPS from somewhere else; then you're f-cked.

    I'm using a set of four IPs, one is my ISP (that change from time to time, so there would I have been f-cked.
    Then I have three VPN solutions with static IPs, they will not change IP, not all three of them, since they are with different companies. Two is my own VPN Servers, one is a paid VPN service with a paid static IP.

    So I don't think I will loose access this way.

  • @myhken

    Uhm, whatever firewall rule/command opens port 22 can also open any other port. Just replace the port number. (Hint: When trying that do it additionally until your setup works. Only then kill the port 22 rule).

    Thanked by 1myhken
  • myhken said: So I don't think I will loose access this way.

    I've a similar setup to yourself, I always have at least VPN 4 IPs in play plus my own home connection's IP, so whilst there is a risk that I'll loose access to my VPN servers, losing all 4 simultaneously is highly unlikely so the risk is mitigated to an acceptable level, IMO.

    Thanked by 1myhken
  • @Abdussamad said:
    Put the IP based restriction at the firewall level rather than in your authorized_keys or sshd_config file. That way they never even hit SSH.

    iptables -P INPUT DROP iptables -I INPUT -p tcp -s <yourip> --dport=22 -j ACCEPT

    This protects you again ssh zero days as well.

    Can't get this to work on CentOS 7. I get following errors:
    -bash: 91.xxx.xxx.x44: No such file or directory

    When I try to remove <> from the IP:
    Bad argument iptables Try iptables -h' or 'iptables --help' for more information.

  • Oh, hey, do everyone as they please.

    But: Why having a firewall job done by the application layer? If you like your "only from certain IPs" concept, fine, but why not having that handled by the firewall?

    Thanked by 1aglodek
  • bsdguy said: But: Why having a firewall job done by the application layer? If you like your "only from certain IPs" concept, fine, but why not having that handled by the firewall?

    Even better, handle it BOTH from the firewall (i.e. iptables filters) and the application layer (i.e. hosts.deny / hosts.allow).

  • @Nekki said:

    Thats good to hear. I uses a non standard SSH port on 90% of my VPS + IP restrictions. But as mention, I have not figured out CentOS 7 yet, so there I have to use port 22.
    Only matter of time before I get the right commands or config edit to make this happen also on CentOS 7.

  • @rds100 said:

    But how in CentOS 7?

  • rds100rds100 Member
    edited February 2015

    myhken said: But how in CentOS 7?

    How what? What's the command that is failing?

    If it's that iptables command above - remove the < > . And make sure the IP is correct.

  • myhkenmyhken Member
    edited February 2015

    @rds100 said:

    I did remove <> and the IP is correct, still the same error.
    But I found this guide for CentOS 7 now, and I got it to work now.

    The commands I had to use, beside changing the port and use AllowUsers root@IP in
    vi /etc/ssh/sshd_config was:
    semanage port -a -t ssh_port_t -p tcp 2222
    semanage port -l | grep ssh
    systemctl restart sshd.service
    firewall-cmd --permanent --zone=public --add-port=2222/tcp
    firewall-cmd --reload
    ss -tnlp|grep ssh
    then it finally worked.

    Ps! My non standard port is of course not 2222 :D

  • bsdguy said: Frankly, I was shocked by that statement. Not only was there no mentioning "key based", nor is your assessment reasonable (90%, rest ...).

    Oh sorry you have to use public key authentication and disable password authentication. I thought everyone was already doing that. Then you restrict access based on IP at the firewall level. It's not a problem to allow remote root login if you do all that.

    Most of these SSH attacks that we get are trying to bruteforce passwords. Remove that possibility entirely and what's left are zero days. Restrict access to certain IPs and you've ruled out most attempts at trying to exploit zero days. Of course you still have to protect your SSH key but if someone manages to get that then your server being exploited will be least of your concerns.

  • AbdussamadAbdussamad Member
    edited February 2015

    myhken said: When I try to remove <> from the IP: Bad argument iptables Try iptables -h' or 'iptables --help' for more information.

    You should use firewalld to manage this on CentOS 7. I am not familiar with it so I can't help.

    Thanked by 1myhken
  • @Abdussamad said:
    I thought everyone was already doing that.

    Not meaning to attack anyone here, honestly. But: I'd assume that someone SSHing as root might quite probably use passwords, too.

    Interesting (I'd hope) sidenote for those interested in security:
    I'm seeing again and again that astonishingly many seem to have a rather lose understanding of security (and OS for that matter) and tend to think in "how to" patterns. In a way that seems to be kind of a console version of "How to secure your server with the 'security' icon of XYZ-panel".
    Again, no hurt feelings intended.

  • raindog308 said: Actually, I'm browsing your private tentacle hentai collection right now.

    That's Mark_R's collection.

    Thanked by 1Nekki
Sign In or Register to comment.