I use iptables, but all my servers have public IPs, for we do telecommunications. If my firewall is down for any reason and I don't catch it, they will hack me. I don't know how they do it, for I have password authentication disabled, but they hack me and it's always via Centos 7 machines. But Openssh in Centos 7 is so old that cannot communicate with newer machines, they cannot agree on protocols and ciphers, etc. So I am trying to compile openssh latest in Centos 7, but no libwrap support. The perfect storm. They have been installing Bitcoin miners right and left. I think that they penetrate a single box that is left with password authentication =yes, and do a lateral infection. The only failsafe solution is to use hosts.allow. They can take down a powerplant with this technique. To remove libwrap was a completely irresponsible move. On Wed, Jun 23, 2021 at 12:19 PM Brian Candler <b.candler at pobox.com> wrote:> On 23/06/2021 17:03, Saint Michael wrote: > > I got hacked in 72 servers this week, they installed Bitcoin miners. > > Are you saying this happened through opensshd? > > What specifically was the cause: do you allow password authentication > for example? > > You can control this by IP address with "Match" clauses in sshd_config. > For example: > > PasswordAuthentication no > > Match Address 10.0.0.0/8,fc00::/7 > PasswordAuthentication yes > > This will allow passwords only from the 10.0.0.0/8 and fc00::/7 > networks, forcing connections from the Internet to use a proper > authentication mechanism (e.g. keys) > >
OpenSSH has built-in support for per-user and host restrictions via the "AllowUsers" and "DenyUsers" settings in /etc/ssh/sshd_config. Relying on host-based security is not really a good idea but you can do it with stock OpenSSH if you really need to. - todd
On 23.06.21 18:27, Saint Michael wrote:> I use iptables, but all my servers have public IPs, for we do > telecommunications. If my firewall is down for any reason and I don't catch > it, they will hack me.1. You want to start doing that thing called "monitoring". 2. If by "firewall", you mean a unit *other* than the target machines, from the moment it is "down", it should *NOT* allow any through traffic to the targets (unless necessary to let an admin remote in to fix the firewall problem). 3. Otherwise, i.e., all you have is the iptables on the target machines themselves, you IMHO want to -- have the sshd listen on a nonstandard port, -- make the iptables, *if they are up and working*, NAT connection attempts to port 22 to the real port, and -- hand a "port cheat sheet" to the admins so that *they* can remote into some machine to fix the iptables being "down". I shall stop here with the details, though, because if you don't know how you get (re)hacked, you don't know whether it's done *through SSH* in the first place, either (and, if so, whether it's by weak passwords, an authorized key hidden someplace during the first hack, etc. etc.).> But Openssh in Centos 7 is so old that cannot communicate with > newer machines, they cannot agree on protocols and ciphers, etc.... out of interest, what's your reference standard there, since it apparently surpasses even hardening guides like https://www.ssh-audit.com/hardening_guides.html#rhel7 ... ? Regards, -- Jochen Bern Systemingenieur Binect GmbH -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3449 bytes Desc: S/MIME Cryptographic Signature URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20210623/2b7e6c4d/attachment.p7s>