boot logs shows chinese ip trying to login ssh
#1
My boot logs show chinese ip, anyway to prevent this?

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



[Image: X7UEpXC.png]

[Image: GcmM8jX.png]
  Reply
#2
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
  Reply
#3
(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 @psychedup,

I disabled root, and change port, and it helped.
  Reply
#4
(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
  Reply
#5
(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.
  Reply
#6
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.
  Reply
#7
(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".
  Reply


Possibly Related Threads...
Thread Author Replies Views Last Post
  Unable to boot from SPI stevefan1999 4 665 05-01-2019, 04:47 PM
Last Post: rhens1
  No Boot, Red Green and White flash at 1 sec intervals wesleykonrad 2 251 01-28-2019, 11:54 PM
Last Post: wesleykonrad
  boot priority - has precedence changed? jovval 1 484 09-22-2018, 02:02 AM
Last Post: mcerveny
  Enable I2C, I2s, SPI in boot-config file? HelgeMK 3 1,484 08-14-2018, 10:59 AM
Last Post: pas059
Bug u-boot (forks) status mcerveny 4 681 07-30-2018, 03:54 PM
Last Post: ayufan
  New ROCK64 doesn't boot p3ntium 18 1,288 06-03-2018, 06:06 PM
Last Post: Rocklobster
  Boot Problems, LEDs lit continuously Facecreator 22 2,559 05-14-2018, 10:24 PM
Last Post: pfeerick
  QQ Group 104471957, for Rock64 Chinese users fbms 7 952 04-23-2018, 02:34 AM
Last Post: Ryan
  No boot at all Arkadiusz 4 756 04-18-2018, 08:48 PM
Last Post: pfeerick
  Rock64 does not boot - SPI problem [resolved] csharpy 7 2,023 03-21-2018, 09:34 PM
Last Post: pfeerick

Forum Jump:


Users browsing this thread: 1 Guest(s)