How to PREVENT a user from logging in through SSH

Discussion in 'Linux Networking' started by Ignoramus10392, Apr 7, 2008.

  1. I think that after limiting logon rights to a set of accounts, I am in
    a good shape. These rate limiting rules can easily get me DOSed and
    locked out. (unless the limits are per IP)

    i
     
    Ignoramus15795, Apr 8, 2008
    #21
    1. Advertisements

  2. I've never been clear on the exact meaning of "limit-burst", but I think
    your explanation might have finally crossed my confusion threshold.

    *If* I understand correctly, the idea is that 3/minute is the steady
    state limit. But if the system is sufficiently quiet (ie. no requests
    for the past 40 seconds), up to 5 connections can be permitted within a
    single "instant"? Is that right?

    Thanks...
    Andrew
     
    Andrew Gideon, Apr 8, 2008
    #22
    1. Advertisements

  3. Also he didn't understand how to configure bind to allow zone
    transfers to happen securely, I fear...

    [..]
     
    Michael Heiming, Apr 8, 2008
    #23
  4. Ignoramus10392

    Jurgen Haan Guest

    Give them a non-usable shell.
    /bin/false or /bin/nologin
     
    Jurgen Haan, Apr 9, 2008
    #24
  5. Um, these users NEED to log in, just not from SSH. They need to log in
    from GDM.

    i
     
    Ignoramus22864, Apr 9, 2008
    #25
  6. Ignoramus10392

    David Brown Guest

    Yes, that's it. I think a lot of people find it difficult to figure out
    until they can imagine a suitable analogy, and then it "clicks".
     
    David Brown, Apr 10, 2008
    #26
  7. Ignoramus10392

    David Brown Guest

    Ignoramus15795 wrote:
    No, the limits are not per IP (it's probably possible to do that using
    iptables - there's modules for all sorts of things). And certainly
    limiting your ssh accounts and their login rights are the most important
    step for securing your ssh. But I don't think the rate limit rules here
    are going to make it more likely to get you locked out by a DOS attack.

    First off, when you are looking at defending against DOS attacks, it's
    important to analyse the risks. Are you actually a likely target for
    such an attack? If you can imagine that someone will have motivation
    for attacking your particular machine (financial motives, revenge, or
    whatever), then you are perhaps at high risk and must plan accordingly.
    For the huge majority of sites, however, there is little risk - a
    cracker will pick *your* site more or less at random, and when his ssh
    cracking effort is failing due to rate limiting, he will simply move on
    to an easier target.

    Secondly, if you *don't* have rate limiting enabled, then a DOS on your
    ssh port will be far worse, since it will consume more resources on your
    system and network - perhaps causing other services to fail as well.

    It is also perfectly possible to avoid the possible problem in at least
    two different ways. If you have a fixed IP address from your remote
    location (such as your home office), then you can simply insert a rule
    ACCEPTing all ssh packets from that address (and if you don't have a
    fixed IP address, and consider your site a high-risk target, then it's
    high time you got such a fixed address. Filtering on IP addresses is
    not full-proof, but it's an easy and cheap way of greatly improving your
    security).

    An alternative method is to have a second server on an independent IP
    address (and perhaps even an independent connection to the Internet)
    which will act as a backdoor server. Obviously this needs to be equally
    secure, but since it is not hosting your website (or other services), it
    is a very unlikely target. This machine should then have privileged
    access to the main server via an independent Ethernet port (which is
    much harder to fake than a privileged source IP address). Then if you
    need to, you can tunnel your ssh to the main server via the backdoor
    server. You could even drop the Internet-facing ssh access to the main
    server altogether - any breakins then need to compromise two machines.
     
    David Brown, Apr 10, 2008
    #27
  8. I can see being a target of a specific person (not that I know of
    anyone, but USENET and all, it is possible). I have a strong server on
    a good network, and it is not easy to bog it down with ssh requests.
    I use backdoors a lot in form of SSH tunnels, and this could be a very
    good idea.

    i
     
    Ignoramus9437, Apr 10, 2008
    #28
  9. See hashlimit module:

    The idea is to have something like
    ’limit’, but either per destination-ip
    or per (destip,destport) tuple.

    It's pretty flexible.

    - Andrew
     
    Andrew Gideon, Apr 10, 2008
    #29
  10. Ignoramus10392

    Jurgen Haan Guest

    Ah.
    Ok.. not going to bother about the usefulness of that stuff.

    Use groups.
    use DenyGroups in your sshd conf to deny them access.
     
    Jurgen Haan, Apr 11, 2008
    #30
  11. Ignoramus10392

    Jurgen Haan Guest

    rectification:
    Use AllowGroups.
    It's much cleaner. :)
     
    Jurgen Haan, Apr 11, 2008
    #31
  12. I simply use AllowUsers. Does exactly what I want. I am happy. Yes, I
    verified it.

    i
     
    Ignoramus6985, Apr 11, 2008
    #32
  13. Ignoramus10392

    Jurgen Haan Guest

    Same principle, with the difference that for every new user, you need to
    change your sshd_config if you want them able to log in through ssh.
    With groups you can just assign the user to the appropriate group.

    But indeed. AllowUsers will do aswell.

    -R-
     
    Jurgen Haan, Apr 11, 2008
    #33
  14. Yes, but, I do not get new users often. I have a list of users in a
    "system-night" shell script that sets sshd_config to that list. So
    things are easy to change. I just change the night script and it takes
    care of everything on all my machines.

    i
     
    Ignoramus9437, Apr 11, 2008
    #34
  15. David Brown wrote:

    are you saying a source mac address is harder to spoof than a source ip?
    if so ... wtf dude they can both be set easily with ifconfig.
     
    [email protected], Apr 14, 2008
    #35
  16. Ignoramus10392

    Simon Tatham Guest

    No, he's saying that if the target machine has two separate
    _physical Ethernet connections_ and is only granting privileged
    access to packets coming in through (say) connection A, it's pretty
    hard for an attacker to arrange for their packets to come in through
    A if their only direct access to the machine is through B and
    there's no other connection between the two networks.

    MAC addresses should be irrelevant to that.
     
    Simon Tatham, Apr 14, 2008
    #36
  17. Ignoramus10392

    David Brown Guest

    Yes, that's what I meant. I don't know for sure that it's impossible to
    fool the target into thinking a packet is coming in on a different
    interface, but it's a lot harder than doing an ifconfig on the source
    machine!
     
    David Brown, Apr 14, 2008
    #37
  18. ok sorry misunderstood
    indeed that would be pretty impossible imho
     
    [email protected], Apr 15, 2008
    #38
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.