Apa ancaman keamanan yang ditimbulkan oleh akun SA dan nama akun lainnya yang diketahui terhadap keamanan?


10

Apakah nama akun yang dikenal seperti sa, menimbulkan ancaman keamanan ke basis data? Ketika menggunakan otentikasi windows pada SQL Server apakah itu memberlakukan kebijakan kata sandi yang sama (jika diatur untuk mengatakan penguncian akun setelah 5 kali)?


Bisakah Anda meningkatkan pertanyaan Anda? 1) Buat judul pertanyaan. 2) Bisakah Anda mempersempit ruang lingkup pertanyaan? Apakah Anda tertarik tentang serangan brutal, atau kerentanan akun yang diketahui. Apa daerah keamanan yang Anda tertarik?
Brian Ballsun-Stanton

Saya berbicara lebih banyak tentang ini dalam sebuah buku yang saya tulis yang seharusnya diterbitkan dalam waktu sekitar satu bulan. Saya menempatkan ini secara terpisah karena membeli buku itu bukan bagian dari jawabannya. amazon.com/Securing-SQL-Server-Protecting-Attackers/dp/…
mrdenny

@ Mrdenny, bisakah Anda memberi kami beberapa kutipan berguna dari buku ini? Mungkin membantu menjawab pertanyaan Anda, dan mengutipnya sebagai sumber cukup dapat diterima :)
Brian Ballsun-Stanton

@ Brian Saya harus memeriksa kontrak untuk melihat apakah saya bisa melakukan itu. Saya mungkin harus parafrase, tetapi saya akan melihat apa yang bisa saya lakukan.
mrdenny

Jawaban:


11

Apakah nama akun yang dikenal seperti sa, menimbulkan ancaman keamanan ke basis data?

Akun pengguna "dewa" dengan nama yang dikenal umumnya dianggap sebagai ide yang lebih buruk daripada pengguna dewa dengan nama yang kurang dikenal. Itu membuat serangan brute force sedikit lebih mudah karena penyerang hanya perlu menebak kata sandi dan bukan nama pengguna dan kata sandi.

Lagipula, memiliki pengguna dewa bisa berbahaya. Anda umumnya lebih baik memiliki pengguna tertentu dengan hak spesifik untuk apa yang perlu mereka lakukan. Jenis keamanan berbasis hak istimewa ini lebih mudah diimplementasikan dari awal dibandingkan dengan retrofit ke lingkungan Anda nanti.

Menonaktifkan sa dan memberikan pengguna khusus hak admin khusus seperti yang diperlukan di SQL server pada dasarnya adalah rekomendasi yang sama dengan menonaktifkan rootdan membagikan hak admin sebagaimana diperlukan melalui sudoLinux dan sejenisnya. Anda selalu dapat mengaktifkan kembali sasetelah terhubung langsung ke mesin dengan hak istimewa yang memadai jika terjadi kesalahan dan pada akhirnya Anda menjatuhkan semua hak yang harus dioperasikan pengguna (dan memperbaiki masalah) sama seperti Anda dapat merekayasa akses root ke Linux kotak jika Anda memiliki akses fisik ke kotak - jadi menonaktifkan akun bukanlah peluru ajaib (tetapi begitu penyerang memiliki akses fisik ke mesin Anda, atau akses Administratif penuh melalui RDC atau SSH, semua taruhan tetap dibatalkan).

Ketika menggunakan otentikasi windows pada SQL Server apakah itu memberlakukan kebijakan kata sandi yang sama (jika diatur untuk mengatakan penguncian akun setelah 5 kali)?

Ketika menggunakan Windows Integrated Authentication SQL server tidak memiliki kontrol atas penguncian akun dan semacamnya - itu hanya memetakan pengguna Windows ke pengguna SQL dan meminta OS untuk menjamin fakta bahwa pengguna telah memberikan kredensial yang sesuai. Untuk pengguna manusia interaktif ini berarti setiap penguncian akan terjadi ketika pengguna berusaha untuk mengotentikasi dengan Windows, bukan saat mereka masuk ke SQL Server.


4

Bukan ide yang buruk untuk membuatnya sehingga pengguna admin default (admin / root / postgres / sa / etc) tidak benar-benar ada di sistem Anda. Anda selalu dapat membuat akun istimewa dengan nama yang berbeda.

Jika tidak ada yang lain, orang yang mencoba mengeksploitasi sistem Anda tidak memiliki waktu yang mudah seperti jika mereka bekerja buta (misalnya, injeksi sql tanpa memiliki shell interaktif atau tidak dapat melihat output langsung dari perintah mereka)

Adapun penguncian akun - jika seseorang berhasil cukup jauh untuk dapat mencoba masuk ke mesin Anda, kecuali jika Anda secara khusus mengizinkan masuk langsung dari pengguna, Anda telah kalah dalam pertempuran. Secara pribadi, saya tidak mendukung lockout untuk sebagian besar, karena memberikan seseorang kemampuan untuk membuat penolakan layanan jika mereka berhasil mendapatkan nama pengguna Anda. (dan membuat mereka mengunci pengguna super? tidak menyenangkan).

Saya akan merekomendasikan untuk melihat CIS Benchmarks ... mereka tidak memilikinya untuk setiap database, tetapi mereka memiliki rekomendasi untuk Oracle, MS SQL, DB2 dan MySQL. Jika Anda menjalankan sesuatu yang lain, ada baiknya mencari hal-hal umum yang mereka rekomendasikan.


4

Saya tidak melihat orang lain menyebutkan ini, jadi saya akan menambahkannya. Dengan SQL Server 2005+ jika server Anda adalah bagian dari suatu domain dan domain tersebut memiliki kebijakan kata sandi, Anda dapat mengaktifkan kebijakan kata sandi untuk ditegakkan pada login SQL. Ini termasuk persyaratan kompleksitas kata sandi dan kemampuan untuk memaksakan perubahan kata sandi saat login.

Perhatikan bahwa ini kadang-kadang dapat menyebabkan masalah dengan beberapa penginstal perangkat lunak yang belum diperbarui untuk bekerja dengan SQL 2005+ dan membuat SQL login dengan kata sandi tidak aman.


3

Ada dua mode otentikasi yang digunakan dalam SQL Server: otentikasi Windows dan mode campuran (memungkinkan otentikasi Windows dan otentikasi SQL Server)

Mode pertama kurang rentan terhadap serangan brute-force karena penyerang kemungkinan akan mengalami lockout login (fitur Kebijakan Penguncian Akun) setelah sejumlah upaya serangan yang terbatas. Setiap lingkungan produksi, jika menggunakan mode Otentikasi Windows, harus menggunakan fitur kebijakan penguncian, karena membuat serangan brute-force menjadi mustahil

Ketika datang ke kerentanan serangan brute-force otentikasi SQL Server, situasinya tidak begitu menguntungkan. Otentikasi SQL Server tidak memiliki fitur yang memungkinkan mendeteksi ketika sistem berada di bawah serangan brute-force. Selain itu, SQL Server sangat responsif ketika memvalidasi kredensial otentikasi SQL Server. Itu dapat dengan mudah menangani upaya login berulang, agresif, brute-force tanpa kinerja keseluruhan negatif yang mungkin menunjukkan serangan tersebut. Ini berarti bahwa SQL Server Authentication adalah target yang sempurna untuk pemecahan kata sandi melalui serangan brute-force

Juga, metode brute-force berkembang dengan setiap metode enkripsi dan kompleksitas kata sandi yang baru diperkenalkan. Misalnya, penyerang yang menggunakan tabel pelangi (tabel yang dihitung sebelumnya untuk membalikkan nilai hash kriptografis untuk setiap kombinasi karakter yang mungkin) dapat dengan mudah dan cepat memecahkan kata sandi hash apa pun

Untuk melindungi SQL Server Anda dari serangan brute-force, Anda harus mempertimbangkan hal berikut:

  • Jangan gunakan mode Autentikasi SQL Server - paksa penyerang untuk menekan kunci masuk login melalui Otentikasi Windows
  • Jika Anda perlu menggunakan mode Otentikasi SQL Server, nonaktifkan atau hapus login SA - dengan begitu penyerang harus menebak dan memasangkan nama pengguna dan kata sandi

1

Akun sa, ketika diaktifkan dapat melakukan apa saja di SQL Server. Jika penyerang masuk ke akun ini mereka bisa melakukan apa saja pada contoh SQL Server (dan mungkin OS host) yang mereka inginkan.


1

SA (dan nama akun terkenal lainnya) adalah poin terkenal yang dapat diserang peretas. Beberapa yang Oracle didokumentasikan dengan buruk dan dengan demikian kata sandi default tidak selalu berubah. Setelah Anda memiliki kendali atas akun SA di SQL Server, Anda mengontrol server yang sedang berjalan dan dapat menjalankan kode apa pun atau menginstal apa pun yang Anda inginkan. Pada hari-hari koboi saya, saya ingat tidak diizinkan (diperlukan dokumen yang tidak akan saya isi) untuk menginstal kontrol ActiveX pada server web yang juga hosting SQL Server - jadi saya menggunakan xp_cmdshell untuk menyalin dan menginstal kontrol .


1
Kata sandi Oracle SYS default adalah change_on_install dan Anda akan terkejut betapa banyak orang yang tidak melakukannya!
Gayus
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.