Ask Slashdot: FTP Server Honeypots? 298
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?"
ssh is the same (Score:5, Funny)
Re:ssh is the same (Score:4, 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!!
Re: (Score:2)
*whoosh*
re: whossh (Score:2)
That's pretty much what my equipment said when I fed 110v to the Ethernets...
Re: (Score:2)
I am too dense to see the wit in your original post, I apologize. :)
Re: (Score:2)
Dell: welcome to dell customer service, how can i help you?
Customer: I got hacked so i fought back with electricity, and now the monitor isn't working properly.
Dell: *sounds of someone securing a noose*
Re: (Score:3)
At Dell the response would probably be "Have you tried rebooting the computer?"
Re: (Score:2)
You may be the only one of us who hasn't made a "fool-killer". It's a 120V plug on one end connected to alligator clips on the other. Great for connecting ANYTHING to a power outlet, especially things that shouldn't be.
Re: (Score:3, Insightful)
Stop allowing password-based access. There is no way anyone is going to be able to guess a key by connecting and trying them.
Re: (Score:2)
That's a fine idea for private systems. For private servers I use only ssh with certificates. Poof, hack attempts are gone.
For a public facing FTP server the idea is to keep it easy. It should work with any FTP client out of the box with no configuration. In this case your only defense is to pick real username and long, quality passwords.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:3)
It actually works very well. Almost every break-in attempt is from a script. Almost every script only tries the default port. You can easily eliminate a very large number of script attacks just by changing the port.
Re:ssh is the same (Score:5, Insightful)
Proper security measures and changing port is better than having only the former.
Re:ssh is the same (Score:5, Informative)
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.
Re: (Score:2)
I finally solved the issue of logs of failed logins with a way simpler metod... in the initial message I tell everybody the root password.
Been years since I saw one of those pesky messages.
Re: (Score:2)
RMS's root password (Score:3)
It was "carriage return".
Re:RMS's root password (Score:4, Funny)
He also had a README file whose contents were
"cat: README: No such file or directory".
Re: (Score:2)
I have a cuckoo bird who listens for such traffic and dangles my keys on the modem connector when it happens.
Re: (Score:2)
Damn. I thought that only worked on Kermit connections.
+1 Cliff Stoll reference
Re: (Score:2)
Send the Phone Spiders!
Re: (Score:2)
Or, you could geolocate their IP and nuke them from orbit. It's the only way to be sure.
Probably not worth the effort (Score:4, Informative)
Re: (Score:2)
What? First, I had to worry about zombies eating my flesh - Now, I have to worry about them hacking into my FTP server, too?!?
Re: (Score:2)
Re: (Score:2)
They are, however, bloody annoying and make spotting anything important that much harder.
If you know legit connections will be in certain IP blocks, ban all others.
If not but you've decent FTP software, have it block access from any IP that tries to access specific accounts (such as Administrator, samba, nagios or whatever ones that both don't exist and are being targeted on your box).
If you prefer something more entertaining, use Linux' packet munging code. What you want to do is detect inbound connections
Re: (Score:3)
On my WWW server all common IIS exploits are HTTP/1.1 301 Moved Permanently Location: http://www.microsoft.com/%5Bsame [microsoft.com] path]
Fail2ban? (Score:3)
I've used Fail2ban in the past:
http://www.fail2ban.org/wiki/index.php/Main_Page [fail2ban.org]
Re: (Score:2)
I second Fail2Ban, I've set my tripwire VERY tight for services. I also agree with the following post, SFTP, I'm phasing out FTP myself. About bloody time.
Re: (Score:2)
Yeah, there are a few script package deals, fail2ban, denyhosts(?), etc.
Or you can just modify iptables / pf / whatever your firewall is directly. I've got a rule on pf to plonk any traffic on ssh if more than 3 connections are made in some amount of time.
Of course, all of these aren't immune to massive distributed attacks, as a billion * three attempts is still 3 billion attempts.
Re: (Score:3)
Except that for the more serious attackers, who have botnets at their disposal, it doesn't do much. In a attack by a botnet, each IP address only hits your server a handful of times and they're synchronized so that each bot tries a different username/password combination. But since there are a few thousand or tens of thousands of machines in the botnet, it adds up to a few tens of thousands of at
Re: (Score:2)
Yep, I've been doing and saying this for years. If Asia, Russia, South America are not interesting markets for my site/service/product/email, I simply block the IP ranges from hitting the respective ports. I'm certainly not about to sell high-end gaming computers or consulting services to China, so they're more than welcome to find some other host to crack.
Extra Special Content for China (Score:2)
You might as well provide some customized content for your Chinese visitors. Falun Gong literature, Tibetan Buddhist literature, clones of the epochtimes.com newspaper, an occasional Jasmine Revolution or Grass Mud Horse.
Well, not really... (Score:5, 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.
rate limit incoming connections based on IP (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.
Re: (Score:2)
Have you ever thought of just running ssh on a port other than 22? I haven't use 22 in many years. We get tons of garbage attacks on the webserver, but I haven't had a single attempt on my ssh server in years. Not one. I still check the logs, but now it takes seconds instead of an hour. One less thing to have to worry about.
Putting ftp on a different port(s) is much more problematic, but changing sshd is trivial.
Re: (Score:2)
Even better.
iptables -A INPUT -s 8.0.0.0/6 -j DROP
Re: (Score:2)
Every once in a while some one will do something. After checking my logs I found one day I found some attacks coming from a university in the UK. Sent that section of the log to the admin of the school. I got a nice email back thanking me for email because it allowed him to find and fix the machine that was compromised.
Another option would be to write a script that would detect any attempt at admin access that fails more than three times and block the IP for a week or so.
Re: (Score:2)
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.
That's a pretty good idea. I take it you use the ip blocks given in http://www.ipdeny.com/ipblocks/ [ipdeny.com]
The only slight snag is that the IP I'm on at work in the UK doesn't seem to be listed, so I'm not sure how reliable this list is, although I guess a false negative is better than a false positive.
iptables-by-country (Score:2)
Block by country dynamically: https://github.com/bugi/iptables-by-country [github.com]
It's a bit cobbled together, but it works for me.
DISA or FBI (Score:2)
Re: (Score:2)
Not unless you are someone of particular noteworthyness. A government official, a celebrity of any kind. Then you'll get their attention. Because the police know that even a famous singer will raise hell if they talk about how useless the police are.
honeypots (Score:2)
I always found that honeypots also attracted MORE attention to the network, rather than serving as a tool of defense.
Essentially, even if you did get the police involved to the point where they could trace the hackers, chances are they are using some type of TOR technology, and the ones that aren't, the little bobby droptables of the world, probably aren't worth prosecuting.
Save yourself the headache and forgo the unnecessary risk and stress of honeypotting.
Public FTP today... (Score:2)
I would recommended that you use SSH/SFTP except for FTP FTP is one of those old standards made before people realized that they could sniff networks, and pull login names and passwords.
FTP and Telnet are one of those simple protocalls if you are woried about security, HTTPS, SSH and SFTP
Re: (Score:2)
This doesn't change the problem, brute force attempts come through on ssh too. All you solution does is transfer the question to a different port.
That said, I prefer scp myself.
Re: (Score:2)
Require client certs?
Re: (Score:2)
Can SFTP do resume downloads and uploads yet?
Re: (Score:2)
Put a simple "here's how to use SFTP, if you want to deal with me, use it" text file in the FTP Server, if you really feel like educating your partners. If you don't, just show them the finger if they're too stupid to use SFTP.
Sorry, but it's not my duty to explain security to people for free. I get paid for that.
Re: (Score:2)
Odd. Just yesterday I added an "S" to a project (in front of the "FTP") and nobody raised a concern, it was signed without a problem.
My partners don't care about protocols or technical tidbits. They care about a working interface. For them, using SFTP or FTP is the same as long as their interface delivers their data. If you're concerned with your customers, give them what they need to access your files instead of leaning back and complaining that you'd lose business if your increase security.
it's probably the US government (Score:2)
seriously. read the HBGary emails dumped by anonymous. the guy was running crack programs against people he found on irc.
and this was a federal government contractor with millions in income.
its only the tip of the iceberg.
James Bamford's book The Shadow Factory describes specifically how their new system, Turbulence, provides 'offensive' capabilities.
(coincidentially, two of the documents that whistleblower Thomas Drake is under Espionage Act indictment for were related to Turbulence)
im not saying the US govt is targeting you (Score:2)
im saying there are probably a lot of people who work for the government who are doing a lot of 'testing' of their little toys on the unwitting civilian population. nothing makes this more clear than the HBGary emails.
Re: (Score:2)
So you mean I should disable the automated DDoS response to hack attempts?
fail2ban or similar (Score:2)
Personally I use the lfd daemon with the csf firewall script on my servers. fail2ban is similar.
People should not get unlimited attempts to connect to your services.
At the same time, you don't want to clog up your firewall rules with thousands of denied IPs, so I usually set the filter rather high so it will not impact real users (you would be surprised how many users need 10 or 15 attempts to guess their password if they forgot) but only people really performing a serious brute force password guessing atta
ftp sends passwords in cleartext; sftp+denyhosts (Score:3)
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.
Re: (Score:2)
retrofitting a tricycle to make it supersonic.
I like your ideas. Do you have a newsletter I could subscribe to?
Re:ftp sends passwords in cleartext; sftp+denyhost (Score:5, Funny)
That would be like retrofitting a tricycle to make it supersonic.
So you're saying it would be totally awesome?
Change Ports! (Score:3)
Also consider FTP with SSL / TLS like what can be done with vsftpd. http://vsftpd.beasts.org/ [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.
Worst thing is the bandwidth drain (Score:4, 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.
Lots of Options Here (Score:2)
Option 1 - set an access list on your border router and permit connections only from the networks of your users
Option 2 - eliminate FTP externally, make everyone connect via VPN and run FTP internally.
Option 3 - Option 1 plus SFTP rather than FTP.
There are more options of course. There are ways to mitigate the number of attacks, but you have to research and implement them. Good luck!
I wrote a nice security script for that... (Score:2)
Re: (Score:2)
I did the same (except not making it present as a Windows box. =P)
Just a simple perl script that parses for patterns I can specify and performs actions based on the thresholds I set in each recipe.
I've got it so X failures in Y hours might lock you out for a time, but then re-allow. Z failures in Y hours will result in a permanent ban, etc.
It's not as full featured as a full adaptive firewall, but it lets me watch what I want to watch. Both user logins as wells as specific 404s from apache, etc.
Give them a VIRUS (Score:2)
Let's see how stupid they are. Find a nasty virus variant, package it in a file called Kiddy_Porn.exe and drop it on your server. Set up an account with the login Administrator:Password and have that account point to just this file. Maybe put some others in a directory to give it some legitimacy.
Monitor your logs and laugh your butt off when you see get /kiddy_porn.exe
5 seconds (Score:2)
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.
So, your week lasts for about 5 seconds?
Re: (Score:2)
that's totally not what that says and i can't even mis-parse it to say that
SFTP. It's 2011. (Score:4, 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.
Here's the irony (Score:3)
Let them in. (Score:2)
I wrote a (T)FTP server that after 6 trys gives the user a 6 minute delay; after another 10 tries another delay (15 minutes) is applied, but after 20 to 30 (psedo- random) total failed attempts in one day, the user (irregardless of username) is given what seems like access to the system. They can list a limited set of small "files and directories", although none actually exist, and all simulated file contents are mundane, boring, and severely rate limited.
Only one fake "guest" account is allowed at a t
Did you trace the IP address? (Score:2)
Alternately, if you are seeing distributed (botnet) attempts, there isn't much point in trying. You'll have dozens (if not more) of different addresses, and they are almost always all transient anyways. You could spend your time going through all t
Re: (Score:2)
I would be it's coming from China.
I get fairly periodic hits to my firewalled router. They probe random ports a couple of times then disappear for 40 minutes, then do it again, pretty much 24/7/365.
There's more than just .cn IPs in there, but the .cn ones have persisted for years.
Setup a fake login (Score:2)
Setup a fake login with a separate file structure. Fill it with Goatse and gay porn.
Alternately (or in addition to) add some random viruses that you know they'll click on.
There are other ways... (Score:2)
Fail2Ban seems to work well, and one of the mail servers I use does it, but i asked him to not use int on my server - I wanted the wrapper option instead of iptables, and my admin partner balked. He wanted to keep the bans in place for years, which is fairly pointless, except he has a secret admirer that comes back and hax on his system every 2 years or so. I'm not sure i can take him anywhere with me any more, he's pissed someone off who has more scripts than he does. Fortunately his secret admirer is n
Re: (Score:2)
BTW, you ARE using ftps or something secure, aren't you? Plain old FTP is so insecure you need to run it in jail, non-root, no write perms, and mark everything r/o.
I have a team here that uses JScape, but there are other FTPS, S/FTP, and such tools out there. Gotta do it, my friend. FTP is nearly useless. I use SCP a lot, but I will tolerate the clients.
Check your program settings (Score:2)
Filezilla can do automatic bans. I am sure your favourite FTP server can do that as well. 5 failed login attempts = auto ban for 3 hours. That solved all our problems in the office.
For home, just running an FTP server on a different port got rid of these kind of attacks completely. Of course, blocking hinet and other chinese netblocks works as well. You have a lot of options here.
Reply from the submitter (Score:4, 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.
Re: (Score:3)
If the content is designed to be public readable, setup a download only FTP site that requires no authentication, and do the uploads via SCP.
If you need to allow uploads, setup a folder that allows anonymous uploads, but don't let FTP users download from that folder. Retrieve t
Re: (Score:3)
That doesn't make sense. SFTP is not a normal FTP server exposed over an SSH or SSL tunnel. There's no "FTP server config" you can screw up and magically transform an SFTP server into an FTP server. Even if there were, server configs don't change on their own, it doesn't real
fail2ban (Score:4, 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 [fail2ban.org]
Re: (Score:3)
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.
shell script to auto null route brute force attack (Score:3, Interesting)
----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
SSH HoneyPots have many benefits. (Score:3)
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
Re: (Score:2)
And the long answer. All you can do is firewall, and use things like fail2ban.
Re:No (Score:5, Informative)
Denyhosts [sourceforge.net] also. I just set this up after finding over 40,000 failed ssh attempts in the last 3 days.
Re: (Score:3)
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.
Re: (Score:2)
Re: (Score:3)
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.
Re: (Score:3)
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 y
Re:No (Score:4, 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.
The longer answer. (Score:5, 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.
Re: (Score:2)
Depending on the nature of "something", you might not actually want to have it. If someone would upload some pirated terrorist child porn to your server, left a log file on his PC and gets busted by the cyber police, you and your server would be their next target.
Re:The longer answer. (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.
Re: (Score:2)
3 would probably be "charge for it". Since everything else is in place.
Re: (Score:2)
Re: (Score:2)
The basis for social construct is that the collective does the work of the individual to prevent abuse. If the collective (police) won't do the work, then by default it returns back to the individual. But you're right, however the "they" you speak of is "us".
Re:Yep, (Score:4, Interesting)
Re: (Score:2)
Re: (Score:2)
You can pwn their box...
There's a decent chance that the box that's actually trying to connect is already pwned by the person making the login attempt. Retribution against the (owner of the) box is likely to be retribution against a fellow victim. At least—I dunno about ftp—I use ssh with hosts.allow/deny to control access, which does a reverse DNS lookup so I get the host names of attackers in my logs, and a high percentage of them look like small mail servers and the like, so I'm pretty sure they're already pwned.
Re: (Score:2)
I'm pretty sure it doesn't. That would be like saying that turning the doorknob on somebody's home qualifies as breaking and entering.
Re: (Score:2)
Surely trying every doorknob on a terraced street qualifies as intent to tresspass and steal??