การใช้งาน CPU "Peaky" บนตัวควบคุมโดเมน

เรามี Windows Server 2008 SP2 สองตัว (ไม่ใช่ 2008 R2 อย่างน่าเศร้า) ตัวควบคุมโดเมนในไคลเอนต์ขนาดเล็ก 150 โดเมนที่แสดงการใช้งาน CPU "ยอด" มาก ตัวควบคุมโดเมนทั้งคู่แสดงพฤติกรรมเดียวกันและโฮสต์บน vSphere 5.5.0, 1331820 ทุกสองหรือสามวินาทีที่การใช้งาน CPU กระโดดขึ้นสูงถึง 80-100% แล้วลดลงอย่างรวดเร็วยังคงอยู่ในระดับต่ำสำหรับหนึ่งหรือสองวินาทีแล้วกระโดดขึ้น อีกครั้ง

การดูข้อมูลประสิทธิภาพที่ผ่านมาของเครื่องเสมือนบ่งชี้ว่าสภาพนี้เกิดขึ้นอย่างน้อยหนึ่งปี แต่ความถี่เพิ่มขึ้นตั้งแต่เดือนมีนาคม

กระบวนการที่ละเมิดคือ SVChost.exe ซึ่งห่อลูกค้า DHCP (dhcpcsvc.dll), EventLog (wevtsvc.dll) และบริการ LMHOSTS (lmhsvc.dll) ฉันไม่แน่นอน internals ผู้เชี่ยวชาญของ Windows แต่ฉันไม่สามารถดูเหมือนจะพบสิ่งที่ผิดปกติโดยเฉพาะอย่างยิ่งเมื่อดูกระบวนการที่มี Process Explorer อื่น ๆ กว่าที่มันปรากฏ EventLog เรียกตันของRpcBindingUnbindโทร

ณ จุดนี้ฉันออกจากกาแฟและความคิด ฉันจะแก้ไขปัญหานี้ได้อย่างไร

TL; DR: ไฟล์ EventLog เต็มแล้ว การเขียนทับรายการนั้นมีราคาแพงและ / หรือมีการใช้งานไม่ดีใน Windows Server 2008

ที่@pk และ@joeqwertyข้อเสนอแนะและหลังจากถามไปรอบ ๆ ฉันตัดสินใจว่ามันเป็นไปได้มากที่สุดที่การใช้งานการตรวจสอบที่ถูกลืมนั้นกำลังคัดลอกบันทึกเหตุการณ์

ฉันติดตั้งการตรวจสอบเครือข่ายของ Microsoftบนหนึ่งใน Domain Controllers และเริ่มการกรองสำหรับ MSRPC โดยใช้ProtocolName == MSRPCตัวกรอง มีการรับส่งข้อมูลจำนวนมาก แต่ทั้งหมดอยู่ระหว่าง RODC ของไซต์ระยะไกลและน่าเสียดายที่ไม่ได้ใช้พอร์ตปลายทางเดียวกันกับกระบวนการรับฟัง EventLog ยี้! มีทฤษฎีดังกล่าว

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

SC config EventLog Type= own

จากนั้นฉันไปที่ProcMonและตั้งค่าตัวกรองเพื่อแยกทุกอย่างที่ไม่ได้ใช้ PID นั้น ฉันไม่เห็นตันของความพยายามที่ล้มเหลวโดย EventLog เปิดรีจิสทรีคีย์ที่ขาดหายไปตามที่ระบุเป็นสาเหตุที่เป็นไปได้ที่นี่ (เห็นได้ชัดว่าการใช้งานเส็งเคร็งสามารถลงทะเบียนเป็นแหล่งที่มาของกิจกรรมในรูปแบบที่น่าสงสารมาก) ฉันเห็นรายการ ReadFile ที่ประสบความสำเร็จมากมายของบันทึกเหตุการณ์ความปลอดภัย (C: \ Windows \ System32 \ WinEvt \ Logs \ Security.evtx)

นี่คือการดูสแต็คในหนึ่งในกิจกรรมเหล่านี้:

คุณจะสังเกตเห็น RPCBinding ก่อนแล้วจึง RPCBindingUnbind มีจำนวนมากเหล่านี้ เหมือนเป็นพันต่อวินาที ล็อกการรักษาความปลอดภัยไม่ว่างจริง ๆ หรือมีบางอย่างไม่ทำงานกับSecurity.evtxบันทึก

ใน EventViewer บันทึกการรักษาความปลอดภัยเป็นการบันทึกระหว่าง 50-100 เหตุการณ์ต่อนาทีเท่านั้นซึ่งดูเหมือนว่าเหมาะสมสำหรับโดเมนขนาดนี้ ยี้! มีทฤษฎีจำนวนที่สองที่เรามีแอปพลิเคชั่นบางอย่างที่มีการตรวจสอบเหตุการณ์ที่ละเอียดมากหันไปทางซ้ายในมุมที่ถูกลืม มีกิจกรรมที่บันทึกไว้จำนวนมาก (~ 250,000) แม้ว่าอัตรากิจกรรมที่บันทึกไว้ต่ำ ขนาดบันทึกอาจ?

ล็อกการรักษาความปลอดภัย - (คลิกขวา) - คุณสมบัติ ... และขนาดล็อกสูงสุดถูกตั้งค่าไว้ที่ 131,072 KB และขนาดล็อกปัจจุบันอยู่ที่ 131,072 KB ปุ่มตัวเลือก 'เขียนทับเหตุการณ์ตามต้องการ' ได้รับการตรวจสอบแล้ว ฉันคิดว่าการลบและการเขียนไฟล์บันทึกอย่างต่อเนื่องอาจเป็นงานที่ยากโดยเฉพาะอย่างยิ่งเมื่อมันเต็มดังนั้นฉันเลือกที่จะล้างบันทึก (ฉันบันทึกบันทึกเก่าในกรณีที่เราต้องการมันเพื่อตรวจสอบในภายหลัง) และให้บริการ EventLog สร้างขึ้น ไฟล์ว่างใหม่ ผลลัพธ์: การใช้งาน CPU กลับสู่ระดับสติประมาณ 5%

คุณอาจสามารถไล่ล่าสิ่งนี้ด้วยการสร้างชุดตัวเก็บรวบรวมข้อมูลขนาดเล็ก

• เปิดการตรวจสอบประสิทธิภาพและสร้างชุดตัวเก็บรวบรวมข้อมูลที่ผู้ใช้กำหนด
• เลือกด้วยตนเอง (ไม่มีเทมเพลต) และเลือกข้อมูลการติดตามเหตุการณ์เท่านั้น
• เพิ่มบริการโดเมน Active Directory:ข้อมูลหลักและบันทึกชุด
• เปลี่ยนเงื่อนไขการหยุดภายใต้คุณสมบัติเป็น 1 นาที
• เริ่มการตั้งค่าและรอ
• เมื่อเสร็จสิ้นให้แปลงไฟล์. etl ที่บันทึกไว้ไปเป็น. csvโดยใช้tracerpt –l “file.etl” –of CSV
• วิเคราะห์ข้อมูลsummary.csvและdumpfile.csvใน Excel คุณอาจต้องการดาวน์โหลดเอกสารนำเข้า -DC-Info.xlsm นี้เพื่อช่วยในการวิเคราะห์ของคุณ

หากลางสังหรณ์ของฉันถูกต้องคุณจะเห็นอุปกรณ์บางอย่าง (IP: พอร์ต) ตอกย้ำ DC ของคุณ

แน่นอนว่าเป็นเรื่องยาก นอกเหนือจากการทิ้งไว้คนเดียว (1 CPU / โหลด 50% .. ใครสนใจ?) คุณสามารถลองตั้งค่าตัวควบคุมโดเมนใหม่และดูหลังจากผ่านไปหลายวันถ้าสิ่งนี้ทำให้คุณมีพฤติกรรมแบบเดียวกัน ถ้าเป็นเช่นนั้นคุณอาจต้องการลองใช้การติดตามแบบ Wireshark (เห็นได้ชัดว่ามีบางอย่างในเครือข่ายที่ทำให้เกิดสิ่งนี้)

สิ่งต่อไปที่อยู่ในใจคือการเรียกไมโครซอฟท์อย่างง่าย

เทรวิส "เก็บถาวร" ไม่ได้ช่วยคุณ ในความเป็นจริงแม้แต่การล้างบันทึกเหตุการณ์เมื่อมันโตขึ้น 2 / 3rd ก็ไม่ได้ช่วยอะไรคุณ แต่ "เก็บถาวร" ช่วย KraigM

kce: ล้างไฟล์ "เขียนทับ" 131MB และเห็นประสิทธิภาพลดลงจากพูดว่า 55% o 5% แต่คำถาม: บางทีคุณอาจเห็นการใช้งานที่สูงอีกครั้งเนื่องจากอาจ (ก) ถูกทริกเกอร์เมื่อถึงสภาวะการเขียนทับหรือ (b) มันอาจแย่ลงเป็นลำดับเมื่อไฟล์ที่ลบเพิ่มขึ้นจากขนาด 0mb เป็นขนาด 131MB

บางคนเห็นสิ่งนี้สำหรับ security.evtx และบางคนเห็นมันสำหรับบันทึกการดำเนินงาน Task Scheduler ฉันแนะนำให้ถอนการติดตั้ง AV ของคุณอย่างสมบูรณ์ (คุณใช้อันไหน) และลอง ผู้บุกรุกต้องซ่อนแทร็กของตนและแทร็กของพวกเขาจะทำในงานที่กำหนดไว้ที่พวกเขาติดตั้ง ดังนั้นพวกเขาจะซ่อนแทร็กของพวกเขาโดยทำลายตัวจัดการในบันทึกเหตุการณ์เหล่านี้และเขียนใหม่เพื่อข้ามแทร็ก AV อาจตรวจจับสิ่งนี้ด้วยวิธีบั๊กกี้เพราะถ้าเป็น Microsoft จะมีการรายงานการใช้งานที่สูงกว่านี้มากขึ้น แต่ฉันเห็นเพียงไม่กี่โพสต์เมื่อ Googling ฉันยังเห็นสิ่งนี้บนเซิร์ฟเวอร์ 2008 R2 สำหรับบันทึก security.evtx ไม่มีสมาชิกบันทึกเหตุการณ์ไม่มีจอภาพภายนอก ฉันสังเกตการทำงานของ AV services (McAfee) สองอย่างและพวกเขามีการใช้งานโดยรวมต่ำมากสำหรับเซิร์ฟเวอร์หลายวันดังนั้นฉันจึงสงสัยว่ามันถูกถอนการติดตั้งและเพียงบางส่วนเท่านั้น (น่าจะเป็นความต้องการถอนการติดตั้งพิเศษของ McAfee) และฉันสงสัยว่า บริการ vestige (หรือที่ติดตั้งตามปกติ) บริการ McAfee หรือไดรเวอร์ตัวกรองตัวกรอง McAfee ที่ใช้งานอย่างใดอย่างหนึ่งเขียนปกติลงในบันทึกเหตุการณ์และตัดสินใจในการกรองของพวกเขาที่พวกเขาต้องการที่จะทำให้สิ่งนี้กลายเป็นการอ่านบันทึกเหตุการณ์ทั้งหมด เชื่อใจฉันไดรเวอร์ฟิลเตอร์ของบุคคลที่สามจาก บริษัท AV บางแห่งมีความบึกบึนและแน่นอนว่าคนขายตั๋ว 10,000 เท่ากว่าไมโครซอฟท์ที่ใช้งานการบันทึกเหตุการณ์ซึ่งน่าจะสมบูรณ์แบบมาก โดยสรุปการถอนการติดตั้ง 100% ของ av และดูว่าปัญหาของคุณจะแก้ไข ถ้าเป็นเช่นนั้นทำงานร่วมกับ บริษัท AV ของคุณเพื่อแก้ไข AV ไม่ควรทำข้อยกเว้นสำหรับไฟล์

นอกจากนี้เมื่อใช้ procmon ให้ใส่ใจกับการเรียก WriteFile เพราะ Writefile เป็นสิ่งที่จะทำให้ตัวจัดการตัวกรองอ่านไฟล์ทั้งหมด ในกรณีของฉันการอ่านเริ่มต้นประมาณ 30 วินาทีหลังจากการเขียนเสร็จซึ่งอาจเกิดจากการออกแบบ แต่มันก็สอดคล้องกันและในกรณีของฉันไฟล์คือ 4GB และไฟล์นั้นเกี่ยวข้องกับการอ่าน 64K Readfiles แต่ละ 64KB ยาวและมันใช้ 35% ของ CPU ในการทำสิ่งนี้ เศร้ามาก.

อัพเดท 03/23/2016 ฉันดูไดรเวอร์ตัวกรองในเครื่องนี้หลังจากสรุปสิ่งนี้ต้องเกิดจากหนึ่งในนั้น (กลไกบันทึกเหตุการณ์ไม่สามารถบั๊กได้ด้วยตัวเองหรือจำนวนรายงานประเภทนี้จะส่ายและ มันไม่ใช่). ฉันเห็นไดรเวอร์ตัวกรองบางตัวจาก AV และจาก บริษัท บุคคลที่สามที่รู้จักกันดีซึ่งช่วยเพิ่มประสิทธิภาพของดิสก์เครื่องเสมือนด้วยการมองไปข้างหน้าอ่านและถามหัวหน้าสถาปนิกของพวกเขา (ผู้ใจดีและมีน้ำใจ) หากผลิตภัณฑ์ของเขาอาจอ่านมากเกินไป บันทึกเหตุการณ์ความปลอดภัย (ซึ่งเกิดขึ้นอย่างชัดเจนต่อ procmon) สิ่งนี้จะเป็นประโยชน์สำหรับบันทึกการรักษาความปลอดภัยที่มีขนาดเล็กลง แต่ไม่ใช่ขนาดที่รายงานที่นี่ ไม่มีทางที่เขาจะพูด เขาตกลงว่าอาจเป็น AV

ดังที่ฉันพูดกับเพื่อน Azure ด้านล่างเราไม่มีการติดตามจากโปสเตอร์ต้นฉบับหากปัญหาปรากฏขึ้นอีกครั้งหลังจากการล้างบันทึกเหตุการณ์เนื่องจากเป็นวิธีการแก้ปัญหาทั่วไปและผิดพลาดเนื่องจากประสิทธิภาพลดลงเมื่อเวลาผ่านไปอีกครั้ง สิ่งนี้เรียกว่า "การติดตามผล" และฉันเห็นโดยตรงว่าคำตอบของผู้โพสต์ดั้งเดิมสามารถหลอกคนที่ไม่ติดตามให้เชื่อว่าพวกเขาแก้ไขปัญหาได้แล้ว ฉันเกือบถูกหลอกเช่นกัน ฉันล้างบันทึกเหตุการณ์และปรับปรุงประสิทธิภาพ - แต่ฉันใช้ procmon และเห็นว่าปัญหาจะเพิ่มขึ้นและเติบโตอย่างช้าๆเมื่อเวลาผ่านไปจนกว่าจะกลายเป็นปัญหา ด้วยเหตุผลบางอย่างเพื่อน Azure ได้วิจารณ์อย่างรุนแรงกับฉันเมื่อโปสเตอร์ดั้งเดิมไม่ได้ติดตาม (อาจมีผู้เสียชีวิตถูกไล่ออกลาออกหรือไม่ว่าง) เพื่อน Azure ด้านล่างคิดว่าหากโปสเตอร์ดั้งเดิมไม่ได้ติดตามมันจะต้องเป็นปัญหาคงที่ นี่มันน่ารำคาญและทำให้งงเพราะฉันไม่สามารถนึกถึงใครก็ตามที่ได้รับการยกย่องอย่างสูงในทางเทคนิคแล้วใครจะเข้ามารับตำแหน่งนี้ ฉันขอโทษถ้าฉันทิ่มเส้นประสาท บางทีในการเคลื่อนไหวของฉันที่อื่นบนอินเทอร์เน็ตที่ฉันโทรหาคนที่ฉันไปที่เส้นประสาทของเขา - ที่นี่ (serverfault) ฉันเพียงแค่มีน้ำใจและแบ่งปันความรู้ทางเทคนิคลึกและผลจากนาย Azure ข่มขู่ว่าการสนับสนุนทางเทคนิคของฉัน จำเป็นหรือสำหรับบล็อกของฉัน (ฉันไม่มีบล็อกดังกล่าว) ฉันยังไม่ได้ตั้งใจจะส่งลิงค์นี้ไปยังเพื่อนสนิทที่สำคัญประมาณครึ่งโหลที่ Microsoft และถามพวกเขาว่าอะไรที่เกิดขึ้นกับการกลั่นแกล้งประเภทนี้จากพนักงาน MSFT คนสำคัญเพราะฉันมุ่งเน้นไปที่ผลประโยชน์ที่ดีที่สุดของ ชุมชนในใจและคำตอบด้านล่างจาก Mr. Azure คือไม่กี่คำที่ไม่น่าเชื่อ, เป็นกรด, ทำให้ตกใจและข่มขู่ - ซึ่งฉันแน่ใจว่าบางคนสนุกกับการทำกับผู้อื่น ตอนแรกฉันถูกทำให้ขุ่นเคือง แต่อยู่เหนือมันและรู้ว่าผู้อ่านเชิงรับหรือผู้ใช้งานจะชื่นชอบสิ่งที่ฉันพูดและชื่นชมความคิดเห็นของฉัน - ฉันยืนอยู่ข้างหลัง 100% โดยไม่คำนึงถึงเหตุผลทางกฎหมายว่าทำไมมันจึงไม่เหมาะสม M. Azure โปรดฝึกความมีน้ำใจและงดเว้นจากการแสดงความคิดเห็นของฉันในแง่ที่ไม่ดี เพิ่งได้รับมันและแสดงความยับยั้งชั่งใจและไม่แสดงความคิดเห็นอีกครั้ง โปรดฝึกความมีน้ำใจและงดเว้นจากการแสดงความคิดเห็นของฉันในแง่ที่ไม่ดี เพิ่งได้รับมันและแสดงความยับยั้งชั่งใจและไม่แสดงความคิดเห็นอีกครั้ง โปรดฝึกความมีน้ำใจและงดเว้นจากการแสดงความคิดเห็นของฉันในแง่ที่ไม่ดี เพิ่งได้รับมันและแสดงความยับยั้งชั่งใจและไม่แสดงความคิดเห็นอีกครั้ง

ก่อกวน