Get best of the week

Pembunuh VPN. Akses jarak jauh yang tepat ke server pertempuran

Pendapat yang diungkapkan dalam artikel ini adalah pendapat pribadi penulis. Dia menekankan bahwa itu mungkin tidak sesuai dengan pendapat atasannya, atasan dan departemen keamanan.

Salah satu hal paling keren di perusahaan kami dalam hal infrastruktur adalah bagaimana kami menerapkan akses jarak jauh. Ini hanya sihir super-mega-protected. Saya berbicara dengan banyak rekan penjaga keamanan dan auditor saya, dan sepertinya kami secara tidak sengaja menemukan cerita yang sama sekali baru dengan menggabungkan solusi komersial dan perangkat lunak kami. Jadi, saya pikir, akan menarik untuk menggali lebih dalam ke detail teknis tentang bagaimana industri ini bekerja dengan solusi akses jarak jauh yang sudah ketinggalan zaman dan bagaimana kami menerapkannya.

VPN orang baik tidak akan menyarankan


Saya akan mulai dengan pernyataan kuat: semua VPN adalah sampah .

VPN, seperti teknologi digital lainnya, dapat dikonfigurasi sehingga jika diretas, maka dunia tidak akan berakhir. Namun, tidak ada yang melakukan ini ... tetapi secara teoritis mereka bisa!

Dalam 99,95% kasus, VPN dikonfigurasi untuk:

  1. Membuat jembatan jaringan antara perangkat (laptop atau server lain)
  2. ... dan jaringan server yang lebih besar (misalnya, di cloud atau untuk on-prem )
  3. ... dan Internet, dilindungi oleh lapisan enkripsi tambahan



Ini bukan ide yang bagus. Bayangkan jika sebuah virus telah menetap di laptop Anda dan Anda terhubung melalui VPN ke jaringan server pertempuran? Dam Ta! Virus sekarang memiliki akses LAN ke produksi Anda. Apa yang ada di knalpot? Kesedihan. Banyak kesedihan.

Oke, anggap saja kasus virus ini tidak masuk akal. Tetapi bagaimana dengan fakta bahwa seorang hacker dapat menyusup ke dalam VPN itu sendiri, misalnya, menggunakan kerentanan di dalam perangkat atau perangkat lunak tempat VPN itu bekerja? Jadi, apakah Anda langsung masuk ke jaringan target? Ini adalah masalah serius, dan jauh dari berteori. Anda dapat membaca lebih lanjut di artikel tentang bagaimana Heartbleed digunakan untuk menangkap VPN menggunakan vektor serangan, yang saya peringatkan langsung di blog saya .

Belum lama ini, gelombang kerentanan VPN melanda seluruh dunia, yang segera digunakan oleh penjahat cyber untuk mendapatkan akses ke jaringan target. Tapi ini tidak mengejutkan, bukan? Sistem ini "melihat" langsung ke dalam Jaringan, tanpa ada mekanisme perlindungan lain di depannya. Perbaikan dan tambalan biasanya tidak diterapkan secara otomatis, dan melibatkan mekanisme kepemilikan yang dikendalikan oleh perangkat lunak berpemilik yang dijalankan pada OS berpemilik. Yah, semoga berhasil di sana.

Apakah sulit menemukan perangkat VPN ini? Sebelum menulis artikel ini, saya tidak pernah mencoba, jadi saya tidak tahu pasti. Sekitar setengah jam di Shodan.io dan tolong - beberapa hasil utama dari output:

  • Thomson Reuters adalah perusahaan senilai $ 41 miliar dengan 26.000 karyawan, setengahnya berasal dari jasa keuangan.
  • SAP Concur adalah layanan manajemen perjalanan, melanggar itu akan memberikan banyak data pribadi dan pembayaran dari semua jenis.
  • Asuransi Progresif - data pribadi dan informasi medis pribadi, ditambah dengan beberapa data pembayaran.
  • Chevron Phillips Chemical - namanya berbicara untuk dirinya sendiri.

Yah, ini mungkin tidak terlalu baik. Jika hal-hal ini sangat mudah ditemukan, sepertinya bukan solusi yang tepat untuk menempatkannya secara online. Apakah kita punya pilihan lain?

Tanpa kepercayaan


Zero Trust [secara harfiah: “zero trust”] - pada dasarnya, ini berarti Anda mengotorisasi setiap koneksi, dan jangan berasumsi bahwa beberapa dari mereka dapat dipercaya karena mereka sudah ada di dalam jaringan Anda. Jika Anda ingin lebih memahami istilah ini dan memikirkan kembali pendekatan Anda terhadap bisnis, baca artikel ini di Network World (maaf untuk PR lain yang tidak tahu malu).

Kami membeli solusi Okta Advanced Server Access (OASA) untuk memperkenalkan otorisasi Zero-Trust di server pertempuran.
OASA keren karena tiga alasan:

1. Ini hanya pembungkus seputar konfigurasi OpenSSH pada steroid


Di bawah tenda, platform OASA adalah penyebaran OpenSSH yang dikelola dengan baik (perintah ssh yang sama di konsol Anda). Dan OpenSSH adalah solusi administrasi jarak jauh yang sangat teruji dan aman. Omong-omong, sejak tahun 2003, OpenSSH tidak memiliki satu kerentanan yang dapat mengarah pada akses jarak jauh yang tidak sah dalam konfigurasi standar.
Titik masuk dalam skema ini adalah instance Amazon Linux 2. EC2 biasa. Dengan demikian, area serangan sangat kecil. Ingat: salah satu masalah utama dengan menggunakan VPN adalah konfigurasi perangkat lunak / OS milik yang mencegah patch otomatis. Kemampuan untuk memperbarui titik masuk jaringan kami bersama dengan infrastruktur lainnya merupakan kemenangan besar.

2. Tidak ada jembatan jaringan


Seperti yang saya sebutkan di atas, sebagian besar VPN dikonfigurasikan untuk membuat jembatan jaringan antara perangkat jaringan, seperti laptop, dan jaringan server di Internet. Salah satu tempat saya yang paling menyakitkan di VPN adalah mereka mencegat semua lalu lintas jaringan Anda. Anda dapat, tentu saja, mengkonfigurasi ulang untuk perilaku yang berbeda, tetapi klien kami dan protokol keamanan NIST 800-53 SC-7 (7) biasanya memerlukan hal itu.

Ini adalah contoh yang baik tentang bagaimana beberapa langkah keamanan jauh di belakang pengembangan industri. Di dunia jadul, VPN bisa menjadi satu-satunya lapisan untuk mengenkripsi lalu lintas. Kadang-kadang auditor percaya bahwa tanpa perlindungan VPN Anda akan mengirim data Anda melalui saluran yang tidak dienkripsi.

Untungnya ada cara yang lebih baik. Dalam model OASA, koneksi dibuat secara individual antara Anda dan server. Misalnya, dalam menanggapi permintaan "Saya ingin masuk ke EC2 misalnya i-028d62efa6f0b36b5", sistem Anda terhubung ke titik input jaringan, dan kemudian ke server target. OASA juga melindungi koneksi ini dengan mengeluarkan sertifikat klien sepuluh menit setelah verifikasi pertama data Anda melalui SSO , dan kemudian memverifikasi bahwa Anda menggunakan perangkat tepercaya yang dimaksudkan (dan dikonfirmasi).

Ada sedikit kebebasan untuk menjelajah jaring. Administrator dapat memasukkan titik entri jaringan dan meneruskan port ke tujuan lain, tetapi fitur ini dinonaktifkan secara default dan harus diminta secara eksplisit ketika membuat koneksi. Dan bagian terbaiknya adalah tidak ada yang mengharuskan saya untuk membawa semua lalu lintas melalui Virtual Private Cloud, karena ini tidak disebut "VPN".

3. Akses jaringan khusus dan IP acak


Titik masuk jaringan ini digunakan secara terpisah untuk setiap Cloud Pribadi Virtual (misalnya, satu untuk prod, satu untuk staging, satu untuk dev, dll.). Selain itu, masing-masing dipantau secara ketat oleh solusi keamanan kami, yang mencatat semua aktivitas dan menyaring lalu lintas. Jika cracker berada di dalam salah satu titik masuk, sesuatu juga tidak akan berhasil. Dalam situasi apa pun, skema keamanan kami tidak memungkinkan akses ke sumber daya yang dilindungi hanya karena Anda sudah berada di dalam Virtual Private Cloud.

Salah satu mekanisme pertahanan favorit saya muncul secara tidak sengaja. Ketika kami pertama kali mulai mengkonfigurasi titik masuk, masing-masing dikonfigurasi untuk alamat IP statis dari AWS. Cukup cepat, kami menemukan bahwa alamat IP ini kadang-kadang tidak terikat dengan instance EC2 pada waktu yang tepat, yang dapat menyebabkan konfigurasi diri OASA yang salah. Setelah mengalami kelezatan berbagai perbaikan dalam produksi, saya tidak tahan dan hanya menghapus seluruh cerita tentang IP statis - dan itu berhasil.



OASA hanya membutuhkan IP yang menghadap ke Internet, tidak harus diketahui sebelumnya. Ketika klien siap untuk membuat koneksi, sebuah GUID unik diminta, dengan bantuan yang IP ditentukan:

  • Pengguna: Saya ingin masuk untuk terhubung ke vpc-99f2acff
  • Aplikasi Klien OASA: Saya telah mendefinisikan vpc-99f2acff sebagai server yang dikenal dengan GUID 25af5d4f-e657-4583-b0bd-beb1ca4f0c1f
  • Server OASA: K 25af5d4f-e657-4583-b0bd-beb1ca4f0c1f dapat diakses di 3.22.198.24, berikut adalah sertifikat
  • Aplikasi klien OASA: Sertifikat diinstal, menghubungkan ke 3.22.198.24 melalui SSH ...

Ini berarti bahwa setiap instance dari infrastruktur entry point kami ( posting terpisah tentang hal itu menjadi perhatian Anda) hadir dengan satu set alamat IP yang sama sekali baru. Dengan demikian, peretas acak harus mencari satu IP di antara puluhan juta, dan jumlah mereka bertambah setiap hari. Sayangnya untuk mereka, pencarian ini benar-benar sia-sia, terima kasih kepada ...

Mengetuk port perusahaan


Mengetuk port [secara harfiah: mengetuk port] adalah hal yang, pada prinsipnya, tidak ada yang digunakan di dunia nyata, tetapi sangat menyenangkan untuk dikonfigurasikan. Singkatnya, port knocking adalah urutan "gundukan" ke berbagai port jaringan tertutup, dan jika urutannya diulang dengan benar, port "nyata" terbuka ke IP Anda. Elegan, tetapi tidak praktis dalam proyek besar nyata.
Saya terinspirasi oleh ide itu dan berpikir bagaimana meningkatkan ide itu. Jadi solusi yang saya sebut Enterprise Port Knocking lahir .

Saya ingin membuat mekanisme yang akan menjamin kedekatan titik masuk kami ke Internet, sampai seseorang dapat mengaksesnya. Mekanisme ini seharusnya mudah digunakan, andal, dan disahkan dengan cara yang sudah ada.
Saya membuat sketsa arsitektur mekanisme dan pergi bersamanya ke tim insinyur kami yang sangat berbakat. Beberapa minggu kemudian kami mulai.

Layanan ini cukup sederhana dan digunakan sebagai fungsi AWS Lambda, dengan akses ke sana melalui AWS API Gateway (kesenangan arsitektur tanpa server!) Untuk penggunaan yang mudah dan andal. Mekanisme kerjanya seperti ini:

  1. Pengguna berhasil diautentikasi melalui SSO.
  2. Aplikasi memintas akun AWS yang dikonfigurasi untuk mencari Kelompok Keamanan yang ditandai khusus (konsep AWS untuk aturan firewall)
  3. Aplikasi memperbarui Grup Keamanan, yang memungkinkan akses ke alamat IP pemohon. Aturan di Grup Keamanan juga menyimpan stempel waktu add.
  4. Tugas cron menghapus daftar IP yang diizinkan setiap periode waktu yang ditentukan.

Berkat situasi ini, kami sekarang menawarkan solusi akses jarak jauh yang sepenuhnya tertutup untuk Internet dan memerlukan otentikasi dua faktor melalui basis data pengguna kami sebelum membuka port di firewall .

Dan itu mudah!


Saya belum menyentuh betapa sederhananya mekanisme ini beroperasi. Saya tahu bahwa ada banyak komponen, tetapi bersama-sama mereka membuat otorisasi yang sangat sederhana:

  1. Masuk melalui SSO.
  2. Klik pada peluncuran Enterprise Port Knocking di portal SSO.
  3. Di terminal, menggunakan perintah SSH, tentukan tujuan sebagai ID dari instance EC2. Sistem OASA cukup pintar untuk mencari tahu titik masuk mana yang harus digunakan dan yang lainnya terjadi secara otomatis!



Seluruh sistem ini merupakan kemenangan besar bagi infrastruktur kami, untuk kepatuhan kami terhadap semua perjanjian keselamatan dan untuk keselamatan pelanggan kami. Pengguna sangat menyukai betapa mudahnya terhubung ke server kami, karena Anda tidak perlu melalui otentikasi tambahan atau ingat VPN mana yang harus digunakan. Dan saya sangat suka tidur tenang saya. Semua orang menang dari model baru!

Ya, kecuali para peretas, tentu saja.

More articles:


All Articles