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:
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]
  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
Sad No boot, garbage console text and blinking red light ... jean_bruder 0 35 07-09-2020, 02:15 PM
Last Post: jean_bruder
Bug u-boot (forks) status mcerveny 10 1,660 06-19-2020, 03:40 PM
Last Post: XmAz
  No boot up after power on Whoopsadaisy 2 189 05-26-2020, 11:24 PM
Last Post: Whoopsadaisy
  Graphical boot manager john3voltas 0 131 03-25-2020, 02:27 PM
Last Post: john3voltas
  doesn't boot, no video cjyar 7 567 11-15-2019, 03:45 PM
Last Post: ab1jx
  Unable to boot from SPI stevefan1999 4 1,032 05-01-2019, 04:47 PM
Last Post: rhens1
  No Boot, Red Green and White flash at 1 sec intervals wesleykonrad 2 511 01-28-2019, 11:54 PM
Last Post: wesleykonrad
  boot priority - has precedence changed? jovval 1 1,069 09-22-2018, 02:02 AM
Last Post: mcerveny
  Enable I2C, I2s, SPI in boot-config file? HelgeMK 3 2,052 08-14-2018, 10:59 AM
Last Post: pas059
  New ROCK64 doesn't boot p3ntium 18 2,012 06-03-2018, 06:06 PM
Last Post: Rocklobster

Forum Jump:


Users browsing this thread: 1 Guest(s)