เมื่อเร็ว ๆ นี้ (แต่มันก็เป็นคำถามที่เกิดขึ้นอีก) เราเห็นหัวข้อที่น่าสนใจ 3 ข้อเกี่ยวกับการแฮ็กและความปลอดภัย:

ฉันจะจัดการกับเซิร์ฟเวอร์ที่ถูกบุกรุกได้อย่างไร .
การค้นหาวิธีที่เซิร์ฟเวอร์แฮ็กถูกแฮ็ก
คำถามการอนุญาตให้ใช้ไฟล์

อันสุดท้ายไม่เกี่ยวข้องโดยตรง แต่เน้นว่าการจัดการกับเว็บเซิร์ฟเวอร์ทำได้ง่ายเพียงใด

เนื่องจากมีหลายสิ่งที่สามารถทำได้ก่อนที่จะมีสิ่งเลวร้ายเกิดขึ้นฉันต้องการให้คำแนะนำของคุณในแง่ของแนวปฏิบัติที่ดีเพื่อ จำกัด ผลกระทบด้านหลังของการโจมตีและวิธีการตอบสนองในกรณีที่น่าเศร้าจะเกิดขึ้น

มันไม่ได้เป็นเพียงเรื่องของการรักษาความปลอดภัยเซิร์ฟเวอร์และรหัส แต่ยังรวมถึงการตรวจสอบบันทึกและตอบโต้มาตรการ

คุณมีรายการแนวปฏิบัติที่ดีหรือคุณต้องการพึ่งพาซอฟต์แวร์หรือผู้เชี่ยวชาญที่วิเคราะห์เว็บเซิร์ฟเวอร์ของคุณอย่างต่อเนื่อง (หรืออะไรเลย)?

ถ้าใช่คุณสามารถแบ่งปันรายการและความคิด / ความคิดเห็นของคุณได้หรือไม่?

UPDATE

ฉันได้รับข้อเสนอแนะที่ดีและน่าสนใจหลายประการ

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

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

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

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

เกี่ยวกับข้อมูลสื่อผู้มีอำนาจและคู่แข่ง

มีสองพื้นที่ขนาดใหญ่ที่จะมุ่งเน้น:

1. ทำให้ยากที่จะเข้า
2. การสร้างนโยบายและขั้นตอนเพื่อให้สามารถจัดการกับเหตุการณ์ที่เกิดขึ้นในจุดที่ 1 ได้อย่างสงบและมีประสิทธิภาพ

ทำให้ยากที่จะเข้า

นี่เป็นหัวข้อที่ซับซ้อนมากและส่วนมากจะเน้นไปที่การทำให้แน่ใจว่าคุณมีข้อมูลเพียงพอที่จะเข้าใจว่า WTF เกิดขึ้นจริงหรือไม่ สัญลักษณ์แสดงหัวข้อย่อยที่เป็นนามธรรมเพื่อความเรียบง่าย:

• เก็บบันทึก (ดูการจัดการเหตุการณ์ความปลอดภัยข้อมูล)
  • การอนุญาตใด ๆ พยายามทั้งที่ประสบความสำเร็จและล้มเหลวโดยเฉพาะอย่างยิ่งกับแหล่งข้อมูลที่สมบูรณ์
  • บันทึกการเข้าถึงของไฟร์วอลล์ (อาจต้องมีไฟร์วอลล์ต่อเซิร์ฟเวอร์หากมีการใช้งาน)
  • บันทึกการเข้าถึงเว็บเซิร์ฟเวอร์
  • บันทึกการพิสูจน์ตัวตนเซิร์ฟเวอร์ฐานข้อมูล
  • บันทึกการใช้งานเฉพาะแอปพลิเคชัน
  • หากเป็นไปได้ SIEM สามารถส่งการแจ้งเตือนในรูปแบบที่น่าสงสัย
• บังคับใช้การควบคุมการเข้าถึงที่เหมาะสม
  • ตรวจสอบให้แน่ใจว่ามีการตั้งค่าสิทธิ์อย่างถูกต้องทุกที่และหลีกเลี่ยง 'สิทธิที่ขี้เกียจ' ("โอ้แค่ให้ทุกคนอ่าน") ถ้าเป็นไปได้
  • การตรวจสอบเป็นระยะของ ACLs เพื่อให้แน่ใจว่ามีการปฏิบัติตามขั้นตอนจริงและขั้นตอนการแก้ไขปัญหาชั่วคราว ("ให้ทุกคนอ่านดูว่าทำงานได้หรือไม่") ถูกลบอย่างถูกต้องหลังจากการแก้ไขปัญหาเสร็จสิ้น
  • กฎการส่งผ่านไฟร์วอลล์ทั้งหมดจำเป็นต้องได้รับการพิสูจน์และตรวจสอบเป็นระยะ
  • การควบคุมการเข้าถึงเว็บเซิร์ฟเวอร์จำเป็นต้องได้รับการตรวจสอบเช่นกันทั้งเว็บเซิร์ฟเวอร์และ ACL ของระบบไฟล์
• บังคับใช้การจัดการการเปลี่ยนแปลง
  • การเปลี่ยนแปลงใด ๆ ในสภาพแวดล้อมการรักษาความปลอดภัยจะต้องมีการติดตามและตรวจสอบจากส่วนกลางมากกว่าหนึ่งคน
  • แพทช์ควรรวมอยู่ในกระบวนการนี้
  • การมีบิลด์ OS ทั่วไป (เทมเพลต) จะทำให้สภาพแวดล้อมง่ายขึ้นและทำให้การเปลี่ยนแปลงง่ายขึ้นในการติดตามและนำไปใช้
• ปิดใช้งานบัญชีผู้เยี่ยมชม
• ตรวจสอบให้แน่ใจว่ารหัสผ่านทั้งหมดไม่ได้ถูกตั้งค่าเป็นค่าเริ่มต้น
  • แอปพลิเคชันที่ไม่ได้วางจำหน่ายอาจตั้งค่าผู้ใช้ด้วยรหัสผ่านที่กำหนดไว้ล่วงหน้า เปลี่ยนพวกเขา
  • เครื่องใช้ไอทีจำนวนมากมาพร้อมกับคู่ผู้ใช้ / รหัสผ่านที่เป็นที่รู้จักกันดี เปลี่ยนสิ่งเหล่านั้นแม้ว่าคุณจะเข้าสู่สิ่งนั้นเพียงปีละครั้ง
• ฝึกใช้สิทธิน้อยที่สุด ให้สิทธิ์การเข้าถึงแก่ผู้ใช้ที่พวกเขาต้องการ
  • สำหรับผู้ใช้งาน Admin การตั้งค่าสองบัญชีนั้นฉลาด บัญชีปกติหนึ่งบัญชีที่ใช้สำหรับงานอีเมลและสำนักงานอื่น ๆ และบัญชีที่สองสำหรับงานยกระดับส่วนตัว VM ทำให้การใช้งานง่ายขึ้นด้วย
  • อย่าสนับสนุนให้ใช้บัญชีผู้ดูแลระบบ / รูททั่วไปอย่างสม่ำเสมอเป็นการยากที่จะติดตามว่าใครทำอะไรเมื่อใด

การสร้างนโยบายและขั้นตอนเพื่อให้สามารถจัดการกับเหตุการณ์ที่เกิดขึ้นได้อย่างสงบและมีประสิทธิภาพ

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

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

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

องค์ประกอบบางส่วนของแผนการตอบสนองเหตุการณ์ใด ๆ :

• ระบุระบบที่ถูกบุกรุกและข้อมูลที่เปิดเผย
• พิจารณาก่อนว่าจะต้องมีหลักฐานทางกฎหมายหรือไม่สำหรับการดำเนินคดีในที่สุด
  • หากหลักฐานที่จะต้องเก็บไว้ไม่ได้สัมผัสอะไรเกี่ยวกับระบบที่เว้นแต่มีความจำเป็นอย่างยิ่งที่จะ อย่าเข้าสู่ระบบ อย่าลอดผ่านไฟล์บันทึก ทำ. ไม่. แตะ.
  • หากหลักฐานถูกเก็บรักษาไว้ระบบที่ถูกบุกรุกจำเป็นต้องถูกทิ้งไว้แบบออนไลน์แต่จะถูกตัดการเชื่อมต่อจนกว่าจะถึงเวลาที่ผู้เชี่ยวชาญนิติเวชคอมพิวเตอร์ที่ผ่านการรับรองสามารถผ่าระบบในลักษณะที่เข้ากันได้กับกฎการจัดการหลักฐาน
    • การปิดระบบที่ถูกบุกรุกอาจทำให้ข้อมูลมัวหมอง
    • หากระบบจัดเก็บข้อมูลของคุณอนุญาตให้ถ่ายภาพ LUN ที่ได้รับผลกระทบนี้ (อุปกรณ์ที่ไม่ต่อเนื่อง SAN) ก่อนที่จะตัดการเชื่อมต่อและตั้งค่าสถานะเป็นอ่านอย่างเดียว
  • กฎการจัดการหลักฐานมีความซับซ้อนและง่ายที่จะพลาด อย่าทำอย่างนั้นจนกว่าคุณจะได้รับการฝึกฝน SysAdmins ทั่วไปส่วนใหญ่ไม่มีการฝึกอบรมเช่นนี้
  • หากหลักฐานยังคงอยู่ให้สูญเสียการบริการเป็นความเสียหายจากการสูญเสียฮาร์ดแวร์และเริ่มกระบวนการกู้คืนด้วยฮาร์ดแวร์ใหม่
• กฎที่กำหนดไว้ล่วงหน้าสำหรับภัยพิบัติประเภทใดต้องมีการแจ้งล่วงหน้าประเภทใด กฎหมายและข้อบังคับแตกต่างกันไปตามท้องที่
  • กฎที่เกี่ยวข้องกับ 'การเปิดเผย' และ 'การประนีประนอมที่พิสูจน์แล้ว' นั้นแตกต่างกันไป
  • กฎการแจ้งเตือนจะกำหนดให้ฝ่ายสื่อสารต้องมีส่วนร่วม
  • หากการแจ้งที่ต้องการนั้นใหญ่เพียงพอการจัดการระดับสูงจะต้องมีส่วนร่วม
• การใช้ข้อมูล DR จะกำหนดเวลา "WTF ที่เพิ่งเกิดขึ้น" ได้ก่อนที่จะให้บริการกลับมาออนไลน์กลายเป็นลำดับความสำคัญที่สูงขึ้น
  • เวลาในการกู้คืนบริการอาจต้องใช้การหาว่าเกิดอะไรขึ้นกับผู้ใต้บังคับบัญชา ถ้าเป็นเช่นนั้นให้นำภาพไดรฟ์ของอุปกรณ์ที่ได้รับผลกระทบเพื่อแยกส่วนหลังจากบริการถูกเรียกคืน (นี่ไม่ใช่สำเนาที่เห็นได้ชัดสำหรับช่างเทคนิคที่จะทำวิศวกรรมย้อนกลับ)
  • วางแผนงานการกู้คืนบริการของคุณเพื่อรวมการสร้างใหม่ทั้งหมดของระบบที่ได้รับผลกระทบไม่ใช่แค่ทำความสะอาด
  • ในบางกรณีเวลาในการกู้คืนบริการจะแน่นพอที่จะต้องนำดิสก์อิมเมจออกทันทีหลังจากที่ระบุว่ามีการประนีประนอมเกิดขึ้นและหลักฐานทางกฎหมายจะไม่ถูกเก็บไว้ เมื่อบริการถูกสร้างใหม่งานการค้นหาสิ่งที่เกิดขึ้นสามารถเริ่มต้นได้
• ลอดผ่าน logfiles เพื่อดูข้อมูลเกี่ยวกับวิธีที่ผู้โจมตีเข้ามาและสิ่งที่พวกเขาอาจทำในครั้งเดียว
• กรองไฟล์ที่มีการเปลี่ยนแปลงเพื่อดูข้อมูลที่เกี่ยวข้องกับวิธีการที่พวกเขาเข้าไปและสิ่งที่พวกเขาทำเมื่อพวกเขาเข้ามา
• ลอดผ่านไฟร์วอลล์บันทึกสำหรับข้อมูลเกี่ยวกับที่มาจากที่พวกเขาอาจส่งข้อมูลไปและจำนวนของมันอาจถูกส่ง

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

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

วิธีช่วยเหลือที่เหมาะสมจะช่วยได้อย่างไร

เราต้องพิจารณาว่าลูกค้าจะจัดการกับที่นี่ได้อย่างไร (สิ่งนี้ใช้ได้กับลูกค้าทั้งภายในและภายนอกที่ติดต่อฝ่ายช่วยเหลือ)

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

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

1. ลองและโพสต์การอัปเดตที่สมจริงให้กับลูกค้าและทำงานร่วมกับพวกเขาเพื่อกำหนดความเร่งด่วนในการนำบริการกลับมาออนไลน์ การตระหนักถึงความต้องการของลูกค้าเป็นสิ่งสำคัญ แต่ในขณะเดียวกันก็ไม่อนุญาตให้พวกเขากำหนดตารางเวลาที่ไม่สามารถทำงานให้คุณได้
2. ตรวจสอบให้แน่ใจว่าทีมช่วยเหลือของคุณทราบว่าข้อมูลใดบ้างที่สามารถและไม่สามารถเผยแพร่ได้และพวกเขาไม่ควรสนับสนุนข่าวลือและการเก็งกำไร
3. สิ่งหนึ่งที่ผู้ช่วยควรทำคือบันทึกการโทรทั้งหมดที่เกี่ยวข้องกับการบุกรุก - สิ่งนี้สามารถช่วยวัดการหยุดชะงักที่เกิดจากการบุกรุกและกระบวนการที่ตามมาเพื่อจัดการกับมัน การใส่ทั้งเวลาและค่าใช้จ่ายทางการเงินในการบุกรุกและการลดผลกระทบจะมีประโยชน์มากทั้งกับการปรับกลยุทธ์ในอนาคตและเห็นได้ชัดว่าอาจเป็นประโยชน์กับการดำเนินการทางกฎหมาย การบันทึกเหตุการณ์ ITIL กับการบันทึกปัญหาสามารถช่วยได้ที่นี่ - ทั้งการบุกรุกเองและการบรรเทาสามารถบันทึกเป็นปัญหาแยกกันและผู้โทรแต่ละรายที่ถูกติดตามว่าเป็นปัญหาหนึ่งหรือทั้งสองปัญหา

มาตรฐานการปรับใช้สามารถช่วยได้อย่างไร

การปรับใช้กับเทมเพลตชุด (หรืออย่างน้อยรายการตรวจสอบ) ก็ช่วยได้เช่นกันพร้อมกับฝึกการควบคุม / จัดการการเปลี่ยนแปลงเกี่ยวกับการปรับแต่ง / อัปเกรดใด ๆ ให้เป็นเทมเพลตการปรับใช้ของคุณ คุณสามารถมีเทมเพลตหลายบัญชีสำหรับเซิร์ฟเวอร์ที่ทำงานต่าง ๆ (เช่นเทมเพลตเมลเซิร์ฟเวอร์, เทมเพลตเว็บเซิร์ฟเวอร์ ฯลฯ )

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

สิ่งนี้ช่วยได้หลายวิธี:

• ช่วยให้คุณสามารถกู้คืน / สร้างใหม่ได้เร็วขึ้นในกรณีที่มีการบุกรุกเกิดขึ้น (โปรดทราบว่าคุณไม่ควรปรับใช้จากแม่แบบนี้ 'ตามที่เป็น' เพราะคุณรู้ว่ามีความเสี่ยง แต่จะช่วยให้คุณกลับไปที่ " ซึ่งจำเป็นต้องได้รับการชุบแข็งเพิ่มเติมก่อนการปรับใช้จริง ... และอย่าลืมอัปเดตเทมเพลตการปรับใช้ของคุณเมื่อคุณแน่ใจว่าล็อคไว้อย่างถูกต้องแล้ว)
• ให้ "พื้นฐาน" แก่คุณเพื่อเปรียบเทียบเซิร์ฟเวอร์ที่ถูกแฮ็ก
• ลดข้อผิดพลาดที่ไม่จำเป็นซึ่งอาจนำไปสู่การบุกรุกในตอนแรก
• ช่วยในเรื่องการเปลี่ยนแปลงและการจัดการแพตช์เพราะเมื่อเห็นได้ชัดว่าคุณต้องการแพตช์ / อัพเกรดหรือการเปลี่ยนแปลงขั้นตอนเพื่อความปลอดภัย (หรือเหตุผลอื่น ๆ สำหรับเรื่องนั้น) ทำให้ง่ายต่อการดูว่าระบบต้องการการเปลี่ยนแปลงอย่างไร เพื่อดูว่ามีการใช้การเปลี่ยนแปลงอย่างถูกต้องหรือไม่ ฯลฯ )
• หากทุกอย่างสอดคล้องกันเท่าที่จะเป็นไปได้และมีเหตุผลมันจะช่วยให้เหตุการณ์ที่ผิดปกติและน่าสงสัยยื่นออกไปอีกเล็กน้อย

สำหรับเซิร์ฟเวอร์ส่วนใหญ่ของเราเราใช้ไฟร์วอลล์โฮสต์และเครือข่ายซอฟต์แวร์ต่อต้านไวรัส / สปายแวร์รหัสเครือข่ายและรหัสโฮสต์สำหรับการป้องกันส่วนใหญ่ของเรา พร้อมด้วยแนวทางทั่วไปทั้งหมดเช่นขั้นต่ำส่วนตัวถอนการติดตั้งโปรแกรมที่ไม่จำเป็นอัพเดต ฯลฯ จากนั้นเราใช้ผลิตภัณฑ์เช่น Nagios, Cacti และ SIEM solution สำหรับซับพื้นฐานและการแจ้งเตือนเมื่อมีเหตุการณ์เกิดขึ้น HIDS ของเรา (OSSEC) ทำการบันทึกประเภท SIEM จำนวนมากเช่นกันซึ่งถือว่าดี โดยทั่วไปเราพยายามที่จะบล็อกสิ่งต่าง ๆ ให้มากที่สุดเท่าที่จะเป็นไปได้ แต่จากนั้นเข้าสู่ระบบจากส่วนกลางดังนั้นหากมีสิ่งใดเกิดขึ้นเราสามารถวิเคราะห์และเชื่อมโยงมันได้

สิ่งที่คุณต้องการจริงๆสามารถล้มลงใน 3 พื้นที่พื้นฐาน:

1. การกำหนดค่าระบบมาตรฐาน
2. การตรวจสอบระบบ / แอพพลิเคชั่น
3. การตอบสนองต่อเหตุการณ์

หากคุณมีข้อมูลพนักงาน (ประกัน | ความปลอดภัย) ที่มีอยู่คุณควรพูดคุยกับพวกเขาอย่างแน่นอน ในขณะที่การตอบสนองเหตุการณ์มักจะเป็นขอบเขตของสำนักงานดังกล่าว แต่ส่วนที่เหลือควรเป็นความพยายามในการพัฒนาร่วมกันในทุกฝ่ายที่ได้รับผลกระทบ

ด้วยความเสี่ยงที่จะประเมินตนเองคำตอบสำหรับคำถามที่เกี่ยวข้องนี้ควรจัดทำดัชนีทรัพยากรที่มีประโยชน์มากมายสำหรับคุณ: เคล็ดลับสำหรับการรักษาความปลอดภัยเซิร์ฟเวอร์ LAMP

ตามหลักแล้วคุณควรมีระบบปฏิบัติการที่รองรับได้น้อยที่สุดและสร้างแต่ละระบบโดยใช้อิมเมจพื้นฐาน คุณควรเบี่ยงเบนจากฐานเท่าที่จำเป็นในการให้บริการสิ่งที่เซิร์ฟเวอร์ให้ ส่วนเบี่ยงเบนควรจัดทำเป็นเอกสารหรืออาจจำเป็นถ้าคุณต้องพบกับ PCI / HIPAA / etc หรือการปฏิบัติตามกฎหมายอื่น ๆ การใช้การปรับใช้และระบบการจัดการการกำหนดค่าสามารถช่วยได้มากในแง่นี้ ข้อมูลเฉพาะจะขึ้นอยู่กับ OS, cobbler / puppet / Altiris / DeployStudio / SCCM ของคุณเป็นต้น

คุณควรทำการตรวจสอบบันทึกอย่างสม่ำเสมอ หากเลือกตัวเลือก SIEM จะมีประโยชน์มากแต่ก็มีข้อเสียของการมีราคาแพงทั้งในราคาซื้อและค่าใช้จ่ายในการสร้าง ลองอ่านคำถามนี้จากเว็บไซต์ IT Security SE เพื่อรับความเห็นเกี่ยวกับการวิเคราะห์บันทึก: คุณจัดการการวิเคราะห์บันทึกได้อย่างไร? หากสิ่งนี้ยังหนักเกินไปแม้แต่เครื่องมือทั่วไปเช่น LogWatch ก็สามารถจัดเตรียมบริบทที่ดีสำหรับสิ่งที่เกิดขึ้น อย่างไรก็ตามสิ่งสำคัญคือเพียงสละเวลาเพื่อดูบันทึกทั้งหมด สิ่งนี้จะช่วยให้คุณคุ้นเคยกับสิ่งที่ถือเป็นพฤติกรรมปกติเพื่อให้คุณสามารถรับรู้สิ่งผิดปกติ

นอกเหนือจากการตรวจสอบบันทึกการตรวจสอบสถานะของเซิร์ฟเวอร์เป็นสิ่งที่สำคัญ การรู้ว่าการเปลี่ยนแปลงเกิดขึ้นเมื่อใดไม่ว่าจะวางแผนหรือไม่ก็ตาม การใช้เครื่องมือตรวจสอบในพื้นที่เช่นTripwireสามารถแจ้งเตือนผู้ดูแลระบบถึงการเปลี่ยนแปลง น่าเสียดายที่ SIEM และ IDSes มีข้อเสียของการปรับและ / หรือการซื้อ ยิ่งไปกว่านั้นหากไม่มีการปรับแต่งที่ดีเกณฑ์การแจ้งเตือนของคุณจะสูงมากจนข้อความที่ดีใด ๆ จะหายไปในเสียงรบกวนและไร้ประโยชน์

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

ฉันไม่ใช่ผู้เชี่ยวชาญด้านความปลอดภัยดังนั้นฉันจึงชอบพวกเขาเป็นหลัก แต่เริ่มจากPrincipal of Least Privilegeทำให้การทำงานง่ายขึ้นอย่างเห็นได้ชัด การใช้สิ่งนี้เช่นการรักษาด้วยยารักษาโรคทำงานได้ดีในหลาย ๆ ด้านของความปลอดภัย: การอนุญาตไฟล์ผู้ใช้รันไทม์กฎไฟร์วอลล์ ฯลฯKISSไม่เคยเจ็บอย่างใดอย่างหนึ่ง

โซลูชันส่วนใหญ่ที่กล่าวถึงที่นี่สามารถใช้งานได้ในระดับโฮสต์และเครือข่าย แต่เรามักจะลืมแอปพลิเคชันเว็บที่ไม่ปลอดภัย แอปพลิเคชันบนเว็บเป็นช่องโหว่ด้านความปลอดภัยที่พบได้บ่อยที่สุด ผู้โจมตีสามารถเข้าถึงฐานข้อมูลหรือโฮสต์ของคุณผ่านทางเว็บแอปพลิเคชัน ไม่มีไฟร์วอลล์ IDS ไฟร์วอลล์สามารถป้องกันคุณจากสิ่งเหล่านั้นได้ OWASP จัดทำรายการช่องโหว่ที่สำคัญที่สุด 10 อันดับแรกและเสนอการแก้ไขสำหรับช่องโหว่เหล่านั้น

http://www.scribd.com/doc/19982/OWASP-Web-Security-Guide