101–110 of 186 posts
Fairly 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.
Fail2ban failing on ipv6 is strange given it doesn't do anything networky. It just analyses logs and updates iptable.
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. Wh…
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.
Earlier quoted context omitted.
(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. Wh…
I am using high ports >30000 but you can chose what you want.
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.
Fairly 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.
$ 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 I'm using DenyHosts for this, there are alternatives but this works for me. http://denyhosts.sourceforge.net/
you should probably upgrade that kernel
Earlier quoted context omitted.
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 usefu…
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 ;)
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. Wh…
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.
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.
It's a big quiet void out there in sixspace.
Earlier quoted context omitted.
(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. Wh…
> 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'.