8 ms·

If one were to run a honeypot like this and take every IP which connects and attempts a login and immediately ban it from your network, then if more than 1% of

If one were to run a honeypot like this and take every IP which connects and attempts a login and immediately ban it from your network, then if more than 1% of the IP range they are in has been banned, ban the entire range... what would the expected outcome be for a typical residential user?

ryanlol 9y ago
>what would the expected outcome be for a typical residential user? Wasted time for precisely zero benefit. There are lots of hobbyists that'll tell you otherwise, but in reality you should be using key auth and worrying about better things.
merb 9y ago
in my first years I've setup a ssh server behind a nat'd network and installed fail2ban. the outcome was that nobody could access the ssh server... probably the same thing would happen, on ssh I've seen so many login attemts even on the smallest VPS I've ever gotten, it's just ridicoulus and important to use non password authentication with ssh (i.e. rsa keys probably 4096b).
- logicallee 9y ago
  EDIT: I'm withdrawing the question per the accepted answer below. - original comment: >it's just ridiculous and important to use non password authentication with ssh Does this follow from the assumption (that you did not state) "since I won't bother to create a high-entropy password"? Granted its a fairly safe assumption if you're not trying too hard but SSH supports passwords of arbitrary length so I'm curious if there's any other reason, besides not taking the time to create a high-entropy password. ----- Accepted answer below (esp "Because your users cannot be trusted. I run servers which coworkers, all developers, get access to.")
  - tokenizerrr 9y ago
    Because your users cannot be trusted. I run servers which coworkers, all developers, get access to. It's either ssh keys or 2 factor authentication because most don't give a fuck about security and will insist using garbage passwords if not prevented from doing so (and then they will complain), even though the use of a password manager is mandatory.
    - logicallee 9y ago
      Perfect answer actually. Accepted and I've updated my original comment.
    - jlgaddis 9y ago
      > ... will insist using garbage passwords if not prevented from doing so ... /etc/security/pwquality.conf is how I prevent co-workers from doing so (on RHEL and derivatives).
      - tokenizerrr 9y ago
        Good to know. We do our user provisioning through an internal portal which enforces everything. The ssh servers als gets configured to disable password login so the only thing passwords are used for is sudo. All web stuff is behind a SSO gateway with password+2fa.
  - Cozumel 9y ago
    Using passwords for ssh is just a bad idea, high entropy or not. Keys are the only way to go. The amount of login attempts you get otherwise is just off the scale, on one server there were over 20,000+ failed attempts from my last login in the space of just 10 minutes, all it takes is one lucky guess.
  - spiritguy 9y ago
    One thing i was surprised to learn was that whatever you type as your password is actually transmitted to the server for validation! So if you typed the password for the wrong server in.. then you've just leaked that other password to the server you were trying to connect to! uh oh! if you use keys, this doesn't happen.
  - eru 9y ago
    Private keys never leave the place they are born. Passwords not so much.
- callesgg 9y ago
  Just alter the ssh port, i have never received a ssh connection that i can not personally account for.
  - secfirstmd 9y ago
    Yep, big advocate of that.
  - pilsetnieks 9y ago
    Security through obscurity is not the solution, though. Sooner or later someone does a port scan and finds that port. I've found that it's more efficient just to whitelist the IPs or subnets you might need and denying the rest. Edit: I didn't mean changing the port is a bad thing. You can and should do it, and it will help a bit - just that it shouldn't be the only thing to rely on for your SSH security.
    - avtar 9y ago
      > Security through obscurity is not the solution, though. It's not the only solution but something that can be used to at least drastically reduce the amount of noise in logs. > I've found that it's more efficient just to whitelist the IPs or subnets you might need and denying the rest. That does sound more efficient but what if someone connecting doesn't have a static IP?
      - pilsetnieks 9y ago
        > what if someone connecting doesn't have a static IP? Whitelist your ISPs subnet then, at the very least - there's much lower probability of an attacker coming from just your ISPs, and, of course, use other measures too - I didn't mean that to be the only solution for the problem.
      - scaryclam 9y ago
        We use a VPN for this reason. It works pretty well and means we can lock things down to a single IP while allowing staff to still get on from home.
- Karunamon 9y ago
  Only exception I can think of is SSHing into things where you’re not allowed to plug stuff in or put files on, like a public terminal of some kind. Password plus a second factor would be more usable there.
- noir_lord 9y ago
  Literally the first thing I do on any new machine is disable password logins, disable root logins and then punt the SSH port to the top of the range (usually 47999). Every remote machine gets it's own keypair as well and links between machines also get their own key-pairs (key handling is PITA, I've yet to find a method I really like), Keys for work stuff are back up on multiple LUKS memory sticks (two in separate safes, two offsite). I'm fortunate in that work machines are in the pet category not cattle category so we don't need to change keys that frequently (though I will rotate them out yearly anyway).
  - jaytaylor 9y ago
    Friendly advice.. It might be better not to disclose this level of detail about your professional security practices, especially when there is a trail of breadcrumbs in the HN profile on your account..
    - noir_lord 9y ago
      Shrug, given how hostile the internet is I fail to see how this increases the risk at all.
      - rimliu 9y ago
        Yeah, I am not so sure how knowing that keys are rotated helps the wannabe attacker. The only "useful" bit would be to look for SSH port up in the range, not much help though.
        noir_lord 9y ago
        My attitude is short of you having the SSH keys if I can't tell my entire setup and still be secure then I'm relying on obscurity not security.
    - z29LiTp5qUC30n 9y ago
      If you do it right it doesn't matter. The default ip(6)tables rule: drop all packets For example to access my least secured public facing server you need to do the following: 17 port port-knocking to enable crypto port knocking Which enables ssh Which requires a 16K RSA key and TOTP The only accounts that can be logged in have 18 character randomly generated usernames and 255 character passwords. The login accounts have no access to administrative functions. So you'll need to su to an administrative account and guess the 255 character password or have a zero day exploit that can bypass SELinux and cryptographically signed white-listing of binaries.
- z3t4 9y ago
  Don't forget about ipv6 if you have that enabled.
bcoates 9y ago
You'd be unreachable from cloud providers, major public hotspots, residential ISPs, and countries that use carrier grade NAT to stick all their traffic on one IP or one range.
- otakucode 9y ago
  Hmm, I hadn't thought about cloud providers. Public hotspots, residential ISPs, and countries behind firewalls aren't really something I expect most home users really need their home network to be accessed by. But blocking connections from cloud providers would be unworkable. I suppose lots of automated SSH attacks would be coming from cloud providers... maybe there are few enough they could be whitelisted?
  - artursapek 9y ago
    With cloud providers it's likely a "bad" IP will eventually get re-assigned to a "good" customer whom you don't want to block. That's why an exponentially increasing ban is generally a good idea, I think. The more abuse you get from a given IP address the longer you ban it each time. If it's use for a one-time attack and thrown away, you forgive it relatively quickly.
  - user5994461 9y ago
    From experience, there are two kind of cloud providers. The normal ones like AWS, OVH and Digital Ocean. And the shady ones. The first one don't attack much of anything, there is the occasional spider that tries to index your website (we had data worth scraping). The later can be banned by entire AS without issues.
justinsaccount 9y ago
I do this sort of thing, but I'm listening on a few /16s. 1% is a pretty low threshold. There are some v4 networks out there that are complete garbage.. If I was going to do something like that I'd start at closer to 90%.. 230 hosts on a /24. $ select subnet, count(distinct(cidr)) as unique_sources from (select set_masklen(cidr,16) as subnet, cidr from stuff where why like 'SSH%' and added > '2017-08-01') as foo group by subnet order by unique_sources desc limit 20; subnet | unique_sources ----------------+---------------- 181.211.0.0/16 | 11688 190.214.0.0/16 | 8486 31.162.0.0/16 | 8454 181.196.0.0/16 | 7994 181.113.0.0/16 | 7892 188.16.0.0/16 | 7294 94.51.0.0/16 | 6384 188.19.0.0/16 | 6077 31.163.0.0/16 | 5905 178.47.0.0/16 | 5788 201.178.0.0/16 | 5620 190.48.0.0/16 | 5179 188.17.0.0/16 | 4893 201.179.0.0/16 | 4812 188.18.0.0/16 | 4266 186.178.0.0/16 | 4208 5.141.0.0/16 | 4203 186.129.0.0/16 | 3858 181.112.0.0/16 | 3836 190.174.0.0/16 | 3836 I think some of those networks are using CGN and have a much smaller number of actually compromised hosts.. ISPs generally just don't give a shit about security.
- bcoates 9y ago
  You may as well just block LACNIC IPs wholesale and save the trouble at this point
- otakucode 9y ago
  I don't see why a residential user should be worried about residential users from other ISPs being able to reach their machine usually. I suppose it would be problematic for torrenting and maybe gaming (depending on architecture of the game). But I imagine my grandmother couldn't care less if some other grandmother couldn't connect to her network directly. 90% seems really high... you'd really wait until 230 of 255 possible hosts have attempted a breakin before deciding they were on a network too dangerous to preserve your accessibility from? Are there a lot of networks where 90% of the boxes are launching attacks, but 10% have legitimate need to connect to your personal home machine?
  - 9y ago
thaumaturgy 9y ago
I've been doing something similar to this for years on a mail server that hosts all of my mail as well as a number of customers. Contrary to the other replies, it's worked out really well, and you can rely on customers to complain pretty quickly if anything's not working right. The bulk of the abuse comes from Russian and Chinese networks, with Brazil working hard to catch up. Those can be pretty well perma-banned without consequence. Under "folks that should be fined into oblivion", there's cogentco.com, quadranet.com, colocrossing.com, level3.com, vpls.com, softlayer.com, hostingsolutionsinternational.com, datashack.net, singlehop.com, actonsoftware.com, and a whole raft of others. The secret sauce is a carefully tuned ban decay function that scales up with the number of abuses. Occasional hits get a network banned for an hour or less, subsequent hits get them banned a little longer, and then there's a fine line where the function goes exponential, all the way up to 6-month-plus ban periods for really big nuisances. Otherwise it's just fail2ban on some logs and some home-brew code that does whois lookups on nuisance IPs and some data mining on the whois response.
- noir_lord 9y ago
  I can't ban China as our suppliers at work are partly -Chinese, it's a royal PITA, I can't even whitelist them as they have to bound around VPN's just to get around the Great Firewall of China on their end.
  - yorwba 9y ago
    If your suppliers use VPNs anyway, you can absolutely ban Chinese IPs without much consequence for them. However, if it's for a user-facing site, please don't just ban all of China. After relocating, I was quite annoyed by the number of websites that are unavailable not because they are blocked by the Great Firewall, but because they banned all of China and VPNs to stop the abuse they saw from some IPs in those ranges.
    - noir_lord 9y ago
      If they consistently used VPN's I would but it seems to be intermittent since the GFWoC is a fickle thing.
acranox 9y ago
I did this with fail2ban. Initially just blocking the IP, and then sweeping back through occasionally and blocking the whole subnet when I had a few offenders in the subnet. There was no negative impact for me.
- emveeoh 9y ago
  +1 fail2ban (properly configured, of course)
samstave 9y ago
DOS against a range provided by an ISP assuming you could spoof the source over and over, you could have valid ranges auto-blocked for valid services where you DOS a range of IPs from any given ISP
bitbang 9y ago
Fwknop is a much better solution than whack-a-mole blacklisting or even Fail2Ban. https://github.com/mrash/fwknop https://github.com/mrash/fwknop

ryanlol 9y ago

>what would the expected outcome be for a typical residential user? Wasted time for precisely zero benefit. There are lots of hobbyists that'll tell you otherwise, but in reality you should be using key auth and worrying about better things.

merb 9y ago

in my first years I've setup a ssh server behind a nat'd network and installed fail2ban. the outcome was that nobody could access the ssh server... probably the same thing would happen, on ssh I've seen so many login attemts even on the smallest VPS I've ever gotten, it's just ridicoulus and important to use non password authentication with ssh (i.e. rsa keys probably 4096b).

logicallee 9y ago
EDIT: I'm withdrawing the question per the accepted answer below. - original comment: >it's just ridiculous and important to use non password authentication with ssh Does this follow from the assumption (that you did not state) "since I won't bother to create a high-entropy password"? Granted its a fairly safe assumption if you're not trying too hard but SSH supports passwords of arbitrary length so I'm curious if there's any other reason, besides not taking the time to create a high-entropy password. ----- Accepted answer below (esp "Because your users cannot be trusted. I run servers which coworkers, all developers, get access to.")
- tokenizerrr 9y ago
  Because your users cannot be trusted. I run servers which coworkers, all developers, get access to. It's either ssh keys or 2 factor authentication because most don't give a fuck about security and will insist using garbage passwords if not prevented from doing so (and then they will complain), even though the use of a password manager is mandatory.
  - logicallee 9y ago
    Perfect answer actually. Accepted and I've updated my original comment.
  - jlgaddis 9y ago
    > ... will insist using garbage passwords if not prevented from doing so ... /etc/security/pwquality.conf is how I prevent co-workers from doing so (on RHEL and derivatives).
    - tokenizerrr 9y ago
      Good to know. We do our user provisioning through an internal portal which enforces everything. The ssh servers als gets configured to disable password login so the only thing passwords are used for is sudo. All web stuff is behind a SSO gateway with password+2fa.
- Cozumel 9y ago
  Using passwords for ssh is just a bad idea, high entropy or not. Keys are the only way to go. The amount of login attempts you get otherwise is just off the scale, on one server there were over 20,000+ failed attempts from my last login in the space of just 10 minutes, all it takes is one lucky guess.
- spiritguy 9y ago
  One thing i was surprised to learn was that whatever you type as your password is actually transmitted to the server for validation! So if you typed the password for the wrong server in.. then you've just leaked that other password to the server you were trying to connect to! uh oh! if you use keys, this doesn't happen.
- eru 9y ago
  Private keys never leave the place they are born. Passwords not so much.
callesgg 9y ago
Just alter the ssh port, i have never received a ssh connection that i can not personally account for.
- secfirstmd 9y ago
  Yep, big advocate of that.
- pilsetnieks 9y ago
  Security through obscurity is not the solution, though. Sooner or later someone does a port scan and finds that port. I've found that it's more efficient just to whitelist the IPs or subnets you might need and denying the rest. Edit: I didn't mean changing the port is a bad thing. You can and should do it, and it will help a bit - just that it shouldn't be the only thing to rely on for your SSH security.
  - avtar 9y ago
    > Security through obscurity is not the solution, though. It's not the only solution but something that can be used to at least drastically reduce the amount of noise in logs. > I've found that it's more efficient just to whitelist the IPs or subnets you might need and denying the rest. That does sound more efficient but what if someone connecting doesn't have a static IP?
    - pilsetnieks 9y ago
      > what if someone connecting doesn't have a static IP? Whitelist your ISPs subnet then, at the very least - there's much lower probability of an attacker coming from just your ISPs, and, of course, use other measures too - I didn't mean that to be the only solution for the problem.
    - scaryclam 9y ago
      We use a VPN for this reason. It works pretty well and means we can lock things down to a single IP while allowing staff to still get on from home.
Karunamon 9y ago
Only exception I can think of is SSHing into things where you’re not allowed to plug stuff in or put files on, like a public terminal of some kind. Password plus a second factor would be more usable there.
noir_lord 9y ago
Literally the first thing I do on any new machine is disable password logins, disable root logins and then punt the SSH port to the top of the range (usually 47999). Every remote machine gets it's own keypair as well and links between machines also get their own key-pairs (key handling is PITA, I've yet to find a method I really like), Keys for work stuff are back up on multiple LUKS memory sticks (two in separate safes, two offsite). I'm fortunate in that work machines are in the pet category not cattle category so we don't need to change keys that frequently (though I will rotate them out yearly anyway).
- jaytaylor 9y ago
  Friendly advice.. It might be better not to disclose this level of detail about your professional security practices, especially when there is a trail of breadcrumbs in the HN profile on your account..
  - noir_lord 9y ago
    Shrug, given how hostile the internet is I fail to see how this increases the risk at all.
    - rimliu 9y ago
      Yeah, I am not so sure how knowing that keys are rotated helps the wannabe attacker. The only "useful" bit would be to look for SSH port up in the range, not much help though.
      - noir_lord 9y ago
        My attitude is short of you having the SSH keys if I can't tell my entire setup and still be secure then I'm relying on obscurity not security.
  - z29LiTp5qUC30n 9y ago
    If you do it right it doesn't matter. The default ip(6)tables rule: drop all packets For example to access my least secured public facing server you need to do the following: 17 port port-knocking to enable crypto port knocking Which enables ssh Which requires a 16K RSA key and TOTP The only accounts that can be logged in have 18 character randomly generated usernames and 255 character passwords. The login accounts have no access to administrative functions. So you'll need to su to an administrative account and guess the 255 character password or have a zero day exploit that can bypass SELinux and cryptographically signed white-listing of binaries.
z3t4 9y ago
Don't forget about ipv6 if you have that enabled.

bcoates 9y ago

You'd be unreachable from cloud providers, major public hotspots, residential ISPs, and countries that use carrier grade NAT to stick all their traffic on one IP or one range.

otakucode 9y ago
Hmm, I hadn't thought about cloud providers. Public hotspots, residential ISPs, and countries behind firewalls aren't really something I expect most home users really need their home network to be accessed by. But blocking connections from cloud providers would be unworkable. I suppose lots of automated SSH attacks would be coming from cloud providers... maybe there are few enough they could be whitelisted?
- artursapek 9y ago
  With cloud providers it's likely a "bad" IP will eventually get re-assigned to a "good" customer whom you don't want to block. That's why an exponentially increasing ban is generally a good idea, I think. The more abuse you get from a given IP address the longer you ban it each time. If it's use for a one-time attack and thrown away, you forgive it relatively quickly.
- user5994461 9y ago
  From experience, there are two kind of cloud providers. The normal ones like AWS, OVH and Digital Ocean. And the shady ones. The first one don't attack much of anything, there is the occasional spider that tries to index your website (we had data worth scraping). The later can be banned by entire AS without issues.

justinsaccount 9y ago

I do this sort of thing, but I'm listening on a few /16s. 1% is a pretty low threshold. There are some v4 networks out there that are complete garbage.. If I was going to do something like that I'd start at closer to 90%.. 230 hosts on a /24. $ select subnet, count(distinct(cidr)) as unique_sources from (select set_masklen(cidr,16) as subnet, cidr from stuff where why like 'SSH%' and added > '2017-08-01') as foo group by subnet order by unique_sources desc limit 20; subnet | unique_sources ----------------+---------------- 181.211.0.0/16 | 11688 190.214.0.0/16 | 8486 31.162.0.0/16 | 8454 181.196.0.0/16 | 7994 181.113.0.0/16 | 7892 188.16.0.0/16 | 7294 94.51.0.0/16 | 6384 188.19.0.0/16 | 6077 31.163.0.0/16 | 5905 178.47.0.0/16 | 5788 201.178.0.0/16 | 5620 190.48.0.0/16 | 5179 188.17.0.0/16 | 4893 201.179.0.0/16 | 4812 188.18.0.0/16 | 4266 186.178.0.0/16 | 4208 5.141.0.0/16 | 4203 186.129.0.0/16 | 3858 181.112.0.0/16 | 3836 190.174.0.0/16 | 3836 I think some of those networks are using CGN and have a much smaller number of actually compromised hosts.. ISPs generally just don't give a shit about security.

bcoates 9y ago
You may as well just block LACNIC IPs wholesale and save the trouble at this point
otakucode 9y ago
I don't see why a residential user should be worried about residential users from other ISPs being able to reach their machine usually. I suppose it would be problematic for torrenting and maybe gaming (depending on architecture of the game). But I imagine my grandmother couldn't care less if some other grandmother couldn't connect to her network directly. 90% seems really high... you'd really wait until 230 of 255 possible hosts have attempted a breakin before deciding they were on a network too dangerous to preserve your accessibility from? Are there a lot of networks where 90% of the boxes are launching attacks, but 10% have legitimate need to connect to your personal home machine?
- 9y ago

thaumaturgy 9y ago

I've been doing something similar to this for years on a mail server that hosts all of my mail as well as a number of customers. Contrary to the other replies, it's worked out really well, and you can rely on customers to complain pretty quickly if anything's not working right. The bulk of the abuse comes from Russian and Chinese networks, with Brazil working hard to catch up. Those can be pretty well perma-banned without consequence. Under "folks that should be fined into oblivion", there's cogentco.com, quadranet.com, colocrossing.com, level3.com, vpls.com, softlayer.com, hostingsolutionsinternational.com, datashack.net, singlehop.com, actonsoftware.com, and a whole raft of others. The secret sauce is a carefully tuned ban decay function that scales up with the number of abuses. Occasional hits get a network banned for an hour or less, subsequent hits get them banned a little longer, and then there's a fine line where the function goes exponential, all the way up to 6-month-plus ban periods for really big nuisances. Otherwise it's just fail2ban on some logs and some home-brew code that does whois lookups on nuisance IPs and some data mining on the whois response.

noir_lord 9y ago
I can't ban China as our suppliers at work are partly -Chinese, it's a royal PITA, I can't even whitelist them as they have to bound around VPN's just to get around the Great Firewall of China on their end.
- yorwba 9y ago
  If your suppliers use VPNs anyway, you can absolutely ban Chinese IPs without much consequence for them. However, if it's for a user-facing site, please don't just ban all of China. After relocating, I was quite annoyed by the number of websites that are unavailable not because they are blocked by the Great Firewall, but because they banned all of China and VPNs to stop the abuse they saw from some IPs in those ranges.
  - noir_lord 9y ago
    If they consistently used VPN's I would but it seems to be intermittent since the GFWoC is a fickle thing.

acranox 9y ago

I did this with fail2ban. Initially just blocking the IP, and then sweeping back through occasionally and blocking the whole subnet when I had a few offenders in the subnet. There was no negative impact for me.

emveeoh 9y ago
+1 fail2ban (properly configured, of course)

samstave 9y ago

DOS against a range provided by an ISP assuming you could spoof the source over and over, you could have valid ranges auto-blocked for valid services where you DOS a range of IPs from any given ISP

bitbang 9y ago

Fwknop is a much better solution than whack-a-mole blacklisting or even Fail2Ban. https://github.com/mrash/fwknop https://github.com/mrash/fwknop