4 ms·

> records the interactions of hackers Before you get too excited, I would say that a common mistake of inexperienced sysadmins is assuming all those brute-forc

> records the interactions of hackers Before you get too excited, I would say that a common mistake of inexperienced sysadmins is assuming all those brute-force attempts in the logs are results of those "hackers" and "crackers", it's not, not even a scriptkid. All you can get by running a honeypot, like this one, is pretty boring activities by soulless, ancient worms and viruses, or automatic global Internet scanners running 24x7, not humans. Most of those are not even worth your time to block (e.g. if you only use strong password or pubkey, there are few reasons to fail2ban). It's nothing personal. Any machine will be port scanned, vuln probed, brute forced, blindly hit with ancient "1 shot" exploits (e.g. ?file=../../../etc/passwd ). This is how the Internet works. Another lesson is: never run any unsecured webserver/service on the public Internet, never ever, not even for debugging, period. Don't listen 0.0.0.0:80 if you have just installed your PHP management system, don't reset your forgotten MySQL password by disabling privilege checking before turning off networking first, if you just installed a new VPS with root password 123456 in a morning, don't wait until afternoon, change it immediately, etc. The reason is exact the opposite, not because of "hackers" but those stupid worms. Ordinary life is boring: if you run a webserver with password 123456 (e.g. for debugging an issue on a disposable server - just for 20 minutes, you think, then you forgot it), you won't (or unlikely) to see someone hacking into your system, but it's a certainty that one of those stupid worms/viruses would infect your machine within hours, sometimes it's as quick as having your lunch. And it probably won't do much damage, but you would spend your time to reinstall the system again...

mergy 7y ago
Indeed. After running this for a few weeks, most of the playbacks where a couple of seconds and consisted of a script that, once it obtained access, would just try and pull down payload sitting on a vulnerable host (in my case on the OVH Euro ISP) and then try to trigger a cron setup and exec in stealth mode on linux. Rarely did I ever get an interactive shell show someone trying to move through the process. When I did, it was fun to watch. I would say automated 1-2 sec script attacks outnumbered human logins 1000 to 1.
- segfaultbuserr 7y ago
  Thanks for sharing. On the other hand, I heard that running sandboxes to obtain the latest samples of IoT viruses and tracking their evolution is fun.
- tastroder 7y ago
  > I would say automated 1-2 sec script attacks outnumbered human logins 1000 to 1. After writing my own honeypot to get up to speed with some SSH details and satisfy curiosity I was kind of disappointed by that fact tbh. Though I expected the level of automation and boring stuff, I let a similar fake environment run for weeks in the hope of some human "coming back" for details but it honestly did not reveal more exciting information than you get from honeypots that make their data public. Nobody else ever got to see the forced little ncurses chat I've built in to talk to the human on the other side, shutting that down was not the happiest of moments. But yeah, fun to watch it was.
lrem 7y ago
Wasn't it just a couple minutes at the hight of Windows XP?
- segfaultbuserr 7y ago
  Indeed, /cough/ ransomware /cough/.
- swinglock 7y ago
  Seconds. Back when NAT routers weren't everywhere because you only had one computer and Windows XP didn't yet have a built-in firewall, unless you installed a third party firewall like ZoneAlarm before connecting a new installation to the Internet, it would be infected very quickly.
- yjftsjthsd-h 7y ago
  Oh yeah, the "infected before you can install patches" time
  - segfaultbuserr 7y ago
    Thanks for the memory. Your comment reminded me about the suggestion "You must disconnect your machine from the Internet before/during the installation of patches." from 2000s computer magazines.
- MivLives 7y ago
  Worked IT in the college I went to. One of the more permanent members told me that if you plugged a fresh XP install it'd be fucked in about 30 minutes. MS apparently came to campus to look at some of the stuff coming in. When I stopped working there, they were still assigning everything an ipv4 address, no firewall. Great for running game servers in dorms, not as great for getting your printer hacked.
tialaramex 7y ago
> if you only use strong password or pubkey Don't use passwords. Disable passwords. It's tempting to say "Oh we'll require 20 character long random strings, it'll be fine". If you've dotted every I and crossed every T that would work, but such passwords aren't memorable so they're no better than a private key - you'll need to store them somewhere and make sure to generate them properly, you might as well use keys. More often something will go wrong. Maybe it will be a local policy failure. "Oh I didn't realise devops needed those goofy passwords too, I thought that was just the backend team - we've been setting them all to pass1234, should I change them or is it too late now?". Maybe it will be in the password checking code, as it has happened way too often already on a broad spectrum of operating systems. Just use pubkey auth everywhere all the time.
- segfaultbuserr 7y ago
  When I setup a new server or a temporary account, my usual workflow would be simply generate a new random password locally from my password manager, before considering proper authentication. A few routers at my home with public Internet access are still password-only, and I don't see a big problem. But I have to agree with you, the suggestion "use strong password" itself is prone to failures, thus bad, and should be avoided.
veddox 7y ago
I remember setting up my first VPS a few years ago and finding automated login attempts in the logs within twenty minutes of it going live. Since then, I always install fail2ban as one of the first things I do on a new server. (Not that I don‘t use good passwords, but at dozens to hundreds of attacks a day, I don‘t want to run any risks!)
- roblabla 7y ago
  I once set up a raspberry pi, didn't finish the entire installation, figured I'd finish where I left off the next morning. Discovered after a few hours of sleep that some ancient port forwarding rule I had set up in my router exposed my rasppi's SSH port to the outside world. Hadn't changed the default root password yet - so obviously it got infested with a buuuunch of malware. So I took it upon me to unplug the damn thing and carefully analyze the content of the SD card. Turns out, it only got infested with x86 malware (as far as I can tell anyways) - None of which worked on rasppi, obviously. Various malwares attempted to connect, and once they succeeded, they uploaded their payload, and repeatedly tried (without success) to run it. Also hilarious: Various attacks tried to write to the same file location, resulting in neither of the payloads being successful. `mktemp` is your friend kids.
- earenndil 7y ago
  Don't use passwords. At all. Pubkeys only.
- segfaultbuserr 7y ago
  Upvoted, Why would someone downvote this comment?!
  - HocusLocus 7y ago
    Downvoted by malware worms. They target me too.
tracker1 7y ago
When Slammer hit, I had just setup a new SQL Server instance, and was going to head home and finish configuring from there... I didn't get out of the office for 5 minutes before they entire network was flooded with traffic from the worm and completely unusable. It doesn't help too much, but I generally move even my SSH port and tunnel everything not meant to be public through that, or over a full VPN. It's a shame that you have to do this now.
sansnomme 7y ago
You need to teach the Docker devs that. By default docker localhost is 0.0.0.0 so when you do docker run container_name -p 80:80 you are mapping to 0.0.0.0. I always explicitly write out the full port map i.e. -p 127.0.0.1:80:80. This is especially problematic if you are running e.g. postgres in Docker. The last thing you want is to have it exposed to the internet. One mitigation is to change the default localhost, you can do this by setting the IP variable in daemon.json to 127.0.0.1. /etc/docker/daemon.json (check your OS, for Mac use the GUI) { "ip" : "127.0.0.1" } Sane, secure-by-default configs are important. Don't let your users go shocked_pikachu.jpeg because of perceived notions of end-user freedom. (See for example how badly a certain famous lisp-based text editor effed up TLS)
- deleted 7y ago
  [deleted]
- segfaultbuserr 7y ago
  > Don't let your users go shocked_pikachu.jpeg because of perceived notions of end-user freedom. (See for example how badly a certain famous lisp-based text editor effed up TLS) On the other hand, don't lock your users up because of perceived notions of end-user privacy and security. (See for example how badly a certain famous browser named after a metal blocked adblockers) Not disagreeing with you at all, I'm all for strict TLS defaults, just ranting about the fact that so many restrictions meant for control and domination are marketed as "security", it hurts the public support of actual security. Many people I've read online cannot distinguish Google's push of secure TLS and Google's push of artificial control, one decided to run the website on plaintext HTTP diehardly. And many others still see ALL hardware security modules as evil DRM / mandatory code-signing scheme. How unfortunate it is, even more unfortunate is that their estimation has a better chance to be correct.
rodgerd 7y ago
> Another lesson is: never run any unsecured webserver/service on the public Internet, never ever, not even for debugging, period. Don't listen 0.0.0.0:80 [...]. This is why Ubuntu's "ease of setup" policy of listening on interfaces with things running on installation is such a poor choice. It may not be terrible on a workstation[1], but it's awful on servers. [1] Actually, it is.

mergy 7y ago

Indeed. After running this for a few weeks, most of the playbacks where a couple of seconds and consisted of a script that, once it obtained access, would just try and pull down payload sitting on a vulnerable host (in my case on the OVH Euro ISP) and then try to trigger a cron setup and exec in stealth mode on linux. Rarely did I ever get an interactive shell show someone trying to move through the process. When I did, it was fun to watch. I would say automated 1-2 sec script attacks outnumbered human logins 1000 to 1.

segfaultbuserr 7y ago
Thanks for sharing. On the other hand, I heard that running sandboxes to obtain the latest samples of IoT viruses and tracking their evolution is fun.
tastroder 7y ago
> I would say automated 1-2 sec script attacks outnumbered human logins 1000 to 1. After writing my own honeypot to get up to speed with some SSH details and satisfy curiosity I was kind of disappointed by that fact tbh. Though I expected the level of automation and boring stuff, I let a similar fake environment run for weeks in the hope of some human "coming back" for details but it honestly did not reveal more exciting information than you get from honeypots that make their data public. Nobody else ever got to see the forced little ncurses chat I've built in to talk to the human on the other side, shutting that down was not the happiest of moments. But yeah, fun to watch it was.

lrem 7y ago

Wasn't it just a couple minutes at the hight of Windows XP?

segfaultbuserr 7y ago
Indeed, /cough/ ransomware /cough/.
swinglock 7y ago
Seconds. Back when NAT routers weren't everywhere because you only had one computer and Windows XP didn't yet have a built-in firewall, unless you installed a third party firewall like ZoneAlarm before connecting a new installation to the Internet, it would be infected very quickly.
yjftsjthsd-h 7y ago
Oh yeah, the "infected before you can install patches" time
- segfaultbuserr 7y ago
  Thanks for the memory. Your comment reminded me about the suggestion "You must disconnect your machine from the Internet before/during the installation of patches." from 2000s computer magazines.
MivLives 7y ago
Worked IT in the college I went to. One of the more permanent members told me that if you plugged a fresh XP install it'd be fucked in about 30 minutes. MS apparently came to campus to look at some of the stuff coming in. When I stopped working there, they were still assigning everything an ipv4 address, no firewall. Great for running game servers in dorms, not as great for getting your printer hacked.

tialaramex 7y ago

> if you only use strong password or pubkey Don't use passwords. Disable passwords. It's tempting to say "Oh we'll require 20 character long random strings, it'll be fine". If you've dotted every I and crossed every T that would work, but such passwords aren't memorable so they're no better than a private key - you'll need to store them somewhere and make sure to generate them properly, you might as well use keys. More often something will go wrong. Maybe it will be a local policy failure. "Oh I didn't realise devops needed those goofy passwords too, I thought that was just the backend team - we've been setting them all to pass1234, should I change them or is it too late now?". Maybe it will be in the password checking code, as it has happened way too often already on a broad spectrum of operating systems. Just use pubkey auth everywhere all the time.

segfaultbuserr 7y ago
When I setup a new server or a temporary account, my usual workflow would be simply generate a new random password locally from my password manager, before considering proper authentication. A few routers at my home with public Internet access are still password-only, and I don't see a big problem. But I have to agree with you, the suggestion "use strong password" itself is prone to failures, thus bad, and should be avoided.

veddox 7y ago

I remember setting up my first VPS a few years ago and finding automated login attempts in the logs within twenty minutes of it going live. Since then, I always install fail2ban as one of the first things I do on a new server. (Not that I don‘t use good passwords, but at dozens to hundreds of attacks a day, I don‘t want to run any risks!)

roblabla 7y ago
I once set up a raspberry pi, didn't finish the entire installation, figured I'd finish where I left off the next morning. Discovered after a few hours of sleep that some ancient port forwarding rule I had set up in my router exposed my rasppi's SSH port to the outside world. Hadn't changed the default root password yet - so obviously it got infested with a buuuunch of malware. So I took it upon me to unplug the damn thing and carefully analyze the content of the SD card. Turns out, it only got infested with x86 malware (as far as I can tell anyways) - None of which worked on rasppi, obviously. Various malwares attempted to connect, and once they succeeded, they uploaded their payload, and repeatedly tried (without success) to run it. Also hilarious: Various attacks tried to write to the same file location, resulting in neither of the payloads being successful. `mktemp` is your friend kids.
earenndil 7y ago
Don't use passwords. At all. Pubkeys only.
segfaultbuserr 7y ago
Upvoted, Why would someone downvote this comment?!
- HocusLocus 7y ago
  Downvoted by malware worms. They target me too.

tracker1 7y ago

When Slammer hit, I had just setup a new SQL Server instance, and was going to head home and finish configuring from there... I didn't get out of the office for 5 minutes before they entire network was flooded with traffic from the worm and completely unusable. It doesn't help too much, but I generally move even my SSH port and tunnel everything not meant to be public through that, or over a full VPN. It's a shame that you have to do this now.

sansnomme 7y ago

You need to teach the Docker devs that. By default docker localhost is 0.0.0.0 so when you do docker run container_name -p 80:80 you are mapping to 0.0.0.0. I always explicitly write out the full port map i.e. -p 127.0.0.1:80:80. This is especially problematic if you are running e.g. postgres in Docker. The last thing you want is to have it exposed to the internet. One mitigation is to change the default localhost, you can do this by setting the IP variable in daemon.json to 127.0.0.1. /etc/docker/daemon.json (check your OS, for Mac use the GUI) { "ip" : "127.0.0.1" } Sane, secure-by-default configs are important. Don't let your users go shocked_pikachu.jpeg because of perceived notions of end-user freedom. (See for example how badly a certain famous lisp-based text editor effed up TLS)

deleted 7y ago
[deleted]
segfaultbuserr 7y ago
> Don't let your users go shocked_pikachu.jpeg because of perceived notions of end-user freedom. (See for example how badly a certain famous lisp-based text editor effed up TLS) On the other hand, don't lock your users up because of perceived notions of end-user privacy and security. (See for example how badly a certain famous browser named after a metal blocked adblockers) Not disagreeing with you at all, I'm all for strict TLS defaults, just ranting about the fact that so many restrictions meant for control and domination are marketed as "security", it hurts the public support of actual security. Many people I've read online cannot distinguish Google's push of secure TLS and Google's push of artificial control, one decided to run the website on plaintext HTTP diehardly. And many others still see ALL hardware security modules as evil DRM / mandatory code-signing scheme. How unfortunate it is, even more unfortunate is that their estimation has a better chance to be correct.

rodgerd 7y ago

> Another lesson is: never run any unsecured webserver/service on the public Internet, never ever, not even for debugging, period. Don't listen 0.0.0.0:80 [...]. This is why Ubuntu's "ease of setup" policy of listening on interfaces with things running on installation is such a poor choice. It may not be terrible on a workstation[1], but it's awful on servers. [1] Actually, it is.