Get best of the week

Bagaimana tidak melindungi sistem Anda di cloud

Seringkali, ketika saya memberi tahu seseorang tentang kerentanan, mereka memandang saya seperti orang gila dengan tanda "Bertobatlah, karena akhir dunia sudah dekat"!

Sekarang semua orang berlari dalam kepanikan dan mencoba untuk mengatur "jarak jauh", membuat kesalahan sederhana, mengumpulkan semua kemungkinan garu, jadi saya memutuskan untuk berbagi beberapa kisah dramatis dengan partisipasi peretas gipsi, buka CVE dan profesional, tetapi sedikit naif. Tentu saja, saya harus menghilangkan beberapa detail atau bahkan dengan sengaja memutarbalikkan, agar tidak mengecewakan pelanggan. Sebagian besar, ini bukan praktik dari pekerjaan saat ini di Technoserv, tetapi biarkan posting ini menjadi memo kecil tentang cara untuk tidak melakukannya, bahkan jika Anda benar-benar ingin.

Cara memagar server


Ada server di pusat data. Seperti sekolah kuno, besi, tanpa wadah mewah dan virtualisasi. Beberapa generasi karyawan yang lalu, salah satu pengembang mengkonfigurasinya "untuk sementara, sehingga hanya beberapa file besar untuk proyek yang diterima." Pada saat yang sama, perusahaan sangat memperhatikan keamanan informasi, tetapi, seperti yang sering terjadi, kolega dari IS pergi untuk memenuhi kebutuhan bisnis dan menyetujui opsi sementara dengan akses penuh ke Internet.

Untungnya, server berada di zona abu-abu DMZ dan tidak dapat terhubung langsung ke layanan kritis dari sirkuit internal. Port 22 ditetapkan, dan di dalam, mereka hanya menambahkan beberapa pengguna lokal dengan kata sandi individu untuk login melalui ssh / sftp. Akses dengan sertifikat dianggap terlalu merepotkan. Kemudian, pengembang dari proyek lain mulai berjalan dan diminta untuk membantu mengunggah unggahan reguler dari server pihak lawan, karena "Anda memiliki server yang nyaman dengan akses terkoordinasi ke jaringan". Kemudian lagi.

Hasilnya adalah situasi yang sangat ceria ketika server, sepertinya hanya sementara, tidak menerima pembaruan apa pun, tetapi banyak proses bisnis sudah terikat padanya dan beberapa terabyte data dipompa per bulan.

Kami memutuskan untuk memantaunya, karena server sangat penting, dan grafik CPU segera memiliki rak 100%. Mereka benar untuk mengatasinya: dan ada banyak proses rand atas nama uji pengguna yang mencurigakan dan banyak memori yang dikonsumsi oleh mereka, dan log memiliki kekuatan kasar terus menerus dari seluruh dunia.

Sebelum meletakkan server ke pelupaan, mereka menyodok tongkat pada proses: lsof segera menunjukkan file yang dihapus, tetapi tidak tertutup yang masih menggantung di RAM. Sayangnya, tidak mungkin untuk memahami apa yang sedang dilakukan penyerang, tetapi perilakunya lebih cenderung seperti seseorang daripada membuat naskah. Saat memeriksa skrip dalam RAM, sisipan seperti scanez clasa (memindai kelas) dalam bahasa Rumania sangat senang:

#!/bin/bash
while["1"];do
class="
#168
"
classb="`seq 1 255`"
classb2=($classb)
num_classb=${#classb2[*]}
b=${classb2[$((RANDOM%num_classb))]}
classc="`seq 1 255`"
classc2=($classc)
num_classc=${#classc2[*]}
c=${classc2[$((RANDOM%num_classc))]}
classes=($class)
num_class=${#classes[*]}
a=${classes[$((RANDOM%num_class))]}
echo "scanez clasa ${a}.${b}"
./a ${a}.${c}
done

Sejauh yang saya tahu, tidak ada yang serius bocor (atau mereka tidak memberi tahu saya tentang itu) dan penyerang tidak bisa masuk ke dalam perimeter internal, tetapi sejak itu perusahaan telah berbicara tentang peretas pencuri kuda gipsi.

aturan


  1. Jangan biarkan solusi sementara yang nyaman, tetapi tidak aman diperbaiki di infrastruktur. Ya, saya tahu mereka tidak konsisten, tetapi hanya bertahan karantina, tetapi hanya setuju ketika Anda akan menghapusnya. Setelah berapa hari atau jam. Dan bersihkan tanpa penundaan. Yah, setidaknya katakan itu pada yang lain. Bagaimanapun, layanan yang terbuka mulai pecah dalam rata-rata 20 menit.
  2. Jangan menunjukkan ssh dan RDP murni ke luar, lebih baik menyediakan akses melalui VPN atau layanan tunneling web. Saya tidak tahu mengapa, tetapi bagi mereka, orang lebih bertanggung jawab untuk set akun yang diizinkan dan kata sandi mereka.
  3. ssh — . . ssh, .
  4. - — - fail2ban, , - . «» «». , . , , , — .
  5. , : « ?» .
  6. . . , , .

IP – , firewall !


Saya benar-benar mengerti bahwa NAT adalah penopang yang diperlukan yang merusak kehidupan pengembang dan tidak memungkinkan opsi implementasi untuk dengan cepat menghubungkan node satu sama lain. Namun demikian, efek sampingnya menyembunyikan struktur internal jaringan sangat berguna dalam hal menyulitkan serangan otomatis biasa. Dan ya, saya mengerti betul bahwa opsi yang paling benar adalah dengan menggunakan firewall yang masuk daftar putih untuk secara eksplisit mengizinkan hanya koneksi yang diperlukan. Masalahnya adalah bahwa di dunia aggaila terus menerus pada hal-hal sepele seperti konfigurasi hard firewall atau Allah melarang SELinux tidak pernah punya waktu dan anggaran. Secara umum, mereka mengganggu debugging, mengurangi indikator kritis time-to-market dan tidak memungkinkan pengembang dan pengembang untuk hidup dalam damai.

Situasi menjadi lebih menarik ketika infrastruktur cloud, yang digunakan secara otomatis berdasarkan permintaan, menjadi standar industri. Faktanya adalah bahwa sebagian besar solusi cloud mengasumsikan bahwa perlindungan tumpukan kontainer yang terangkat dan mesin virtual terletak pada pengguna akhir. Sebagai aturan, mereka memberi Anda infrastruktur, mereka mengalokasikan alamat IP putih dan itu semua, pada dasarnya, mereka menyediakan serangkaian kemampuan, bukan solusi yang siap pakai. Secara default, semuanya tertutup, tetapi tidak nyaman dan karenanya mencegah pengembangan. Karena itu, mari kita buka semuanya dan kita akan dengan tenang mengujinya, tetapi pada produksi kita akan melakukannya dengan benar.

Seringkali ini mengarah pada kasus lucu. Saya menyaksikan satu salinan server MMORPG yang sedikit bajakan. Klan, donat, diskusi terus-menerus tentang ibu satu sama lain dan kesenangan lainnya. Semua orang bertanya-tanya mengapa beberapa karakter dipompa begitu cepat, dan umumnya mahakuasa. Saya menjalankan nmap melalui berbagai alamat yang paling dekat dengan server game.

Ternyata seluruh infrastruktur, termasuk frontend, backend, dan basis data, hanya menjebol port terbuka ke dunia luar. Dan apa kata sandi yang paling mungkin untuk pengguna jika database dapat diakses di seluruh Internet? Itu benar, sa juga! Akibatnya, hal yang paling sulit adalah mencari tahu struktur tabel.

Kisah serupa terjadi dengan satu pelanggan yang membuka akses jarak jauh ke panel admin untuk mesin di rumah saat bekerja dari rumah untuk sementara waktu. Secara alami, panel admin tanpa otorisasi, karena dianggap sebagai sumber daya internal yang aman. Dan pelanggan tidak repot dan langsung membuka port untuk seluruh Internet.

Dan server ELK terbuka untuk dunia muncul setiap minggu. Apa yang tidak ditemukan dalam isinya. Mulai dari data pribadi, diakhiri dengan nomor kartu kredit.

aturan


  1. Firewall harus masuk daftar putih. Dalam hal apapun, backend tidak dapat diakses dari luar. Dan jangan ragu untuk bertanya kepada kontraktor dan karyawan jarak jauh dari IP mana mereka akan terhubung. Pada akhirnya, biaya IP khusus sekitar 150 r / bulan. Ini adalah pemborosan yang layak untuk kesempatan bekerja dari rumah.
  2. Selalu gunakan HTTPS dan autentikasi penuh, meskipun itu hanya mesin uji.
  3. Pisahkan pengujian dan lingkungan produktif secara ketat. Tidak pernah, tidak pernah sama sekali, menggunakan akun yang sama di kedua lingkungan.

Samba


Terutama sering saya senang dengan server Samba, yang secara tradisional digunakan untuk mengatur akses bersama ke sumber daya. Mengapa tidak mengatur akses tamu untuk kolega dari departemen tetangga untuk bertukar file dengan mudah?

Dalam sebuah perusahaan kecil, semuanya berjalan dengan baik sampai tidak ada lagi departemen. Setelah beberapa waktu, diperlukan untuk mengkonfigurasi akses ke cabang jarak jauh. Dan solusi yang sepenuhnya "masuk akal" adalah membuka akses ke samba dari luar. Nah, setiap orang memiliki kata sandi sendiri, apa yang salah? Tidak ada yang ingat tentang akses tamu sampai ternyata bagian nyata dari HDD tersumbat dengan data orang lain. Pemindai otomatis dengan cepat menemukan penyimpanan file gratis, dan HDD mulai menyumbat dengan cepat dengan arsip orang lain yang dienkripsi. Dan di salah satu direktori, kami menemukan selama audit koleksi film yang dipilih untuk orang dewasa dengan partisipasi aktris 60+ (dan beruntung bahwa tidak 18-, kalau tidak, ia akan terbang dari lembaga penegak hukum).

temuan


  1. Jangan pernah berbagi penyimpanan tanpa VPN.
  2. samba ftp-. , .
  3. , , - .

,


Saya punya satu pelanggan yang tidak mengerti sama sekali mengapa dia perlu mengeluarkan jumlah tambahan untuk pencadangan jika semuanya berhasil untuknya. Ini mahal. Dan dia baik-baik saja. Akibatnya, karyawan yang membuka dan menjalankan segala sesuatu secara berurutan yang mereka kirim ke pos dengan aman menangkap virus enkripsi. Mereka kehilangan basis 1C dan dapat mengembalikannya hanya berkat arsip kertas dan satu kontraktor yang pernah menyalin pangkalan itu untuk dirinya sendiri.

Saya berbicara dengan pemimpin, menjelaskan poin-poin penting yang perlu diubah dalam perusahaan untuk menghilangkan risiko kehilangan pangkalan. Dia mengangguk sepanjang percakapan dan berakhir dengan kalimat indah: “Proyektil tidak mengenai lubang yang sama dua kali. Sekarang tidak ada yang perlu ditakutkan. " Dia kembali menolak cadangan dan secara alami kehilangan semua data dalam skenario yang sama enam bulan kemudian.

aturan


  1. , (- ). , .
  2. . - , .
  3. . . , helpdesk.

!


Dalam pengalaman saya, perusahaan kecil dan menengah biasanya memulai dengan manajemen akun pengguna sepenuhnya manual. Maksud saya, manajer penjualan yang baru menginjak ke dalam sarang admin berjanggut, di mana ia dengan sungguh-sungguh diberikan login, kata sandi dan akses. Semua ini bekerja dengan baik hingga perusahaan mulai tumbuh.

Inilah orang-orang yang menjual tank komposit. Mereka baru-baru ini mengubah kepemimpinan mereka dan diputuskan untuk melakukan audit keamanan penuh. Mereka bahkan membawa kami dalam tur untuk menunjukkan produksi. Tontonan sangat mengesankan: di bengkel besar, benda kerja besar diputar, di mana fiberglass terluka, sementara pekerja berlari dengan seember resin epoksi, dengan hati-hati mengoleskannya di atas benda kerja.

Di gedung terpisah mereka memiliki sayap administratif, di mana kami menguburkan diri secara langsung di organisasi bagian informasi produksi. Pada pandangan pertama, mereka telah mengatur skema yang cukup logis, ketika akses ke database pelanggan diberikan hanya melalui akun internal pada AD dengan persetujuan kepala. Ketika seseorang keluar, dia berlari melalui daftar periksa, menyerahkan peralatan, kartu, dan akun itu dinonaktifkan. Semua ini dilakukan secara manual, karena dana untuk manajemen Identitas penuh tidak dialokasikan.

Dalam proses audit, kami menemukan bahwa mereka telah menerapkan portal samopisny bertahun-tahun yang lalu sehingga tenaga penjualan dapat menerima data yang mereka butuhkan dari pelanggan dari jarak jauh. Mereka bahkan mulai memindahkan infrastruktur mereka ke cloud, tetapi pada akhirnya mereka berhenti di tengah jalan karena beberapa kesulitan internal. Selain itu, AD tidak dapat diintegrasikan di sana dan akun dihapus persis sama pada daftar centang setelah pemberhentian. Semuanya tampak normal, tetapi dalam log kami menemukan akun aktif dari Vasily tertentu, yang dipecat beberapa tahun yang lalu dan sekarang telah berhasil bekerja di perusahaan pesaing. Selain itu, dilihat dari log, ia menurunkan hampir seluruh basis klien setidaknya sebulan sekali.

Akun itu segera diblokir dan mereka mulai memperhatikan bagaimana seseorang dapat menghindari peraturan internal. Ternyata Vasily pertama-tama mendapatkan akses ke portal sebagai manajer penjualan, dan kemudian dipindahkan ke posisi manajerial langsung di bengkel, setelah itu ia berhenti. Tetapi daftar untuk pemecatan di bengkel benar-benar berbeda dan penonaktifan akun dari portal tidak terdaftar di sana. Meskipun, tampaknya, membuat daftar periksa umum untuk kontrol akses di semua sistem dan masalahnya bisa dihindari.

aturan


  1. Jika Anda memiliki lebih dari 100 karyawan, pertimbangkan untuk memperkenalkan sistem IDM lengkap.
  2. Singkirkan data bukan dari lembar bypass, tetapi langsung dari departemen personalia. PHK berbeda dan solusinya mungkin tidak membawa Anda.
  3. — . . , « , », , ( , , . .).
  4. « », - .
  5. . .
  6. . , — . .

?


Untuk beberapa alasan, keamanan informasi secara tradisional dianggap sebagai individu yang tidak ramah yang mengejar setiap orang dengan peraturan mereka yang membosankan dan mengganggu pekerjaan mereka. Bahkan, untuk semua contoh aneh di atas, mereka cukup sering ditemukan dalam kasus nyata, dan itu adalah penjaga keamanan dan admin paranoid yang membantu menghindarinya.

Coba saja temukan bahasa yang sama. Pertama-tama, karyawan IS sendiri tidak boleh menjadi penjaga yang hanya terlibat dalam membuat otak suatu kebijakan kata sandi reguler tanpa penjelasan. Pendekatan yang tepat adalah bertemu dengan pengembang dan pengembang, terjun ke masalah mereka. Kemudian kembangkan opsi kompromi yang tepat, yang tidak hanya tidak akan bersinar dengan akses tanpa kata sandi ke dunia luar, tetapi juga akan nyaman untuk digunakan.

Dan para biarawan terkadang ingin menjadi paranoid kecil.
Teks itu disiapkan oleh Vladimir Chikin, Kepala Teknologi Informasi di Technoserv Cloud .

More articles:


All Articles