What SSH Hacking Attempts Look Like(medium.com)
medium.com
What SSH Hacking Attempts Look Like
https://medium.com/@dmrickert/what-ssh-hacking-attempts-look-like-8f698e70a4f5
183 comments
One thing I've found amusing is you can cut down SSH hacking attempts to almost zero (at the cost of compatibility with legacy systems) by using very progressive encryption. If you force use of ChaCha20/Poly1305, ED25519 and so forth in sshd_config, you'll see these attempts almost disappear. There's probably an observation to be made about just how overwhelmingly many of these attempts come from fairly old software setups.
Good info! Got any good resources on configuring sshd algos?
I highly recommend Mozilla's OpenSSH configuration guideline[1].
[1] https://infosec.mozilla.org/guidelines/openssh#Modern
[1] https://infosec.mozilla.org/guidelines/openssh#Modern
Nirv's recommendation below is spot on, but here's a ready-made version as well: https://github.com/ejrv/linuxconfigs/blob/master/etc/ssh/ssh...
It's basically a clone of Mozilla's, except enforcing only the very strictest encryption. You can just lift the first 16 lines out of that and merge them into your sshd_config if you don't want to change your existing sshd_config too much.
It's basically a clone of Mozilla's, except enforcing only the very strictest encryption. You can just lift the first 16 lines out of that and merge them into your sshd_config if you don't want to change your existing sshd_config too much.
Or the ratio of script kiddies to developers.
You mean the ssh handshake will fail... It won't stop an attempt. They just won't get to a password prompt. Right?
I did that and it bit back when it prevented Transmit from connecting to my servers, with only a generic "Unable to connect" message popping up. This was fixed fairly recently[0], but it's a reminder that using a restricted set of ciphers may not only prevent illegitimate connections from going through.
I can confirm from the same experience, however, that it prevents most hacking attempts from ever going to the authentication stage.
[0] https://library.panic.com/releasenotes/transmit5/#5-1
I can confirm from the same experience, however, that it prevents most hacking attempts from ever going to the authentication stage.
[0] https://library.panic.com/releasenotes/transmit5/#5-1
Some notes from an InfoSec person.
- Have a stand alone SSH server that is something like a R-Pi[type B] running an OS that gets patches regularly via unattended-upgrades and reboots itself at least once a week.[could also be a minimal VM like AlpineOS if you need Gbps+ line speed]
- Have this R-Pi and your network gear plugged into a UPS that can withstand at least a couple of hours of power outage.
- Use non-standard ports on your perimeter FW for forwarding to the R-Pi.
- Run fail2ban or something similar. Set a bantime of at least an hour[3600 sec] after no more than 5 attempts in 600 sec. This is mostly to discourage anyone who stumbles across your perimeter listening port.[which enough will] Password login will be disabled anyway, but a bot might not check for allowed auth types.[nmap -Pn -p 22 --script ssh-auth-methods <target>]
- No passwords allowed in /etc/ssh/sshd_config[PasswordAuthentication no]. Use public key based authentication.[PubkeyAuthentication yes] Put the public SSH key[id_rsa.pub] of any machine that you wish to authorize into ~/.ssh/authorized_keys on your R-Pi. This way you can authorize and de-authorize remote machines[with particular users] at will.
- add 'AllowUsers xxxx yyyy' to your /etc/ssh/sshd_config
- No root logins allowed![PermitRootLogin no]
- Maybe limit via perimeter or on the R-Pi which source IP ranges are allowed to access to SSH.[whitelisting]
- Periodically review your logs of perimeter FW, R-Pi FW and /var/log/auth.log to see what's going on. It should be pretty quiet, but look at them anyway once a week.
- Sleep well knowing that you have a simple, layered and robust defense strategy that also has power-event survivability.
Others have mentioned port-knocking which is a cool trick but not something that I typically use in an actual daily defense strategy because I'm not sure how much value it really adds.
Don't use your perimeter device to host SSH services. It will not get patches fast enough when vulns come up.
- Have a stand alone SSH server that is something like a R-Pi[type B] running an OS that gets patches regularly via unattended-upgrades and reboots itself at least once a week.[could also be a minimal VM like AlpineOS if you need Gbps+ line speed]
- Have this R-Pi and your network gear plugged into a UPS that can withstand at least a couple of hours of power outage.
- Use non-standard ports on your perimeter FW for forwarding to the R-Pi.
- Run fail2ban or something similar. Set a bantime of at least an hour[3600 sec] after no more than 5 attempts in 600 sec. This is mostly to discourage anyone who stumbles across your perimeter listening port.[which enough will] Password login will be disabled anyway, but a bot might not check for allowed auth types.[nmap -Pn -p 22 --script ssh-auth-methods <target>]
- No passwords allowed in /etc/ssh/sshd_config[PasswordAuthentication no]. Use public key based authentication.[PubkeyAuthentication yes] Put the public SSH key[id_rsa.pub] of any machine that you wish to authorize into ~/.ssh/authorized_keys on your R-Pi. This way you can authorize and de-authorize remote machines[with particular users] at will.
- add 'AllowUsers xxxx yyyy' to your /etc/ssh/sshd_config
- No root logins allowed![PermitRootLogin no]
- Maybe limit via perimeter or on the R-Pi which source IP ranges are allowed to access to SSH.[whitelisting]
- Periodically review your logs of perimeter FW, R-Pi FW and /var/log/auth.log to see what's going on. It should be pretty quiet, but look at them anyway once a week.
- Sleep well knowing that you have a simple, layered and robust defense strategy that also has power-event survivability.
Others have mentioned port-knocking which is a cool trick but not something that I typically use in an actual daily defense strategy because I'm not sure how much value it really adds.
Don't use your perimeter device to host SSH services. It will not get patches fast enough when vulns come up.
"Others have mentioned port-knocking which is a cool trick but not something that I typically use in an actual daily defense strategy because I'm not sure how much value it really adds."
I don't know how much it adds, but it is non-zero.
The knockd daemon is rock solid[1] and your ssh port traffic goes down to zero (other than your own use).
Port knocking has no place in security by itself but I think it's a wonderful addition to a layered defense - my favorite one, in fact.
I don't know how much it adds, but it is non-zero.
The knockd daemon is rock solid[1] and your ssh port traffic goes down to zero (other than your own use).
Port knocking has no place in security by itself but I think it's a wonderful addition to a layered defense - my favorite one, in fact.
Try using fwknop. Similar concept to Port knocking, but much more secure.
I just use the firewall.. if you make more than 4 SSH connections inside of a minute you're blackholed for 5 minutes. Pretty much drops all automated scanners right on the floor while not adding any steps for normal use.
> Use non-standard ports
While I completely agree and encourage people to use all of your suggestions, this single step - not being on port 22 - has easily provided the most benefit. When sshd listened on port 22, I regularly saw attacks that would run through thousands of common passwords at high speed[1]. After moving to a random port, it was over a year before I saw another hostile login attempt.
It may be easy to discover the server with a simple port scan, but in practice the attacks seem to focus on the easy targets.
> fail2ban
Fail2ban is great and highly configurable. I could accept having to manually reset occasional false positives, so my fail2ban will immediately (no retries) ban on the first use of anything that is known to be malicious such as any attempt to login as root with a password, asking to login with an account name like [admin, mysql, squid], or any apache access log matching /\/phpMyAdmin/, etc.
[1] Several logins per second over ADSL could use a large fraction of the upload bandwidth.
While I completely agree and encourage people to use all of your suggestions, this single step - not being on port 22 - has easily provided the most benefit. When sshd listened on port 22, I regularly saw attacks that would run through thousands of common passwords at high speed[1]. After moving to a random port, it was over a year before I saw another hostile login attempt.
It may be easy to discover the server with a simple port scan, but in practice the attacks seem to focus on the easy targets.
> fail2ban
Fail2ban is great and highly configurable. I could accept having to manually reset occasional false positives, so my fail2ban will immediately (no retries) ban on the first use of anything that is known to be malicious such as any attempt to login as root with a password, asking to login with an account name like [admin, mysql, squid], or any apache access log matching /\/phpMyAdmin/, etc.
[1] Several logins per second over ADSL could use a large fraction of the upload bandwidth.
# cat /etc/ssh/sshd_config | grep PasswordAuthentication
PasswordAuthentication no
^ it should return that. The end.
PasswordAuthentication no
^ it should return that. The end.
Is it worth mentioning useless uses of cat in this day and age?
I'm pretty fanatical about efficiency, but it's kind of annoying to have to remember where in the argument sequence for a whole bunch of commands the input file goes.
Of course once you use the 'cat' trick you then have to remember which comments require '-', '-f -' or something to that effect because whoever programmed them didn't think the primary use case was to work as a filter.
Pipes are one of Unix's most useful features and cat somefile | asequenceofusefulcommands is a shorthand that anybody should be able to use.
Of course once you use the 'cat' trick you then have to remember which comments require '-', '-f -' or something to that effect because whoever programmed them didn't think the primary use case was to work as a filter.
Pipes are one of Unix's most useful features and cat somefile | asequenceofusefulcommands is a shorthand that anybody should be able to use.
s/comments/commands/ sorry.
As a compromise you could just do "< infile grep word | awk '{...}' | sort" so you still have the input file first but got rid of cat ;)
[deleted]
Typing speed has never been my handicap. To me this seems like just another case of premature optimization, the fact that you are typing in a command is a pretty good indication it is a one-off.
it isnt. cat + grep feels a lot more 'natural' to many users and makes 0 performance difference in 99.99% of usecases.
Please educate me
</etc/ssh/sshd_config grep PasswordAuthentication
I've been taught wrong and I've done it wrong for 15 years O_o
Thank you.
It reminds me of the idiom of putting "# -- coding: utf-8 --" at the top of Python 2.x files. Which is incredibly useful, but nobody remembers, and googles everytime.
This comes from the fact the first famous tutorials on Python where written by emacs users, and this editor recognizes this idiom.
But fun fact, the regex matching this line is "^[ \t\v]#.?coding[:=][ \t]*([-_.a-zA-Z0-9]+)" (see https://www.python.org/dev/peps/pep-0263/) and accepts many variations (including a vim format).
The simplest variation is the dumb "# coding: utf8", which is not only straightforward and easy to remember, but way less magical for anybody reading the code.
Bottom line, if you are stuck in 2.x, use "# coding: utf8".
Thank you.
It reminds me of the idiom of putting "# -- coding: utf-8 --" at the top of Python 2.x files. Which is incredibly useful, but nobody remembers, and googles everytime.
This comes from the fact the first famous tutorials on Python where written by emacs users, and this editor recognizes this idiom.
But fun fact, the regex matching this line is "^[ \t\v]#.?coding[:=][ \t]*([-_.a-zA-Z0-9]+)" (see https://www.python.org/dev/peps/pep-0263/) and accepts many variations (including a vim format).
The simplest variation is the dumb "# coding: utf8", which is not only straightforward and easy to remember, but way less magical for anybody reading the code.
Bottom line, if you are stuck in 2.x, use "# coding: utf8".
It's a holdover from the "good ol' days", see http://porkmail.org/era/unix/award.html#cat
Damn it, that "for f in *" loop ! This changes everything !
grep PasswordAuthentication /etc/SSH/sshd_config
Which is worse then using cat, from a user perspective.
Imagine if you look for something else, you have to point the cursor in the middle, right after grep and before the file. With cat |grep you press Arrow-up and Alt+Backspace and you are right where you want to be, ready to search for something else.
In scripts you can save the extra process though.
Imagine if you look for something else, you have to point the cursor in the middle, right after grep and before the file. With cat |grep you press Arrow-up and Alt+Backspace and you are right where you want to be, ready to search for something else.
In scripts you can save the extra process though.
I just use ^...^... or !gre:... and make my edits that way -- it feels much faster and more intuitive than cursoring around, moving my hand over to the arrow keys etc.
The shells were developed on keyboards that didn't have arrow keys and have affordances for them.
The shells were developed on keyboards that didn't have arrow keys and have affordances for them.
Seeing that you need to press enter, the arrow keys are not far away.
I doubt the later one.
I doubt the later one.
I’ll add that bash was the first Unix shell to have interactive editing with history, which comes from me suggesting the design of the readline library to Brian Fox around 1985. I was inspired by the editing JSYS (system calls) in TOPS-20 (VMS had something similar I believe) though they lacked the history mechanism.
You doubt that they keyboards lacked arrow keys? Just look at an ASR-33 (teletype) keyboard or ADM3A. The latter had arrows printed on the hjkl keys but there was no special way to generate “arrow” key presses — those terminals sent 7-bit ASCII characters directly. Look at what # and @ do in cooked mode — THAT goes back to Multics.
The teletype was a printing terminal and the ADM3A was a “glass teletype” — essentially a printing terminal too.
It’s possinle to write a lot of good code this way
The teletype was a printing terminal and the ADM3A was a “glass teletype” — essentially a printing terminal too.
It’s possinle to write a lot of good code this way
No. I doubt that many used them to program shells. Bash is from 1989 for example.
I'm not trying to argue; there are not "arrow" characters in the ASCII character set. sh, csh ksh and bash were all developed on ascii terminals. Brian had an Ann Arbor Ambassador which does do 8-bit ASCII but we always had them configured to set the top bit as a "meta" key, so essentially you had 7-bit ascii as well. All these terminals were connected by serial lines to computers (an unusued Vax 750 in the case of the GNU project; that was the machine he developed Bash on -- for the other shells, developed at Bell labs, ksh was also developed also ib a vax while sh and csh were developed on PDP-11s IMHO). You can see the key layouts available back in the days of ASCII terminals here: http://xahlee.info/kbd/vt100_terminal.html and of course use man ascii.
FWIW anyway Brian wouldn't have thought about those keys as the intended use of Readline would have been emacs keystrokes (emacs, or EMACS as it was in those days, had recently been ported to Unix by RMS).
Interestingly our 36-bit machines (PDP-10s and lispms) had arrow glyphs on their custom non-ASCII keyboards (KTV and space cadet) but they were for mathematical notation, not cursor movement!
FWIW anyway Brian wouldn't have thought about those keys as the intended use of Readline would have been emacs keystrokes (emacs, or EMACS as it was in those days, had recently been ported to Unix by RMS).
Interestingly our 36-bit machines (PDP-10s and lispms) had arrow glyphs on their custom non-ASCII keyboards (KTV and space cadet) but they were for mathematical notation, not cursor movement!
You mean ctrl-w or <ESC>bC? ;-)
I would find it okay without cat to start the next line with "grep newPattern " and then fetching the previous filename with alt-. (edit: or !$ of course, but alt-. is more practical) -- not saying it's necessarily always better, but knowing your shell better (and/or using a better one) is often a viable alternative to using another construct.
Also, than* (sorry)
I would find it okay without cat to start the next line with "grep newPattern " and then fetching the previous filename with alt-. (edit: or !$ of course, but alt-. is more practical) -- not saying it's necessarily always better, but knowing your shell better (and/or using a better one) is often a viable alternative to using another construct.
Also, than* (sorry)
No. The alternative is not any better. Besides if you don't know what you are looking for, piping greps after each other is faster to type.
Don't forget about:
ChallengeResponseAuthentication noFairly standard stuff, definitely interesting to see all the IoT credentials attempred.
I'd recommend SSHGuard over fail2ban though, I seem to remember the version of fail2ban in the Debian repos completely choking on IPv6 and failing open which is obviously undesirable.
I'd recommend SSHGuard over fail2ban though, I seem to remember the version of fail2ban in the Debian repos completely choking on IPv6 and failing open which is obviously undesirable.
I feel like fail2ban failing open is a good thing. If it fails closed you can't SSH into the server. If it fails open it's just as though you aren't using fail2ban.
Actually, my biggest fear with fail2ban is it failing and locking me out of a remote server. If it indeed always fails open then there's no reason for me not to use it.
Though, I don't know how it could be guaranteed to always fail open.
Actually, my biggest fear with fail2ban is it failing and locking me out of a remote server. If it indeed always fails open then there's no reason for me not to use it.
Though, I don't know how it could be guaranteed to always fail open.
> I feel like fail2ban failing open is a good thing. If it fails closed you can't SSH into the server. If it fails open it's just as though you aren't using fail2ban.
But it fails open whilst you think there's a layer of protection there.
> Actually, my biggest fear with fail2ban is it failing and locking me out of a remote server
Most of these tools will let you whitelist an address - and presumably there's usually a way back in via a serial console/IPMI-KVM interface?
But it fails open whilst you think there's a layer of protection there.
> Actually, my biggest fear with fail2ban is it failing and locking me out of a remote server
Most of these tools will let you whitelist an address - and presumably there's usually a way back in via a serial console/IPMI-KVM interface?
>But it fails open whilst you think there's a layer of protection there.
That's pretty easy to test for.
>will let you whitelist an address
I don't have a static IP address.
>usually a way back in via a serial console/IPMI-KVM interface?
I haven't been able to do this at my provider when password login is disabled. Maybe I just don't know the way.
That's pretty easy to test for.
>will let you whitelist an address
I don't have a static IP address.
>usually a way back in via a serial console/IPMI-KVM interface?
I haven't been able to do this at my provider when password login is disabled. Maybe I just don't know the way.
My experience with SSHGuard was it treated monitoring events (specifically from monit) as failed attempts and blocked further attempts marking the service as unreachable.
I'm sure this can be configured but fail2ban does not block such attempts.
Fail2ban failing on ipv6 is strange given it doesn't do anything networky. It just analyses logs and updates iptable.
Calling "iptables" with a v6 address doesn't sound too clever actually.
Installing "iptables" also installs ip6tables.
https://linux.die.net/man/8/ip6tables
https://linux.die.net/man/8/ip6tables
I wonder why the author set up a dedicated SSH python server which mimics some unix userspace as a honeypot. Why not a VM with a real standard widespread linux distribution to see what attackers actually do? Obviously their codes are not very sophisticated that they stop when "uname" fails with certain arguments.
Because it's much easier to set up? It's not breaking after any session no matter what the attacker does. Every session is isolated if several run concurrently. Getting this with a VM involves quite some effort. Then you need to make sure the attacker cannot use any commands to cause external damage but still make them seem to work. But the latter is also a problem with the simulated environment. It's quite easy to detect if you're not just blindly sending automated keystrokes without checking the feedback.
Objectively there should be no difference between a honeypot VM and an actual "productive" VM. I acknowledge that it is much harder to setup, maintain and supervise a network of honeypots VMs instead of a dedicated isolated honeypot server process which just simulates a system. However, as mentioned in other comments here, there is no gain of knowledge if you don't simulate a whole system but only parts of it.
They stop because they know that it's a honeypot. I guess it's a simple check for popular honeypots which emulate linux commands.
Changing the SSH port proved to be most successful. Yes, of course you can find the port with a port scan. But it keeps the logs clean. And I don't want to waste CPU cycles on some brute-forcing idiots.
(I'm primarly a developer, not sysadmin)
Is using non standard ports a reasonable approach? On one hand, it's kind of a security-by-obscurity measure, and it's also a (very minor) inconvenience to real users. However if it's not being used in place of other reasonable security measures, I'm not really sure what's bad about it, but it does feel a bit janky to me.
Same goes for other non-public services such as VPN.
What ports should be used? I think clearly you don't want to use other well known services (eg, running ssh on port 25 is just going to fill your logs with failed connection errors). Should you use ports >1024? >10000?
Is using non standard ports a reasonable approach? On one hand, it's kind of a security-by-obscurity measure, and it's also a (very minor) inconvenience to real users. However if it's not being used in place of other reasonable security measures, I'm not really sure what's bad about it, but it does feel a bit janky to me.
Same goes for other non-public services such as VPN.
What ports should be used? I think clearly you don't want to use other well known services (eg, running ssh on port 25 is just going to fill your logs with failed connection errors). Should you use ports >1024? >10000?
> it's kind of a security-by-obscurity measure
This comes up as a point of confusion often, so allow me to clarify:
A non-standard port as the only security mechanism (e.g., an unauthenticated HTTP admin-interface) would indeed be 'security through obscurity', but a non-standard port as an extra mitigation layer on top of existing security mechanisms (e.g., SSH authentication) is 'defense in depth'.
This comes up as a point of confusion often, so allow me to clarify:
A non-standard port as the only security mechanism (e.g., an unauthenticated HTTP admin-interface) would indeed be 'security through obscurity', but a non-standard port as an extra mitigation layer on top of existing security mechanisms (e.g., SSH authentication) is 'defense in depth'.
That’s a distinction I never understood but makes a lot of sense. Thanks for the explanation.
I’m so tired of hearing people quote “security by obscurity” in relation to moving ssh ports. It is NOT security by obscurity (SBO). SBO is taking an insecure thing and trying to hide it, and relying on the hiddenness as the ONLY means of security. SSH is already highly secure, so hiding it has nothing to do with the security. You can debate whether it’s worth the inconvenience vs reducing log spam, but SBO does not come into it at all.
It's not security by obscurity; obscurity can be a useful component of security. Something that's well protected and hard to find is less likely to be compromised than something that's well protected and easy to find, because some percentage of attackers won't bother to look for it. "Security by obscurity" occurs when someone tries to use obscurity in place of security, by 'hiding' their insecure thing.
Besides, running a service on a non-standard port offers pretty good protection against a fairly common threat scenario in which a new vulnerability is discovered in a well-known service and attackers start sweeping the internet for open ports in order to exploit it.
Not that you should automatically run your services on non-standard ports; there are tradeoffs as others have mentioned. But if you've got to expose something dangerous to the internet at large (and that's an assumption that you should question frequently), then avoiding the standard ports can be a useful tool.
Besides, running a service on a non-standard port offers pretty good protection against a fairly common threat scenario in which a new vulnerability is discovered in a well-known service and attackers start sweeping the internet for open ports in order to exploit it.
Not that you should automatically run your services on non-standard ports; there are tradeoffs as others have mentioned. But if you've got to expose something dangerous to the internet at large (and that's an assumption that you should question frequently), then avoiding the standard ports can be a useful tool.
I typically just pick a high numbered port. > 10k would work.
I see it as a way to reduce the number of attacks, which is helpful, and may end up being more secure, but I wouldn't count on that alone. Against botnet attacks it will likely help, but against someone specifically targeting you, it likely will only slow them down.
Basically it boils down to 'why not?' for me.
I see it as a way to reduce the number of attacks, which is helpful, and may end up being more secure, but I wouldn't count on that alone. Against botnet attacks it will likely help, but against someone specifically targeting you, it likely will only slow them down.
Basically it boils down to 'why not?' for me.
A high numbered port (above 1024) can be bound by non root programs. Use some non 22 port below 1024 if you want to change the port. Or use some RBAC system like selinux to keep anyone from binding to 2222 or whatever.
Awesome point, and exactly the advice I was looking for.
What is the problem?
Another authorized user or a non-root RCE compromise could start listening on the ssh port if sshd ever dies for some reason.
And then what? /etc/ssh is still owned by root, another user can't see the hostkeys. So you'll get an error message if custom keys are used.
Remote user tries to log in. Cannot. Issues (or trojan prompts for) password.
It's a game of percentages.
It's a game of percentages.
SSH key verification...
Server key? Sure, but what's the accept rate on new keys? On short-lived, poorly provisioned, AWS instaances, as just one example.
Again, percentages. With enough attempts, some will succeed.
Again, percentages. With enough attempts, some will succeed.
If it's a new server (like your example) there should be no other user already logged in. If it's not new, then you'll get a warning. And focusing on the "shortlived", so the damage is also shortlived...
I can only speak for myself, if other people are ignoring warnings, it's their problem.
I can only speak for myself, if other people are ignoring warnings, it's their problem.
The original question was: what's the risk, or threat model.
I believe that's been adequately addressed.
I believe that's been adequately addressed.
> I'm not really sure what's bad about it
You say it yourself:
> also a (very minor) inconvenience to real users
I would disagree with the “very minor” part. To paraphrase myself (https://news.ycombinator.com/item?id=6617312):
As I understand the argument, it’s “Changing port number add security, therefore it’s a good idea.” I think nobody argues that it adds security. The problem is that:
1. It adds very little security: 16 bits is not much, and the result is not 256 bits (say) of SSH key plus 16 bits equals 272 bits, but instead effectively still 256 bits, or 256+8×10⁻⁷³ bits.
2. The security it adds is itself bad (sent in cleartext, easily brute-forced)
3. These problems stand against the many drawbacks of this previously discussed (complexity, confusion, etc.).
And the final argument: If increased security is what you want, simply increase your key lengths and/or password lengths, and you will get much more than 8×10⁻⁷³ bits of security, without any of the above problems.
You say it yourself:
> also a (very minor) inconvenience to real users
I would disagree with the “very minor” part. To paraphrase myself (https://news.ycombinator.com/item?id=6617312):
As I understand the argument, it’s “Changing port number add security, therefore it’s a good idea.” I think nobody argues that it adds security. The problem is that:
1. It adds very little security: 16 bits is not much, and the result is not 256 bits (say) of SSH key plus 16 bits equals 272 bits, but instead effectively still 256 bits, or 256+8×10⁻⁷³ bits.
2. The security it adds is itself bad (sent in cleartext, easily brute-forced)
3. These problems stand against the many drawbacks of this previously discussed (complexity, confusion, etc.).
And the final argument: If increased security is what you want, simply increase your key lengths and/or password lengths, and you will get much more than 8×10⁻⁷³ bits of security, without any of the above problems.
You know what it does do though? Dramatically reduces the amount of log spam :). Running SSH on port 22 vs. even just 2222 significantly reduces the number of failed login attempt messages. They'd always fail anyway unless they happened to somehow get ahold of my ssh private key, but it's sure a lot less annoying when looking for something in the logs to not have to filter through all that noise.
You're looking at this the wrong way, because you seem to assume that non-standard ports adds to security the same way the key length does, which is not the case.
I can’t think of any way it could be otherwise, but please, feel free to enlighten us all how a non-standard port number adds any more security than would an additional 16-bit key.
Non-standard ports, port knocking and similar things work before anything reaches sshd; so they can mitigate vulnerabilities in sshd. Obviously a non-standard port is the weakest fellow in the bunch, but that does not mean the effect is zero. An extra 16 bit key length would obviously never mitigate a sshd vulnerability.
An entirely different effect has been brought up by others already; a non-standard port is enough to evade ~99 % of all automated attacks, therefore you can run at higher log levels and might notice actual attackers earlier.
An entirely different effect has been brought up by others already; a non-standard port is enough to evade ~99 % of all automated attacks, therefore you can run at higher log levels and might notice actual attackers earlier.
> Obviously a non-standard port is the weakest fellow in the bunch, but that does not mean the effect is zero.
Like I said, nobody argues that it adds zero security, but that, for all the hassle it introduces, it adds way too little security to be worth it. 16 bits is nothing, and can be brute forced quickly.
Regarding port knocking: I’m assuming that most people don’t write their own port knocking software, but use something standard. The configuration of any port knocking scheme is equivalent to an additional separate key of length log2(number_of_possible_port_knocking_configurations). What is the effective “key length” of port knocking schemes?
Also remember that the “key” of port knocking, just like a non-standard port number, is transmitted in the clear, so anybody listening to the traffic can see it. (And if you assume that the attacker can’t listen to the traffic, why are you even using SSH instead of something simpler like telnet?)
Like I said, nobody argues that it adds zero security, but that, for all the hassle it introduces, it adds way too little security to be worth it. 16 bits is nothing, and can be brute forced quickly.
Regarding port knocking: I’m assuming that most people don’t write their own port knocking software, but use something standard. The configuration of any port knocking scheme is equivalent to an additional separate key of length log2(number_of_possible_port_knocking_configurations). What is the effective “key length” of port knocking schemes?
Also remember that the “key” of port knocking, just like a non-standard port number, is transmitted in the clear, so anybody listening to the traffic can see it. (And if you assume that the attacker can’t listen to the traffic, why are you even using SSH instead of something simpler like telnet?)
Vastly fewer attacks -> less cognitive load on admins. The logs don't fill up.
Technical protection is likely limited, but then, admin attention is also a limited resource.
Technical protection is likely limited, but then, admin attention is also a limited resource.
Also means attackers are much easier to spot in the logs. It's also a point of real interest if an attacker took the time to port scan you first in order to detect which port your ssh is on.
Or, if you prefer, you're choosing to associate with a higher grade of adversary.
There is no added security. Just added comfort of not having to deal with spammers filling up logs.
I am using high ports >30000 but you can chose what you want.
Really, this sounds like a bad practice to bind on non privileged port.
A user can keep running a program to check if your non privileged port can be bound and if it could, it can start any behaving daemon that could be pretending to be a valid SSH daemon but could have anything like key loggers. Even a single restart of sshd could make it happen.
A user can keep running a program to check if your non privileged port can be bound and if it could, it can start any behaving daemon that could be pretending to be a valid SSH daemon but could have anything like key loggers. Even a single restart of sshd could make it happen.
It doesn't have access to the host keys, so it can't do very much unless you intentionally bypass the "someone is intercepting your connection" error your ssh client will give you in that case.
I have my perimeter sshd on port 22... Only bound to IPv6
It's a big quiet void out there in sixspace.
It's a big quiet void out there in sixspace.
Years ago (actually probably more than 10 years ago now) I actually switched from port 22 to 622 on my server because I wanted to get rid of the noise of people attempting to bruteforce my SSH regularly. It worked perfectly for years but surprisingly I've had a handful of bruteforce attempts on port 622 in the past year or so. Nothing particularly targeted either, always the same typical default users (root, admin, oracle, mysql etc...). I wonder who bothers doing that.
Since I disabled password logging on all accounts and my key is stored on an HSM I'm not too worried about it though.
Since I disabled password logging on all accounts and my key is stored on an HSM I'm not too worried about it though.
> I wonder who bothers doing that.
Somebody that added nmap to their bot script.
Somebody that added nmap to their bot script.
622 might be too low. Scanning first 1024 ports is easier.
I never understood why people would use fail2ban or similar approaches. Just set proper password and move on. SSH traffic is tiny, it's not a problem. You'll never be hacked with a proper password. Let them waste their time.
I think you mean just use key-based authentication only ;)
You aren't infallible. While it's easy enough to secure a minimal server with only SSH access, every time you add another service, provide access to a new user, or change a configuration, there's a chance you'll miss something or make a dumb mistake. Running Fail2Ban is a very cheap and easy method to ensure that, even if you do fuck up somewhere, there's another layer of security that should prevent malicious access in most cases (nothing will save you if you set the pass to admin/admin, e.g.).
Because fail2bans approach to log parsing is totally sane and confidence inspiring, right?
The failed attempts make it harder to monitor for other attacks because of the noise in log files, network traffic, etc. and if an attacker IP is blocked early they can't try more effective attacks.
I've set up a second obstacle by allowing access to the device from a certain range of IPs on the router. Cleaned up the log pretty good.
logins can be delayed [0] and TOTP can be used in conjunction with SSH (without google authenticator)
[0] https://unix.stackexchange.com/questions/105553/how-to-provi...
edit:
quick and dirty notes of my setup [1]
[1] https://pastebin.com/yYzSrM61
[0] https://unix.stackexchange.com/questions/105553/how-to-provi...
edit:
quick and dirty notes of my setup [1]
[1] https://pastebin.com/yYzSrM61
Except actual attacks don't show up in logs anyway, so it's still pointless?
The SSH daemon logs when it successfully rejects an access. A successfully rejected access is inconsequential to your security. If you are using secure passwords or pubkey authentication, it will never log a successful login by an attacker. What remains then is exploitation of the SSH server ... but the SSH server doesn't have a code path that logs "I have been exploited".
The SSH daemon logs when it successfully rejects an access. A successfully rejected access is inconsequential to your security. If you are using secure passwords or pubkey authentication, it will never log a successful login by an attacker. What remains then is exploitation of the SSH server ... but the SSH server doesn't have a code path that logs "I have been exploited".
/etc/sshrc executes before a successful ssh login, you can use that to be notified before an attacker has any access to log files
... so? How does that contradict what I wrote?
I originally set up fail2ban because I got fed up with the noise of the hard disk going tick...tick...tick every 15 seconds or so, as another password guessing bot login attempt got logged and the disk heads had to seek as the logfile was written out to disk...
Do you ever examine logs? Fail2ban (or even better, using a nonstandard port or both) keep the noise out of lots to the point that you can still examine them manually.
Without it, 99.99% of the average ssh log is failed back attempts.
Without it, 99.99% of the average ssh log is failed back attempts.
Changing the port away from 22 also had that effect in my experience.
This was like night and day. Non stop constant barrages on the default port, all quiet on the ssh k@ip -p XXX.
I found that setting the port and user in ~/.ssh/config made everything way easier. Also fill in the IP as HostName if you're not using DNS names.
Another more secure option is just to only allow key auth.
Port knocking + key-based auth... What more do you need?
What benefit does port knocking add to having a key auth only setup?
If it's set up properly, it could mean you don't have log files filled with login attempts since the SSH port won't open to them until a successful knock and the knocking doesn't have to be logged.
While port knocking is really just another layer of obscurity, obscurity works really well on scattershot/random attacks. An attacker dedicated to getting into your specific server is another matter but thankfully far more rare.
While port knocking is really just another layer of obscurity, obscurity works really well on scattershot/random attacks. An attacker dedicated to getting into your specific server is another matter but thankfully far more rare.
"While port knocking is really just another layer of obscurity, obscurity works really well on scattershot/random attacks."
Thank you. Remember - security through only obscurity is a bad idea, but additional layers of obscurity can be very valuable.
Also remember: a typical port knock is a series of three ports that all have to be hit in a certain timeframe - for instance, 2000, 4000, 8000 - that's a big "keyspace" to brute force through at WAN packet speeds ...
Thank you. Remember - security through only obscurity is a bad idea, but additional layers of obscurity can be very valuable.
Also remember: a typical port knock is a series of three ports that all have to be hit in a certain timeframe - for instance, 2000, 4000, 8000 - that's a big "keyspace" to brute force through at WAN packet speeds ...
Ideally, your port-knocking service is much simpler and easier to audit than your ssh service. It's also much more obscure. So you have a service which is very unlikely to suffer a 0-day vulnerability listening all the time to engage a much more vulnerable service only at those exact times you need it.
What benefit does locking the glass doors into a bank add to having time-locked vault? Defense in depth.
The vault and the locked glass doors defend against entirely different things. Same doesn’t really apply for ssh keys and port knocking.
A port knock is just a clear password :/
I much prefer restricting port 22 to a few ip and disable passwords
I much prefer restricting port 22 to a few ip and disable passwords
Not with single packet authentication from fwknop
http://www.cipherdyne.org/fwknop/docs/fwknop-tutorial.html#w...
http://www.cipherdyne.org/fwknop/docs/fwknop-tutorial.html#w...
fwknop has a cache to prevent replay attacks, that plus the fact the packets are only valid for a certain length of time pretty much thwarts this. Remember, fwknop is _in addition_ to your existing security practices, it is not the only "password."
I have SSH with key auth everywhere, so I have no security worries.
But when sshd ends up pegging an entire core, and I can't login myself anymore, then fail2ban (or even whitelisting IP ranges for ssh) becomes necessary.
But when sshd ends up pegging an entire core, and I can't login myself anymore, then fail2ban (or even whitelisting IP ranges for ssh) becomes necessary.
It would most probably never end up pegging an entire core if you use key auth and have conventional logins deactivated, no?
I mean, why would people even try.
I mean, why would people even try.
Keys, like passwords, can be leaked, so it's possible there are databases of leaked keys out in the world, because unlike PGP or SSL certs, ssh keys don't have a revocation mechanism built in. So they could just try all the known leaked keys - like they try known leaked or default passwords.
Then there was this: https://jblevins.org/log/ssh-vulnkey (tl;dr - there was a bug in debian that caused ssh-keygen to only produce a very small number of keys rather than keys distributed across the whole keyspace). After that became public the bots were all about trying those keys for a few years after. To this day it's recommended to not used keys from that set.
Point being - the bots will try because it the tiny marginal cost is not high enough to stop the attempt.
Then there was this: https://jblevins.org/log/ssh-vulnkey (tl;dr - there was a bug in debian that caused ssh-keygen to only produce a very small number of keys rather than keys distributed across the whole keyspace). After that became public the bots were all about trying those keys for a few years after. To this day it's recommended to not used keys from that set.
Point being - the bots will try because it the tiny marginal cost is not high enough to stop the attempt.
They simply try password auth, and fail with a message that password auth is off. Constantly. All the time.
Set up a non standard port. This will stop over night.
That would be problematic, but I never encountered that. I'm using cheapest VPS with public IP and without any additional protections. I just checked and its load average is 0.00, so load is non-existant.
[deleted]
I did just to keep the logs cleaner.
Largely, I think, moving to an alternate port cut SSH crack attempts to near zero; but I use fail2ban too.
[deleted]
My current take:
nftables instead of iptables
port-knocking
non-standard port
key+pass access/auth
ip whitelist
good logging
ED25519 wherever possible!!!
nftables instead of iptables
port-knocking
non-standard port
key+pass access/auth
ip whitelist
good logging
ED25519 wherever possible!!!
I love the idea of Single-Packet Authorization with fwknop instead of port knocking: http://www.cipherdyne.org/fwknop/
How does fwknop compare to knockknock? https://moxie.org/software/knockknock/
The design decisions that govern fwknop provide guidance on how fwknop is different from knockknock: http://www.cipherdyne.org/fwknop/docs/fwknop-tutorial.html#d...
Thanks.
I wish fwknop would be added to pfsense.
Nothing wrong with this, but a strong password for all Unix accounts (or, ideally, only allowing SSH with public key authentication) is essentially all you need. Unless you're using a dumb password, you're far more likely to be compromised by an application or OPSEC flaw (like someone getting into the email you used to register your server hosting account) than some crazy SSH compromise.
Curious, what specifically does nftables offer in this context that iptables doesn't ?
why nftables rather than iptables?
Im also curious about this, they use the same netfilter backend
Just looking toward the future. I think bpf is cool but not aimed at production routing that most network techs can approach. nftables fixes so many issues of iptables and is generally viewed as it's replacement. nftables also has a smaller attack surface due to its youth mostly.
So I made the choice to go ahead and focus on learning nft. It's been enjoyable.
So I made the choice to go ahead and focus on learning nft. It's been enjoyable.
Is that true? I thought nftables was still behind on supported features compared to iptables and nftables runs on a VM.
Anyway, nftables should be nicer to administer. More pf-like.
Anyway, nftables should be nicer to administer. More pf-like.
IP whitelist is tough when your home network has a dynamic IP.
I called up my provider and paid a little extra for a fixed IP. Really it was just laziness though because in practice my home IP seemed to only change when I restarted the router.
I wrote a little utility to keep ssh ports off unless a totp packet is sent to a UDP port. I haven't worked on it much since the initial proof of concept. There are several things that could be done to improve it (open only for the address that sent the packet, symmetric key for safer secret distribution, etc). Shared key would involve encrypting time and only open if the decrypted time matches current.
The totp packet is a full hash of time + shared code so brute force is completely infeasible.
It's currently in python, it would be much better in something like go with daemon monitoring. It is very simple, and it practically eliminates attempts. If it became widely known there would probably be attempts on the udp port. An additional improvement would be randomize the listening port based on the time+hash:
https://dhj.io/posts/2017/05/16/totp-knock/
The totp packet is a full hash of time + shared code so brute force is completely infeasible.
It's currently in python, it would be much better in something like go with daemon monitoring. It is very simple, and it practically eliminates attempts. If it became widely known there would probably be attempts on the udp port. An additional improvement would be randomize the listening port based on the time+hash:
https://dhj.io/posts/2017/05/16/totp-knock/
In case you were unaware and didn't just want to write your own, fwknop is an off the shelf tool to do the same.
http://www.cipherdyne.org/fwknop/
http://www.cipherdyne.org/fwknop/
I appreciate the reference.
I looked at that before starting and reference it in the blog post (but should probably include a direct link to the software rather than the original concept post and article that include links).
The similarities are they both use a single packet and they are both an improvement on port knocking.
This is a simpler solution (pairing UDP with TOTP). No TCP connection is required. Making it ip address specific would prevent replay attacks (although even without address specific the replay would only be valid for ~30s).
Another benefit is that a port scan will reveal no ports open (because it is a one-way UDP based protocol).
fwknop is definitely a polished solution where this is just a proof of concept for the TOTP/UDP as a shared key knock.
Thank you for the feedback!
EDIT: I updated the post to include a direct link to fwknop rather than just links to the posts/articles about it.
I looked at that before starting and reference it in the blog post (but should probably include a direct link to the software rather than the original concept post and article that include links).
The similarities are they both use a single packet and they are both an improvement on port knocking.
This is a simpler solution (pairing UDP with TOTP). No TCP connection is required. Making it ip address specific would prevent replay attacks (although even without address specific the replay would only be valid for ~30s).
Another benefit is that a port scan will reveal no ports open (because it is a one-way UDP based protocol).
fwknop is definitely a polished solution where this is just a proof of concept for the TOTP/UDP as a shared key knock.
Thank you for the feedback!
EDIT: I updated the post to include a direct link to fwknop rather than just links to the posts/articles about it.
This all is easy if you only get a handful of login attempts. But when you get more, and more, it becomes an issue. On one of my servers it got so bad that SSH was at the end constantly using an entire CPU core.
I don’t have logs from that server, but here are logs – just the failed attempts – of 2 months from a server that was less severely affected: https://s3.kuschku.de/public/failed_ssh [327M]
And that was despite already blocking massive areas of IP space already.
I don’t have logs from that server, but here are logs – just the failed attempts – of 2 months from a server that was less severely affected: https://s3.kuschku.de/public/failed_ssh [327M]
And that was despite already blocking massive areas of IP space already.
Fail2Ban and psad will do wonders for that.
Yeah, I now simply removed 0.0.0.0/0 dport 22 from the whitelist and only added a select few IP ranges. That has calmed the storm significantly, and if an IP from this range (my ISP) tries it anyway I can contact my ISP (a small local ISP) to take that down.
That's even better, if you don't need to access from arbitrary IPs.
$ grep -c sshd /etc/hosts.deny
1192
$ uptime
11:58:51 up 327 days, 21:33, 1 user, load average: 0.13, 0.11, 0.09
http://denyhosts.sourceforge.net/
you should probably upgrade that kernel
If only there were some way to upgrade the kernel without rebooting. What a god-send that would be.
The Spectre/Meltdown patches required a reboot.
Not all architectures are affected by it.
/s?
(kgraft, kpatch)
(kgraft, kpatch)
What can you tell from the line?
Hasn't rebooted in a year
That used to be a selling point of Linux versus Windows.
Times have changed...
Times have changed...
My servers generally have an IPv4 address and a whole IPv6 subnet. I like to disable SSH except on a specific IPv6 address.
Many botnets just focus on IPv4 and there is a lot more territory to scan on IPv6. I usually couple that with moving to a non-standard port, enforcing modern encryption (ed25519 or ChaCha20, etcc), fail2ban, require SSH keys, etc
Many botnets just focus on IPv4 and there is a lot more territory to scan on IPv6. I usually couple that with moving to a non-standard port, enforcing modern encryption (ed25519 or ChaCha20, etcc), fail2ban, require SSH keys, etc
I think that by using obviously easy passwords anyone who really is looking for something is going to go to the next target. After all impossible to believe anything of value is behind 1234567 or changeme as a password. Even 'baseball' makes slightly more sense. Besides someone running an ssh server is not exactly mr computer newbie. Maybe a desktop you pick out of the trash might contain something interesting if that was the password.
In a classic CIA honeypot I would imagine the women are carefully matched to the target. If you are "James Bond" you get a better looking woman to try and trap you. If you are "Wallace Shawn" (in looks) you would probably figure out really quickly it's a trap if the woman looked like Angelina Jolie.
In a classic CIA honeypot I would imagine the women are carefully matched to the target. If you are "James Bond" you get a better looking woman to try and trap you. If you are "Wallace Shawn" (in looks) you would probably figure out really quickly it's a trap if the woman looked like Angelina Jolie.
I found fail2ban is necessary but not sufficient. It requires some initial number of failed attempts before the attacker is blocked.
To prevent even those initial attempts, I use multiple layers of defenses such as country based blocking or blacklist based blocking. If an attacker slips through despite all this, I blacklist them manually in /etc/hosts.deny.
If there is any interest, my scripts are in https://github.com/KamarajuKusumanchi/hosts.deny/
To prevent even those initial attempts, I use multiple layers of defenses such as country based blocking or blacklist based blocking. If an attacker slips through despite all this, I blacklist them manually in /etc/hosts.deny.
If there is any interest, my scripts are in https://github.com/KamarajuKusumanchi/hosts.deny/
> It absolutely shocked me that it is worth the time of these drive-by attacks to try combinations like root/password, root/root, or root/admin. Apparently they have enough successes using those incredibly insecure combinations that it is worth their time.
It is fairly evident to anyone that has looked at the traffic that a honeypot gets that most of the activity is automated.
Most of it is purely botnets, some of it is automated password guessing followed by manual login. I think the amount of people manually trying passwords is insignificantly small.
It is fairly evident to anyone that has looked at the traffic that a honeypot gets that most of the activity is automated.
Most of it is purely botnets, some of it is automated password guessing followed by manual login. I think the amount of people manually trying passwords is insignificantly small.
I think they mean "time" for the botnet in this case
I am slowly closing all non-vital ports on my router and just letting services accessible from within the VPN.
No open port = no hacking attempts.
Investing a week of on-and-off studying and tinkering with openvpn is really paying off.
No open port = no hacking attempts.
Investing a week of on-and-off studying and tinkering with openvpn is really paying off.
> No open port = no hacking attempts.
That's just obviously nonsense? Closing the port does not change anything about the attempts. Nor about the success rate of the attempts, if you aren't being an idiot with insecure passwords.
That's just obviously nonsense? Closing the port does not change anything about the attempts. Nor about the success rate of the attempts, if you aren't being an idiot with insecure passwords.
Closing the port does not change anything about the attempts. Nor about the success rate of the attempts, if you aren't being an idiot with insecure passwords.
How about "No open port = no concern about possibly vulnerable services running on open ports"? I actually worry less about passwords and more about overflows, protocol problems and parse errors these days.
How about "No open port = no concern about possibly vulnerable services running on open ports"? I actually worry less about passwords and more about overflows, protocol problems and parse errors these days.
Yeah, sure, but (a) then those problems potentially also affect the VPN endpoint, so it's still a trade-off (b) much of the complex protocol machinery often is behind the authentication barrier, so the risk of just exposing the port to the public isn't necessarily that big, and (c) a firewall doesn't necessarily protect your vulnerable service, often there are browsers on the inside that an attacker could use to access those "protected" services.
My point isn't that blocking off ports at the firewall is always pointless, but that it's usually a trade-off, and keeping a vulnerable service running behind the firewall can still be a risk, and many "hacking attempts" are just irrelevant if you follow general best security practices, so it's pointless to do anything specifically to prevent them.
My point isn't that blocking off ports at the firewall is always pointless, but that it's usually a trade-off, and keeping a vulnerable service running behind the firewall can still be a risk, and many "hacking attempts" are just irrelevant if you follow general best security practices, so it's pointless to do anything specifically to prevent them.
I think the person above was maybe being too imprecise with their language. Obviously it doesn't affect the frequency of portscans and the like, but whitelisting ports is a reasonable approach to further mitigating your risks.
Well, potentially.
But then, there is no fundamental difference between a service rejecting unauthorized connections and a firewall rejecting unauthorized connections. If your service is already rejecting unauthorized connections, you don't gain anything by also rejecting the same connections at the firewall, and that is why "No open port = no hacking attempts" is ultimately nonsense: It doesn't change anything about the attempts, and chances are it doesn't fundamentally change anything about the rejections either.
Also, adding a VPN exposes the VPN service to the internet, which thus adds attack surface in a different place. Which might be worth it if you need remote access to otherwise vulnerable services. But the simplistic view of "rejecting connections at the firewall" == "no more hacking attempts!11" is just that: simplistic.
But then, there is no fundamental difference between a service rejecting unauthorized connections and a firewall rejecting unauthorized connections. If your service is already rejecting unauthorized connections, you don't gain anything by also rejecting the same connections at the firewall, and that is why "No open port = no hacking attempts" is ultimately nonsense: It doesn't change anything about the attempts, and chances are it doesn't fundamentally change anything about the rejections either.
Also, adding a VPN exposes the VPN service to the internet, which thus adds attack surface in a different place. Which might be worth it if you need remote access to otherwise vulnerable services. But the simplistic view of "rejecting connections at the firewall" == "no more hacking attempts!11" is just that: simplistic.
That's not how it works. If a vulnerability is found in the service, and you don't need external access, blocking it from the firewall/router essentially blocks the vulnerability. In your scenario, with a public facing service, you will get exploited by a 0 day.
Except that a VPN endpoint is a public facing service, which might get exploited with a 0-day. And that "internal services" more often than not are reachable via HTML email or just web browsers on the inside, which might be used to exploit your "internal service" with a 0-day.
What about http and https ports on a home web server?
Someday I'm going to put all the different pieces together and have things like SMTP & SSH auth failures, hosts hitting my spamtraps, bots scanning for open 23/TCP, and so on, to where I end up with one central host collecting all those events and injecting /32 routes for those IPs towards null0 in my core.
A friend of mine built this complete with a whole pile of honeypots and lots of companies use it.
https://www.blockedservers.com/
Super useful.
https://www.blockedservers.com/
Super useful.
How configurable is fail2ban? Is it service based? Am I in danger of locking out a legitimate user like someone who makes 25 ajax requests within the span of 3 seconds? Can I make it work for authenticated HTTP endpoints as well?
Long ago I made the same thing.
https://livesshattack.net
https://livesshattack.net
The numbers on https://cdn-images-1.medium.com/max/1600/1*47UCBwMdQGFNtk2ao... look very suspicious.
