PINE64

Full Version: boot logs shows chinese ip trying to login ssh
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
My boot logs show chinese ip, anyway to prevent this?

I am using lastest ayufan's image
Code:
root@rock64:~# uname -a
Linux rock64 4.4.126-rockchip-ayufan-239 #1 SMP Sun May 27 18:38:24 UTC 2018 aarch64 GNU/Linux
root@rock64:~#



[Image: X7UEpXC.png]

[Image: GcmM8jX.png]
I would recommend not running sshd on a public IP address unless there is some reason you need to log in remotely. The most secure way is to put the machine behind a firewall.

or if you have multiple network interfaces, you can tell sshd only to listen on the internal one. You can also tell sshd not to allow root to log in over ssh. You can also tell sshd to listen on a different port than 22, this will cut down on login attempts but not eliminate them. All of these things can be done by editing /etc/ssh/sshd_config.

Another thing you can do is configure sshd to authenticate using RSA encryption keys instead of passwords (you have to generate the keys first and distribute them to any machine(s) you want to connect from).

Here's an article with some good tips on securing your SSH: https://www.cyberciti.biz/tips/linux-uni...tices.html
(05-31-2018, 01:28 PM)psychedup Wrote: [ -> ]I would recommend not running sshd on a public IP address unless there is some reason you need to log in remotely. The most secure way is to put the machine behind a firewall.

or if you have multiple network interfaces, you can tell sshd only to listen on the internal one. You can also tell sshd not to allow root to log in over ssh. You can also tell sshd to listen on a different port than 22, this will cut down on login attempts but not eliminate them. All of these things can be done by editing /etc/ssh/sshd_config.

Another thing you can do is configure sshd to authenticate using RSA encryption keys instead of passwords (you have to generate the keys first and distribute them to any machine(s) you want to connect from).

Here's an article with some good tips on securing your SSH: https://www.cyberciti.biz/tips/linux-uni...tices.html

Thanks ,

I disabled root, and change port, and it helped.
(05-31-2018, 01:28 PM)psychedup Wrote: [ -> ]I would recommend not running sshd on a public IP address unless there is some reason you need to log in remotely. The most secure way is to put the machine behind a firewall.

Or at least use SSH keys
(05-31-2018, 04:24 PM)evilbunny Wrote: [ -> ]
(05-31-2018, 01:28 PM)psychedup Wrote: [ -> ]I would recommend not running sshd on a public IP address unless there is some reason you need to log in remotely. The most secure way is to put the machine behind a firewall.

Or at least use SSH keys

I third that suggestion. Generate RSA keys and disable password login, as well as preventing root login via ssh.
Have you any periphals like cameras attached. They're notorious for calling back home. You did a reverse lookup so you know the source. Hackers haven.
(06-01-2018, 08:25 AM)Rocklobster Wrote: [ -> ]Have you any periphals like cameras attached. They're notorious for calling back home. You did a reverse lookup so you know the source. Hackers haven.

This true in Windows where cheap no-name imported devices often require installation of unsigned suspect drivers.   It should NOT happen in Linux with vetted opensource drivers.

But your observation that this may have happened because the Rock64 "phoned home" is probably right on track, because in my experience, most of the time, an attack like this is not due to random port scanning, but is rather a targeted attempt to compromise a machine where some kind of embeded malware has pinged back to the mothership.

If the original poster had been foolish enough to have not reset the root password BEFORE connecting to the internet (as many are) then the Rock64 would have immediately been compromised and become a vector to attempt to compromise EVERY OTHER MACHINE ON THE LOCAL NETWORK.

This is serious stuff.  Someone should setup up a dummy honeypot network with some old PC's with names like DARPA_370 and LAB_04, then hook a fresh Rock64 up through a logging router or access point and see if it starts to sniff around and then tries to "phone home".