Slashdot Mirror


Ask Slashdot: FTP Server Honeypots?

An anonymous reader writes "I run an FTP server for a few dozen people, and it seems like every week I have a random IP address connect to my box and try guessing 'Administrator' passwords once every five seconds or so. This poses no real risk to me, since all my accounts have custom (uncommon) names. But if this is happening to me, I would wager lots of people are at risk of low level, persistent, long term password cracking attempts. Is there a way to report the perpetrators, or any action we can take to address this kind of danger?"

19 of 298 comments (clear)

  1. ssh is the same by bugs2squash · · Score: 4, Funny

    About all you can do is briefly connect the Ethernet to a power outlet and hope that the tubes carry the high voltage across the interweb and fry their equipment. Of course, timing is everything.

    --
    Nullius in verba
    1. Re:ssh is the same by JustNiz · · Score: 3, Funny

      Mod parent up Wow this works really well!
      Since briefly connecting my ethernet to the power socket I haven't had any hack attempts at all!! That must have showed them!!

    2. Re:ssh is the same by icebraining · · Score: 4, Insightful

      Proper security measures and changing port is better than having only the former.

    3. Re:ssh is the same by WuphonsReach · · Score: 4, Informative

      Security through obscurity. That works well. NOT!

      The point of "don't rely on security through obscurity" is that being obscure should not be your only layer of defense.

      Moving your SSH service off of the default port has a few benefits:

      - Most of the standard attack scripts no longer work against your server.

      - Your security logs are 99% less cluttered (if not 99.9%), making it easier to see the more determined and worrisome attackers.

      I never leave a public facing server's SSH port on the default, it's not hard to specify an alternate port in the SSH clients and it makes my life a lot simpler when I don't have to wade through a few thousand password attempts each day on the standard port. There are a few attackers out there who do port-scanning first to find the SSH port before trying dictionary attacks, but since we don't do password authentication they're still left out in the cold unless they get our private SSH keys.

      --
      Wolde you bothe eate your cake, and have your cake?
  2. Probably not worth the effort by The+MAZZTer · · Score: 3, Informative

    They could easily be zombies or proxies you're seeing, especially zombies since it sounds automated.

  3. Well, not really... by DWMorse · · Score: 4, Insightful

    Proactively? Not really. The systems used for this are typically overseas, in countries that more or less don't care.

    However, you -can- configure your server to disregard even initial connection attempts from specific ranges of IP addresses. I solved a lot of this on my own home FTP server by (sorry comrads) telling my server to ignore connection attempts from Russia and China.

    Upon doing so, it went from a daily occurrence, to maybe one attempt a month. Usually less.

    And, if a friend ever needs to FTP in from one of these countries, it's a simple enough rule change.

    --
    There's a spot in User Info for World of Warcraft account names? Really?
  4. rate limit incoming connections based on IP by Shakrai · · Score: 5, Informative

    Easier than banning every overseas IP, IMHO anyway. This is what I do for SSH:

    # Allow SSH with a rate limit
    iptables -A INPUT -i ppp0 -p tcp --syn --dport 22 -m hashlimit --hashlimit 15/hour --hashlimit-burst 3 --hashlimit-htable-expire 600000 --hashlimit-mode srcip --hashlimit-name ssh -j ACCEPT
    iptables -A INPUT -i ppp0 -p tcp --syn --dport 22 -j LOG --log-prefix "[DROPPED SSH]: "
    iptables -A INPUT -i ppp0 -p tcp --syn --dport 22 -j DROP

    There may be a more eloquent way to do this but it gets the job done.

    --
    I want peace on earth and goodwill toward man.
    We are the United States Government! We don't do that sort of thing.
  5. Re:No by 0100010001010011 · · Score: 4, Informative

    Denyhosts also. I just set this up after finding over 40,000 failed ssh attempts in the last 3 days.

  6. Worst thing is the bandwidth drain by BlueCoder · · Score: 3, Interesting

    If your security is even modest as far as passwords there is no need to worry. More sophisticated attacks using coordinated bot nets are the really scary thing but can be countered by limiting the number of login attempts a second/minute. But it's all just extended dictionary attacks. Only someone really dedicated does brute force. This is the equivalent of someone going through a parking lot and checking to see if anyone left their door unlocked and or keys inside their car. If you can just change the port used for ftp, it cuts it down by 99 percent.

    The problem is the bandwidth. You have to pay for it anyway. Even if your server doesn't acknowledge it. Someone really dedicated using a bot net can easily give you overage charges.

  7. Re:ftp sends passwords in cleartext; sftp+denyhost by alostpacket · · Score: 5, Funny

    That would be like retrofitting a tricycle to make it supersonic.

    So you're saying it would be totally awesome?

    --
    PocketPermissions Android Permission Guide
  8. Re:Yep, by zebs · · Score: 3, Interesting

    Hmmm, on the systems I help look after we occasionally see large number of RDP sessions with invalid logons. On some rare occasions we've been able to RDP to the source IP (get to the logon screen). Gives me the impression that its a bot.

  9. SFTP. It's 2011. by bedouin · · Score: 3, Insightful

    Unless you're running an anonymous FTP to download Linux ISOs or something there's no need for it.

    Cyberduck for OS X, FileZilla for Windows, and gFTP all do SFTP and are free. If you're already using SFTP then only allow specific users and disable root access. Key authentication is ideal like others have mentioned but sometimes a hassle.

    The first (and hopefully last time) I was rooted was in '99 on a Redhat box through FTP using a buffer overflow. Since then I learned my lesson.

  10. The longer answer. by Tatarize · · Score: 4, Insightful

    The longer answer is do anything you want. I highly recommend spending a lot of time to configure an "administrator" login. Then have it take one to a fake directory with nothing important. Wait until that IP drops off the inevitable giant pile of files to be shared with other people, and then when all the stuff is uploaded. Disable it and keep the files. It seems like pretending to be there for a short while could get you many gigabytes of something. It would be like peer to peer in reverse.

    --

    It is no longer uncommon to be uncommon.
    1. Re:The longer answer. by diodeus · · Score: 5, Funny

      Years ago we found our FTP server was full. It was hacked and contained all kinds of movies and xbox games. We just happened to like movies and xbox games, so we gave it a bit more space.

  11. Re:No by Sancho · · Score: 3, Interesting

    We use honeypots purely for denyhosts purposes. These are machines which are not in DNS and should never have machines connect to it. If a machine connects, we assume that it's malicious and add it to a blocklist which is shared amongst the rest of our machines. No one ever gets in to the honeypot. One could wait for a failed login attempt to occur (it would be a little more generous to scanners who aren't trying to break in)--it's just a tradeoff. We're much harsher.

  12. Re:RMS's root password by Darinbob · · Score: 3, Funny

    He also had a README file whose contents were
    "cat: README: No such file or directory".

  13. Reply from the submitter by glassware · · Score: 3, Insightful

    I'm the guy who posted (accidentally sent it in via anonymous).

    1) I like the idea of programs like DenyHosts and Fail2Ban; as some people mentioned FileZilla also has a nifty "auto-ban" option which I've used too. I specifically like using a shared list of bad hosts; that was really what I was asking for, so thank you all! Totally answered my question.

    2) Switching from FTP is indeed an option. I originally started by using FTPS, which is nicely supported by FileZilla but not by many other programs. The trouble was that a many users had routing difficulties and were unable to reach the FTPS server from their location. The worst part was that many routing difficulties were transient: when they were at the office it would fail, when they were at starbucks it would work, when they were at a hotel it would fail, etc.

    3) I would wager that SFTP is pretty much the right solution. I figure I'll get started on looking for an SFTP replacement for FileZilla server.

  14. fail2ban by gr8fulnded · · Score: 3, Informative

    How about fail2ban? We use it to block multiple SSH attempts. It blacklists IP's for a user-defined amount of time and then unblocks them again. Works like a charm, every time. Hell, it's even locked me out on more than one time (because I didn't update the whitelist file for my workstation's IP).

    "Fail2ban scans log files like /var/log/pwdfail or /var/log/apache/error_log and bans IP that makes too many password failures. It updates firewall rules to reject the IP address."

    http://www.fail2ban.org/wiki/index.php/Main_Page

  15. shell script to auto null route brute force attack by Kamphor · · Score: 3, Interesting

    Guess it's time to give back to the community....a few years ago, I wrote a custom script to continually tail out lines at a time from /var/log/auth.log and null route the bad ip's....to date, I have 4316 ip's null routed. I have the following script running as a background job initiated from /etc/rc.local hope this is helpful to people.

    ----begin----
    #!/bin/bash
    # script to sense bad ssh or ftp login tries from the same ip address
    while [ 1 ];
    do
    # block known linux service user accounts ssh attempts
    previous=0;
    i=0;
    for badip in `awk '/sshd/ && /Failed password for /' /var/log/auth.log | egrep -i "root|bin|daemon|adm|lp|sync|shutdown|halt|mail|news|uucp|operator|games|rpm|vcsa|rpc|xfs|apache|rpcuser|sshd|ftp|kamphor|named|messagebus|haldaemon|ntp|openvpn|x11|polkituser|avahi|avahi-autoipd|htdig|pulse" | awk '{print $11}'| tail -100 | sort | uniq`;
    do
    if ! `grep -q $badip /etc/hosts.deny`; then
    echo "ALL: $badip" >> /etc/hosts.deny;
    echo "route add -host $badip gw 127.0.0.1" >> /etc/routeblock.sh
    route add -host $badip gw 127.0.0.1;
    fi
    done

    # null route any attempt at non-existant users for ssh attempts
    previous=0;
    i=0;
    for badip in `awk '/sshd/ && /invalid user/ {print $13}' /var/log/auth.log | tail -100 | sort | uniq`;
    do
    if ! `grep -q $badip /etc/hosts.deny`; then
    echo "ALL: $badip" >> /etc/hosts.deny;
    echo "route add -host $badip gw 127.0.0.1" >> /etc/routeblock.sh
    route add -host $badip gw 127.0.0.1;
    fi
    done
    # scan for behavior - probe ssh then try password
    previous=0;
    i=0;
    # first loop- check for ssh probe
    for badip in `awk '/sshd/ && /not receive identification string/ {print $12}' /var/log/auth.log | tail -2`;
    do
    if [ $previous == $badip ]; then
    i=`expr $i + 1`;
    # echo "in spoofed checker $badip $i"
    else
    i=0;
    fi
    #echo "these are the bad ip addresses: $badip $previous $i";
    previous=$badip;
    done
    # end first for loop
    #start second loop - check for failed logins
    for badip2 in `grep $badip /var/log/auth.log | awk '/sshd/ && /Failed/ {print $11}' | tail -2`;
    do
    if [ $previous == $badip2 ]; then
    i=`expr $i + 1`;
    # echo "in spoofed checker $badip2 $i"
    else
    i=0;
    fi
    if [ $i -ge 3 ]; then