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?"
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
They could easily be zombies or proxies you're seeing, especially zombies since it sounds automated.
I've used Fail2ban in the past:
http://www.fail2ban.org/wiki/index.php/Main_Page
"And the meaning of words; when they cease to function; when will it start worrying you?"
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?
I had a few meetings with local FBI cyber people, and they recommended for me to send things like that to either DISA or to them (the local field office for my area) Contact your local FBI field office and see what they say. If you can talk to their cyber division they are usually helpful. (usually...)
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.
You say this poses no real risk to you, because your passwords are immune to dictionary attacks. But ftp sends passwords in cleartext, so it actually does pose a risk to you if someone is able to sniff your packets on the public internet.
But anyway, if you feel that the risk to you is insignificant, then why are you asking the question? Are you asking it on behalf of other people who might want to security-harden their ftp servers? If those people are worried, why wouldn't they have already switched from ftp to sftp? And if they're running sftp, they can protect against attacks of the type you're describing by installing denyhosts:http://denyhosts.sourceforge.net/ Denyhosts does have a cooperative blacklisting facility of the type you were asking about.
I could be wrong, but since ftp is inherently insecure, I would be surprised if someone had created software with the same functionality as denyhosts that would work with ftp. That would be like retrofitting a tricycle to make it supersonic.
Find free books.
Most automated scans will not take the time to scan for open ports. (that I have experienced)
Also consider FTP with SSL / TLS like what can be done with vsftpd. http://vsftpd.beasts.org/
As mentioned elsewhere in this thread consider using Fail2ban which is easily configured for monitoring failed attempts at connecting to your server and can then block the IP after a configurable threshold is reached.
Denyhosts also. I just set this up after finding over 40,000 failed ssh attempts in the last 3 days.
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.
Comment removed based on user account deletion
That sums it up right there. Why? Lots of reasons:
1: A honeypot might get someone in legal hot water if someone then launches criminal activity from it. For example, if someone's honeypot was used for torrents or CP, it will be tough explaining to cops (or the RIAA's pet judge) that the owner knowingly allowed such activity to happen and hoping not to get found culpable/convicted.
2: FTP for anonymous downloads is one thing (assuming a hardened FTP server.) Anonymous uploads can be done too, provided you clean the incoming directory. FTP for users with passwords sent plaintext is just bad form. Use sftp, or scp for this.
3: Before '97, you could call an ISP or other domain and deal with someone who would be ready/willing/able to stop someone hacking from a site. These days, nobody cares, especially offshore domains. IP address banning is noble, but just not running the service unless needed is the best bet.
4: Even with IP banning, it won't do much. Blackhats have a crapload of bots on wide IP ranges. Better to just figure out what ranges to allow and deny everyone else.
5: Passwords should never be used anyway. Use S/Key or OPIE if one can't authenticate using two factor stuff. Best of all, use public key authentication over ssh. This way, there is no way a brute force attack could succeed, if the SSHGuard program or other anti-guessing daemon doesn't work.
That would be like retrofitting a tricycle to make it supersonic.
So you're saying it would be totally awesome?
PocketPermissions Android Permission Guide
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.
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.
Surely trying every doorknob on a terraced street qualifies as intent to tresspass and steal??
This tagline was transcoded to result in at least one smirk. If you experience failure to smirk, please consult your Gen
Denyhosts is the bomb. Seriously, I get weeks where I used to get hammered with ssh login dictionary attacks. Now, denyhosts nicely bans them, and best of all, it can share back with a central server so once somebody starts attacking a couple people, we all ban their asses. It's one of the first things I install on any new server. Seriously, I think I'm going to go send the DH guys another donation because they're so damned awesome.
DH is ssh-centric, though. For your FTP problem, fail2ban is better.
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.
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.
It was "carriage return".
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
I have had good results when the attacking IP is from a provider such as Comcast, AT&T, Amazon Cloud, etc.
When it's from "China Unicom Hebei Province Network", like the IP's that hit my router all day long every day scanning port 27977, no reason to even send an abuse message.
No offense meant to anyone from that part of the world.
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.
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
Who needs to synchronize ban lists? Have it ban a host for a week or so after 10 failed attempts (for both existing and nonexistent accounts, so they can't brute-force usernames). No meaningful number of brute-force attempts will get through to any box that way.
"When information is power, privacy is freedom" - Jah-Wren Ryel
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.
/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`; /etc/hosts.deny`; then /etc/hosts.deny; /etc/routeblock.sh
/invalid user/ {print $13}' /var/log/auth.log | tail -100 | sort | uniq`; /etc/hosts.deny`; then /etc/hosts.deny; /etc/routeblock.sh /not receive identification string/ {print $12}' /var/log/auth.log | tail -2`; /var/log/auth.log | awk '/sshd/ && /Failed/ {print $11}' | tail -2`;
----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/ &&
do
if ! `grep -q $badip
echo "ALL: $badip" >>
echo "route add -host $badip gw 127.0.0.1" >>
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/ &&
do
if ! `grep -q $badip
echo "ALL: $badip" >>
echo "route add -host $badip gw 127.0.0.1" >>
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/ &&
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
do
if [ $previous == $badip2 ]; then
i=`expr $i + 1`;
# echo "in spoofed checker $badip2 $i"
else
i=0;
fi
if [ $i -ge 3 ]; then
This is the sort of thing I've considered doing, but I've worried about locking myself out, if I'm trying to connect remotely and having a particularly bad case of clumsy typing.
/var/log?
A similar example to my worry follows.... it's a very interesting idea, but I wonder what procedures you have in place to prevent the following??
---
Sancho:> Hey, orangesquid, can you check out something on sancho3 for me, in
orangesquid:> sure, let me open a shell
os@orangesquid.net:~$ ssh sancho3.sancho.com
Resolver timed out
os@orangesquid.net:~$ grep sancho3 ~/sancho-hosts
11.22.33.49 sancho3
os@orangesquid.net:~$ ssh 11.22.33.46
^C "Dammit, clumsy hands"
os@orangesquid.net:~$ ssh 11.22.33.49
Connection timed out
os@orangesquid.net:~$ ping 11.22.33.49 -c3
Ping 11.22.33.49 (64 bytes) from 99.88.77.66
---
4 packets transmitted, 0 packets received
"Stupid auto-block..."
os@orangesquid.net:~$ mail sancho2000@gmail.com
Hey, can you unblock me? Typo!
.
os@orangesquid.net:~$
MAIL FROM: postmaster@sancho.com
You attempted to send mail to "sancho2000@gmail.com" from 99.88.77.66. This IP address has been banned. Sorry.
--TheOrangeSquid Is it any wonder things seem so awry? We swim in a sea of confusion and don't have to think to survive
It's a pretty simple concept - a basic heuristic for dodgy-looking connection attempts, and then blocking the originating IP at the firewall. Once it's reasonably bug-free it won't need maintenance until Linus decides to switch to a different firewall again.
Hail Eris, full of mischief...
E pluribus sanguinem
HoneyPots can be an important layer. But you need the other layers. We use the following layers to protect SSH (https://it.wiki.usu.edu/ssh_description )
1.) The firewall limits the vulnerable scope of SSH to a few trusted hosts.
2.) The firewall can also be used to prevent credential guessing by rate-limiting connections to the SSH port.
3.) The SSH Port is treated as a shared secret. Only interesting, targeted attacks find the SSH server.
4.) The SSH server should not allow known usernames including root. The attacker must find a username.
5.) The admin is trained to create good passwords for his usernames.
6.) SSH users are taught to verify the identity of their systems when they first connect.
7.) System admins must regularly review the activity of their SSH servers.
8) Security monitors all SSH connections, including ones on non-standard ports. We follow up on connections that seem interesting.
9.) USU has SSH HoneyPots that help us respond to SSH attack.
SSH HoneyPots give us several benefits:
1) They make it easy to automate blocking SSH attackers, with virtually no chance of false positives. Some patterns of attack are designed to bypass Fail2ban, but the HoneyPots have to problem handling them.
2) We notify remote ISPs (and remote managers) that they have attacking systems. This is surprisingly effective. When we started (6 years ago) less than 1 notify in 8 seemed to have any effect. Now about 1/2 of the notifications seem to be have an effect. And remember, virtually every one of those attacking computers belongs to an innocent victim. Notification helps them, and it improves the overall security of the internet. We have also confirmed that notifications drive away some attackers.
3) We collect and analyze guessed credentials.
- If they meet our complexity requirements, they are added to our central black-list.
- Patterns of credentials reveal patterns of attack and patterns of attackers. It's a Heisenberg thing. An attacker both changes the target, and reveals information about himself. Password guessing reveals a lot of information. Virtually every attack has been a unique combination of credentials. You can do cluster analysis against the combinations. You can find relationships between attacks and IPs. You can track how these relationships change over time. You can correlate this information with your other intelligence. The FBI came to us and asked about some attacking IPs. Almost all of them had hit our SSH HoneyPots. We were able to pass all this intelligence back to them.
Our SSH Honeypots (and several other SSH servers) now have the following banner:
---
USU tracks internet abuse. We have SSH honeypots that automate
the process of detection, notification, and blocking. These
honeypots also collect credentials and analyze them.
If this system is a honeypot, your access will be reported as abuse.
Your credentials will be logged. Your IP address will be blocked.
If you believe that your access has been misidentified as abuse,
please contact USU IT Security at security@usu.edu or 435-797-1804.
---
Miles
People who worry about computer security are forbidding the clients of my company from installing software on their MS Windows computers. That means they cannot install the software to do SFTP on their computers - so in the name of security they are using plain old vanilla FTP! For as long as this stupid situation persists I'll be using FTP. The alternatives the clients can actually use are stupid web based FTP done badly ideas like those idiots that set up a system where a password change wouldn't keep people out.
I think I'll be hosting it until we either get some SFTP client that becomes as ubiquitous as winzip or until Microsoft bundle one in.
There's a lot of clunky web based FTP front ends out there but nothing I've seen that does things well with uploads doing https all the way and leaving FTP out of it completely.
Sorry but as far as i remember Filezilla server does not do SFTP only FTPS(implicit and explicit) as secure connections.
http://en.wikipedia.org/wiki/File_Transfer_Protocol#Secure_FTP
Although the end result is the same the process is different. Its like watering your garden with a supermodel, you can fill a watering can or use your hose but the end result is the same... your pants will be wet.
$ unzip, strip, touch, finger, grep, mount, fsck, more, yes,fsck,fsck,fsck,umount, sleep