Find the answer to your Linux question:
Page 1 of 2 1 2 LastLast
Results 1 to 10 of 11
A couple of weeks ago I ran lastb on my server, and it came out with nothing. Long story short, Today I ran this: Code: lastb | wc -l 88202 ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Linux Engineer Freston's Avatar
    Join Date
    Mar 2007
    Location
    The Netherlands
    Posts
    1,049

    I'm under attack (sweeps)


    A couple of weeks ago I ran lastb on my server, and it came out with nothing. Long story short, Today I ran this:
    Code:
    lastb | wc -l
    88202
    From what I see there are patterns discernible. A lot of pouncing from not to many different IP's. With roughly 10~20 login attempts per minute, I think my adversary isn't human. They are also originating from different parts of the world, Latin America, Asia, USA...

    Now what should I do? They have not broken in yet. And I've been doing some reading on security. I guess I am a bit shocked right now, sweaty palms and everything. But I know, /I know/, this is nothing out of the ordinary. Just some bots finding a filtered ssh port on their sweeps, and now pouncing on the door.

    I've read about these things enough, but as this is Real World, not exercise, I want to make sure I understand the basics and take the necessary precautions.
    I am behind a hardware firewall, that forwards port 22 to my server
    My server runs Slackware 12.1
    It disallows protocol 1 and root logins
    My accounts have odd names, not guessable by permutation of my personal details (nor are they 'lesbian' or 'playboy' as one of the attackers thought; he'd wish... I don't even shave my beard on most days )
    My passwords are long and secure

    What else can I do? Can I run commands when someone logs in to my machine if that someone isn't me? Is there a better way to deal with this than I have done? Without loosing functionality I mean. Can and how do I set a login delay of ~5 seconds on a failed attempt?

    What are signs to look for that someone broke in?



    Edit: Is it a generally /bad/ idea to sweep back, run a portscan on the incoming IP's? Can I bet the machines (IP's) used are zombies? Real World is different than reading about it.
    Can't tell an OS by it's GUI

  2. #2
    Just Joined!
    Join Date
    May 2008
    Posts
    37
    get a firewall and allow port access only from your ip from no-ip.com .

  3. #3
    Trusted Penguin Dapper Dan's Avatar
    Join Date
    Oct 2004
    Location
    The Sovereign State of South Carolina
    Posts
    4,630
    I've experienced this several times. The first time got me in a real panic but now I don't worry too much about it. Like you, I have taken all the precautions you've mentioned. Make all passwords, long, convoluted and unpredictable. When not in use, I simply shut off access through port 22 in my router. If I need it, I'll VNC into that box and open it up.
    Linux Mint + IceWM Registered: #371367 New Members: click here

  4. #4
    Linux Engineer Freston's Avatar
    Join Date
    Mar 2007
    Location
    The Netherlands
    Posts
    1,049
    Quote Originally Posted by proprietarysucks
    get a firewall and allow port access only from your ip from No-IP - Dynamic DNS, Static DNS for Your Dynamic IP .
    Thanx! That looks good. I'll check that out in more detail.

    But the thing is, I need to be able to access my server from remote locations. Right now it's only in testing phase, but I intent to serve valuable data and important services on it. So I can't lock it by IP. I mean, I can configure my hardware firewall to forward any port into nothingness safe for known IP's. But I need to be able to access my machine from unknown IP's. Maybe if you want to comment on that?? I'd appreciate it.





    The way I see it, my machine is only secured with a login name and a password. To crack my box you need:
    Phase 1: a thousand monkeys scanning IP's at random until hit
    Phase 2: a thousand monkeys randomly guessing login names (never knowing when they hit)
    Phase 3: a thousand monkeys randomly guessing passwords
    Phase 4: ... ehm ...
    Phase 4: Profit!

    Right (Y/n)?:

    Quote Originally Posted by Dapper Dan
    I've experienced this several times. The first time got me in a real panic but now I don't worry too much about it. Like you, I have taken all the precautions you've mentioned. Make all passwords, long, convoluted and unpredictable. When not in use, I simply shut off access through port 22 in my router. If I need it, I'll VNC into that box and open it up.
    Thanx!
    Yeah... I am thinking this is just something you need to put up with if connected. This is just normal (if I may use that word here).

    As mentioned above, you'll need a lot of monkeys to permutate every letter (capital or otherwise), number and symbol on the keyboard to get to my long passwords. And that only helps /if/ you get to my login names, which are equally unguessable.

    But I'm not not running this server for the heck of it. I intend to build functionality in this after extensive endurance testing. Have I done my utmost? Not to step across proprietarysucks's post here, but how much do I have to fear from these sweeps?
    They didn't come close to anywhere near a valid login name, although I have found several holes in other systems I have set up earlier through this exercise. They are guessing common names. I'm glad I'm not called Eric or Patricia for that matter. They are guessing those. That /is/ something to consider.
    Can't tell an OS by it's GUI

  5. #5
    Linux Newbie Geeth's Avatar
    Join Date
    Apr 2008
    Location
    Brisbane Aus
    Posts
    176
    You mentioned port 22, if you are using it for ssh, then you could also change the port that ssh uses.

    Login to your server and obtain root access through SU.

    Edit the file /etc/sshd/sshd_config

    At the top of the file, you will see something similar to:
    Port 22
    Protocol 2, 1
    Just remember when you ssh in, you MUST provide the port since pretty much all programs will default it to 22.

    i think the code is something like

    Code:
    ssh -p 2254 <ip>
    but thats from memory and I'm tired
    This may help a little though a port scan will show it open, but theres no way around that unless you close the port of course.

  6. #6
    Linux Newbie SagaciousKJB's Avatar
    Join Date
    Aug 2007
    Location
    Yakima, WA
    Posts
    162
    I believe the simplest thing you could do, is disable passwords, and use keys instead. This way no matter what, they will not login.


    However, if you like passwords over keys ( I do too ), you can use a script called denyhosts. It will take any IP that has over a certain amount of failed login attempts on ssh and then adds them to your /etc/hosts.deny in whatever fashion you wish. I set mine to deny ALL, but I think default is only ssh.

    The greatest part about denyhosts is that, the IPs that are collected are pooled, and kept on a community database, and this community database is also preloaded. So, in essence, you will be helping to add these IPs to a massive list of bad IPs, if they're not on it already. By the sounds of it it's just a bot net, so I doubt your server is the only they're trying against; if they ran into one with denyhosts, then they will be on that blacklist.

    SourceForge.net: DenyHosts

  7. #7
    Linux Engineer Freston's Avatar
    Join Date
    Mar 2007
    Location
    The Netherlands
    Posts
    1,049
    Quote Originally Posted by Geeth
    You mentioned port 22, if you are using it for ssh, then you could also change the port that ssh uses.
    Yeah I looked into that. What I think I can do is give SSH a really high port, one that nmap doesn't scan by default and send port 22 to an IP out of my normal DHCP range. It wont help against a human with the intend of entering my system, but it could throw the bots a little off track I think.

    I'm not really sure if it works like that though.

    Quote Originally Posted by SagaciousKJB
    However, if you like passwords over keys ( I do too ), you can use a script called denyhosts.
    Yeah I want to keep the username/password login combo. It's just easier than carrying keys around.

    I doubted the effect of DenyHosts.py as a means to block attacks. My reasoning was that all attackers are zombies. I then thought hosts.deny would eventually outgrow my root partition

    But then, I didn't know this:
    Quote Originally Posted by SagaciousKJB
    The greatest part about denyhosts is that, the IPs that are collected are pooled, and kept on a community database, and this community database is also preloaded. So, in essence, you will be helping to add these IPs to a massive list of bad IPs, if they're not on it already. By the sounds of it it's just a bot net, so I doubt your server is the only they're trying against; if they ran into one with denyhosts, then they will be on that blacklist.
    I'm gonna try this first then.



    ____

    (after one month)
    Unsuccessful attacks > 90,000
    Successful attacks = 0
    Unique number of attackers = 98
    Unique attacks (discarding retries) ~ 49,000

    And by far the #1 login name they are attacking = root
    That just goes to show you it /is/ a good idea to disable root logins. Not many systems default to this.
    Can't tell an OS by it's GUI

  8. #8
    Linux Newbie Geeth's Avatar
    Join Date
    Apr 2008
    Location
    Brisbane Aus
    Posts
    176
    I read your sig, with root being the username they are trying..

    If you want to, you could try disabling root log in so only su (and sudo though dont know if slack has it) to get root access

    Code:
    chsh -s /bin/false root
    To lock
    Code:
    sudo passwd -u root
    To unlock.

    If you are going to be logging in from only 1 location then you might want to add
    ALL:ALL to /etc/hosts.deny
    and only have the ip that you will be logging in from in /etc/hosts.allow.

    That it quite limiting.


    Also at one point I think you mentioned what to look for... I don't know with slackware but I know with bsd you get daily security audits to the root account. If it doesn't default with that in slackware then you may be able to download something similar or activate it.

    Another thing I thought of. If it's a automated system then maybe if you have you modem off for a period of time, it may think you dont exist and stop... thats a big maybe and you will have no connection. But never

  9. #9
    Linux Guru bigtomrodney's Avatar
    Join Date
    Nov 2004
    Location
    Ireland
    Posts
    6,133
    Quote Originally Posted by Freston View Post
    Yeah I looked into that. What I think I can do is give SSH a really high port, one that nmap doesn't scan by default and send port 22 to an IP out of my normal DHCP range. It wont help against a human with the intend of entering my system, but it could throw the bots a little off track I think.
    Quote Originally Posted by Freston View Post
    And by far the #1 login name they are attacking = root
    That just goes to show you it /is/ a good idea to disable root logins. Not many systems default to this.
    These are the best two pieces of advice in running ssh on your box. Most of the scripts out there are bulk attacks by scripts so you don't even need to pick a crazy port up in five digits...a lot of them brute force port 22 in the knowledge that if you're running on 22 chances are you're not using keys and you allow root login.

    I used to get up to 300 attempts a day when I ran on 22. With the port I run on now I get absolutely zero...

  10. #10
    Linux Engineer Freston's Avatar
    Join Date
    Mar 2007
    Location
    The Netherlands
    Posts
    1,049
    Although my opinion on denyhost is quite favorable, I don't want to change to many things at the same time. So I gave the ssh daemon a port higher than what nmap scans by default. And since then I haven't had any more attacks.


    We likes it...


    ...yessssss they keep their filthy hands to themselves :cough: my preciousss
    Can't tell an OS by it's GUI

Page 1 of 2 1 2 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •