ภัยคุกคามความปลอดภัยใดที่บัญชี SA และชื่อบัญชีที่รู้จักอื่น ๆ ก่อให้เกิดความปลอดภัย?

ชื่อบัญชีที่รู้จักเช่น sa ก่อให้เกิดภัยคุกคามด้านความปลอดภัยต่อฐานข้อมูลหรือไม่? เมื่อใช้การรับรองความถูกต้องของ windows บน SQL Server มันกำหนดนโยบายรหัสผ่านเดียวกัน (หากถูกตั้งให้พูดการล็อคบัญชีหลังจาก 5 ครั้ง)

ชื่อบัญชีที่รู้จักเช่น sa ก่อให้เกิดภัยคุกคามด้านความปลอดภัยต่อฐานข้อมูลหรือไม่?

บัญชีผู้ใช้ "god" ที่มีชื่อที่รู้จักนั้นโดยทั่วไปถือว่าเป็นความคิดที่แย่กว่าผู้ใช้ god ที่มีชื่อที่รู้จักน้อยกว่า มันทำให้การโจมตีแบบเดรัจฉานบังคับได้ง่ายกว่าเล็กน้อยเนื่องจากผู้โจมตีจะต้องเดารหัสผ่านไม่ใช่ชื่อผู้ใช้และรหัสผ่าน

ยังมีผู้ใช้เทพอยู่ดีอาจเป็นอันตรายได้ โดยทั่วไปคุณจะดีกว่าการมีผู้ใช้เฉพาะที่มีสิทธิ์เฉพาะสำหรับสิ่งที่พวกเขาต้องทำ การรักษาความปลอดภัยตามสิทธิพิเศษประเภทนี้ง่ายต่อการติดตั้งตั้งแต่เริ่มต้นมากกว่าการติดตั้งเพิ่มเติมในสภาพแวดล้อมของคุณในภายหลัง

การปิดใช้งาน sa และการให้สิทธิ์ผู้ดูแลระบบเฉพาะผู้ใช้ตามที่ต้องการใน SQL Server นั้นเป็นคำแนะนำเดียวกับการปิดใช้งานrootและส่งมอบสิทธิ์ผู้ดูแลระบบตามที่ต้องการผ่านsudoLinux และที่คล้ายคลึงกัน คุณสามารถเปิดใช้งานsaอีกครั้งเมื่อเชื่อมต่อกับเครื่องโดยตรงด้วยสิทธิ์ที่เพียงพอในกรณีที่มีอะไรผิดพลาดและคุณจะต้องลดสิทธิ์ทั้งหมดที่ผู้ใช้งานต้องการ (และแก้ไขปัญหา) เช่นเดียวกับที่คุณสามารถควบคุมการเข้าถึงรูท Linux ช่องถ้าคุณมีการเข้าถึงกล่อง - ดังนั้นการปิดใช้งานบัญชีจะไม่มีกระสุนวิเศษ (แต่เมื่อผู้โจมตีมีการเข้าถึงเครื่องของคุณหรือการเข้าถึงระดับผู้ดูแลระบบอย่างเต็มรูปแบบผ่าน RDC หรือ SSH การเดิมพันทั้งหมดจะปิดอยู่)

เมื่อใช้การรับรองความถูกต้องของ windows บน SQL Server มันกำหนดนโยบายรหัสผ่านเดียวกัน (หากถูกตั้งให้พูดการล็อคบัญชีหลังจาก 5 ครั้ง)

เมื่อใช้ Windows เซิร์ฟเวอร์การพิสูจน์ตัวจริงแบบรวมของ SQL จะไม่มีการควบคุมการล็อกบัญชีและเป็นเพียงการจับคู่ผู้ใช้ Windows กับผู้ใช้ SQL และขอให้ระบบปฏิบัติการรับรองข้อเท็จจริงว่าผู้ใช้ได้ให้ข้อมูลรับรองที่เหมาะสม สำหรับผู้ใช้ที่มีปฏิสัมพันธ์กับมนุษย์นี่หมายถึงการล็อคใด ๆ จะเกิดขึ้นเมื่อผู้ใช้พยายามพิสูจน์ตัวตนกับ Windows ไม่ใช่เมื่อเข้าสู่ระบบ SQL Server

ไม่ใช่ความคิดที่ดีที่จะทำให้ผู้ใช้ที่เป็นผู้ดูแลระบบเริ่มต้น (admin / root / postgres / sa / ฯลฯ ) ไม่มีอยู่จริงในระบบของคุณ คุณสามารถสร้างบัญชีพิเศษได้ตลอดเวลาภายใต้ชื่ออื่น

หากไม่มีสิ่งอื่นใดผู้ที่พยายามใช้ประโยชน์จากระบบของคุณไม่มีเวลาพอ ๆ กับที่ว่าพวกเขากำลังทำงานตาบอด (เช่นการฉีด sql โดยไม่ต้องมีเชลล์แบบโต้ตอบหรือไม่สามารถเห็นเอาต์พุตโดยตรงจากคำสั่งของพวกเขา)

สำหรับการล็อคบัญชี - ถ้ามีคนจัดการได้มากพอที่จะสามารถเข้าสู่เครื่องของคุณได้เว้นแต่ว่าคุณอนุญาตให้เข้าสู่ระบบโดยตรงจากผู้ใช้โดยเฉพาะคุณได้สูญเสียการต่อสู้ไปแล้ว โดยส่วนตัวแล้วฉันไม่ชอบการล็อคเอาท์ส่วนใหญ่เพราะมันทำให้ใครบางคนสามารถสร้างการปฏิเสธการบริการได้หากพวกเขาจัดการเพื่อรับชื่อผู้ใช้ของคุณ (และให้พวกเขาล็อคผู้ใช้ super? ไม่สนุก)

ฉันขอแนะนำให้ดูCIS Benchmarks ... พวกเขาไม่มีฐานข้อมูลทุกตัว แต่มีคำแนะนำสำหรับ Oracle, MS SQL, DB2 และ MySQL หากคุณกำลังใช้งานอย่างอื่นมันยังคงคุ้มค่าที่จะดูสิ่งต่าง ๆ ที่พวกเขาแนะนำ

ฉันไม่เห็นใครพูดถึงเรื่องนี้ดังนั้นฉันจะเพิ่ม ด้วย SQL Server 2005+ หากเซิร์ฟเวอร์ของคุณเป็นส่วนหนึ่งของโดเมนและโดเมนมีนโยบายรหัสผ่านคุณสามารถเปิดใช้งานนโยบายรหัสผ่านที่จะบังคับใช้ในการเข้าสู่ระบบ SQL ซึ่งรวมถึงข้อกำหนดด้านความซับซ้อนของรหัสผ่านและความสามารถในการบังคับให้เปลี่ยนรหัสผ่านเมื่อเข้าสู่ระบบ

โปรดทราบว่าในบางครั้งอาจทำให้เกิดปัญหากับตัวติดตั้งซอฟต์แวร์บางตัวที่ไม่ได้รับการอัพเดตให้ทำงานกับ SQL 2005+ และสร้างการเข้าสู่ระบบ SQL ด้วยรหัสผ่านที่ไม่ปลอดภัย

มีสองโหมดการรับรองความถูกต้องที่ใช้ใน SQL Server: การรับรองความถูกต้องของ Windows และโหมดผสม (เปิดใช้งานทั้งการรับรองความถูกต้อง Windows และการรับรองความถูกต้องของเซิร์ฟเวอร์ SQL)

โหมดแรกจะมีความเสี่ยงน้อยกว่าต่อการโจมตีแบบโหดเหี้ยมเนื่องจากผู้โจมตีมีแนวโน้มที่จะเข้าสู่การล็อคการเข้าสู่ระบบ (คุณลักษณะนโยบายการล็อคบัญชี) หลังจากพยายามทำการโจมตีในจำนวนที่ จำกัด ทุกสภาพแวดล้อมการผลิตหากใช้โหมดการรับรองความถูกต้องของ Windows ควรใช้คุณสมบัตินโยบายการล็อคเนื่องจากจะทำให้การโจมตีที่ดุร้ายไม่สามารถทำได้

เมื่อพูดถึงช่องโหว่การโจมตีแบบ Brute-Force การพิสูจน์ตัวตนของ SQL Server สถานการณ์จะไม่เอื้ออำนวย การพิสูจน์ตัวจริงของเซิร์ฟเวอร์ SQL ไม่มีคุณลักษณะที่อนุญาตให้ตรวจจับเมื่อระบบอยู่ภายใต้การโจมตีแบบ brute-force นอกจากนี้ SQL Server ยังตอบสนองได้ดีเมื่อต้องตรวจสอบความถูกต้องของข้อมูลรับรองความถูกต้องของ SQL Server มันสามารถจัดการกับความพยายามในการเข้าสู่ระบบที่ซ้ำซ้อนก้าวร้าวและไร้เดียงสาได้อย่างง่ายดาย ซึ่งหมายความว่าการรับรองความถูกต้องของเซิร์ฟเวอร์ SQL เป็นเป้าหมายที่สมบูรณ์แบบสำหรับการถอดรหัสรหัสผ่านจากการโจมตีแบบเดรัจฉาน

นอกจากนี้วิธีการบังคับกำลังพัฒนาด้วยการเข้ารหัสที่นำมาใช้ใหม่และวิธีการใช้รหัสผ่านที่ซับซ้อน ตัวอย่างเช่นผู้โจมตีที่ใช้ตารางสายรุ้ง (ตารางที่คำนวณล่วงหน้าสำหรับการย้อนกลับค่าแฮชการเข้ารหัสสำหรับชุดอักขระที่เป็นไปได้ทุกชุด) สามารถถอดรหัสรหัสผ่านที่แฮชได้อย่างง่ายดายและรวดเร็ว

เพื่อปกป้อง SQL Server ของคุณจากการโจมตีแบบ brute-force คุณควรพิจารณาสิ่งต่อไปนี้:

• อย่าใช้โหมดการรับรองความถูกต้องของเซิร์ฟเวอร์ SQL - บังคับให้ผู้โจมตีกดล็อคการเข้าสู่ระบบผ่านการรับรองความถูกต้องของ Windows
• ในกรณีที่คุณต้องใช้โหมดการพิสูจน์ตัวจริงของเซิร์ฟเวอร์ SQL ให้ปิดการใช้งานหรือลบการเข้าสู่ระบบ SA - วิธีที่ผู้โจมตีต้องเดาและจับคู่ทั้งชื่อผู้ใช้และรหัสผ่าน

บัญชี sa เมื่อเปิดใช้งานสามารถทำอะไรก็ได้บน SQL Server หากผู้โจมตีเข้าบัญชีนี้พวกเขาสามารถทำสิ่งใดก็ได้บนอินสแตนซ์ของ SQL Server (และอาจเป็นโฮสต์ระบบปฏิบัติการ) ที่พวกเขาต้องการ

SA (และชื่อบัญชีที่รู้จักกันดีอื่น ๆ ) เป็นจุดที่รู้จักกันดีที่แฮกเกอร์สามารถโจมตีได้ Oracle บางตัวมีการจัดทำเอกสารไม่ดีและรหัสผ่านเริ่มต้นจะไม่เปลี่ยนแปลงตลอดเวลา เมื่อคุณมีการควบคุมบัญชี SA ใน SQL Server แล้วคุณสามารถควบคุมเซิร์ฟเวอร์ที่กำลังทำงานอยู่และสามารถเรียกใช้รหัสใด ๆ หรือติดตั้งสิ่งใดก็ได้ที่คุณต้องการ ในวันคาวบอยของฉันฉันจำได้ว่าไม่ได้รับอนุญาต (มันต้องการเอกสารที่ฉันไม่ได้กรอก) เพื่อติดตั้งตัวควบคุม ActiveX บนเว็บเซิร์ฟเวอร์ที่โฮสต์ SQL Server ด้วยดังนั้นฉันจึงใช้ xp_cmdshell เพื่อคัดลอกและติดตั้งตัวควบคุม .