ฉันจะตรวจสอบผู้ใช้และพยายามเข้าถึง SSH บนเซิร์ฟเวอร์ของฉันได้อย่างไร


28

ฉันมีปัญหาด้านความปลอดภัยเล็กน้อยกับเซิร์ฟเวอร์ของฉันผู้ใช้ SSH สองสามคนได้ตั้งไฟที่รู้จักกันดี

ฉันอยากจะ:

  • ติดตามการเข้าสู่ระบบของผู้ใช้และการออกจากระบบ
  • ติดตามกิจกรรมของ SSH เหล่านี้เพื่อค้นหากิจกรรมที่เป็นอันตราย
  • ป้องกันผู้ใช้จากการลบบันทึก

ฉันไม่ได้เป็นผู้ดูแลระบบ sys มากและฉันค่อนข้างไม่มีประสบการณ์ในเรื่องนี้ดังนั้นคำแนะนำใด ๆ ก็ยินดีต้อนรับและเป็นประโยชน์มาก :)

คำตอบ:


27

เนื่องจากเรากำลังพูดถึงเซิร์ฟเวอร์ SSH ฉันจะให้โซลูชันบรรทัดคำสั่งแก่คุณ

  • ติดตามการเข้าสู่ระบบของผู้ใช้และการออกจากระบบ ง่ายมากไฟล์/var/log/auth.logควรมีข้อมูลนี้

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

  • ป้องกันผู้ใช้จากการลบบันทึก: auth.logผู้ใช้ไม่ควรจะไปสัมผัส เพื่อที่จะหยุดพวกเขาจากการเล่นกับ.bash_historyที่คุณต้องทำคู่ของเทคนิค

  • เกิดอะไรขึ้นถ้าผู้ใช้จัดการเพื่อรับการเข้าถึงรูท : คุณเมาแล้ว หากพวกเขาทำผิดพวกเขาจะสามารถซ่อนรอยเท้าทั้งหมดของพวกเขาได้


โปรดทราบว่าไม่มีวิธีที่จะป้องกันผู้ใช้ไม่ให้พิมพ์unset HISTFILEใน bash และประวัติ bash ของพวกเขาจะไม่ถูกบันทึก
Gilles 'หยุดความชั่วร้าย'

@Gilles โปรดอ่านลิงก์เคล็ดลับ พวกเขาตั้งค่า HITSFILE เป็นตัวแปรแบบอ่านอย่างเดียวใน. profile
Javier Rivera

ฉันคิดว่าคุณสามารถยกเลิกการตั้งค่าตัวแปรอ่านอย่างเดียวในทุบตีแบบไม่ จำกัด แต่ดูเหมือนจะไม่ นี้จะช่วยปรับปรุงการสอบกลับได้เล็ก ๆ น้อย ๆ ตั้งแต่เริ่มต้นเปลือกอื่น (ซึ่งจะไม่ได้อ่าน~/.bash_historyหรือ~/.bashrc) $HISTFILEจะแสดงขึ้นใน แต่ในตัวมันเองอาจจะถูกต้องตามกฎหมายอย่างสมบูรณ์ (เช่นผู้ใช้เพียงแค่ต้องการเรียกใช้zshหรือต้องการตั้งค่าตัวเลือกของพวกเขาในทางเลือกbashrc)
Gilles 'หยุดความชั่วร้าย'

1
ใช่. คุณสามารถ จำกัด ให้เขาทุบตีหรือเปลือกอื่น ๆ หลังจากความปลอดภัยทั้งหมดเป็นเพียงการแข่งขัน
Javier Rivera

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

6

[การปฏิเสธความรับผิด]ฉันรู้ว่าฉันมาปาร์ตี้ช้า แต่ฉันอยากจะวางคำตอบที่ฉันให้กับคำถามอื่นเพราะฉันรู้สึกว่ามันสามารถนำเสนอข้อมูลเชิงลึกที่ดีให้กับผู้อ่านและคำถามนี้ดูเหมือนจะเป็นไปได้ สถานที่สำหรับข้อมูลพื้นฐาน SSH

มีปัญหาคล้ายกันที่ทำให้ฉันหลังจากอ่านคำถามนี้ที่ AskUbuntu และตรวจสอบ VPS ของฉันเท่านั้นที่เห็นความพยายามอันดุร้ายของพันล้าน นั่นคือเมื่อฉันตัดสินใจที่จะดำเนินการ

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

grep sshd.\*Failed /var/log/auth.log | less

หากเอาต์พุตประกอบด้วยหลายบรรทัดนั่นคือแรงเดรัจฉานหลายครั้งโดยเฉพาะอย่างยิ่งหากเกิดขึ้นระหว่างช่วงเวลาสั้น ๆ คุณอาจต้องการดำเนินการต่อไปนี้:

เปลี่ยนไฟล์คอนฟิกูเรชัน ssh

การทำเช่นนี้เปิดไฟล์ที่อยู่ใน/ etc / SSH / sshd_configvim /etc/ssh/sshd_configด้วยการแก้ไขที่คุณชื่นชอบเช่นนี้

1. ลองย้าย ssh จากพอร์ต 22 : ค้นหาบรรทัดที่อ่านแล้ว:

# What ports, IPs and protocols we listen for
Port 22

และคอมเม้นท์พอร์ต 22 และใช้ใครก็ได้ที่คุณอาจชอบ ตัวอย่าง:

# What ports, IPs and protocols we listen for
# Port 22
Port 28934

โปรดจำไว้ว่าพอร์ตต่ำกว่า 1024 ต้องได้รับอนุญาตพิเศษ (รูท) ฉันไม่รู้ว่าสิ่งนี้จะรบกวนการทำงานของมันได้อย่างไร แต่ฉันแค่พูด

2. ปิดใช้งานการเข้าสู่ระบบรูทผ่าน ssh : เนื่องจากชื่อผู้ใช้รูทสามารถคาดเดาได้และให้การเข้าถึงระบบของคุณอย่างสมบูรณ์การให้การเข้าถึงบัญชีนี้ผ่านทาง SSH นั้นไม่มีความหมายใด ๆ ค้นหาบรรทัดอ่านPermitRootLoginและตั้งค่าให้ไม่มี

PermitRootLogin no

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

PasswordAuthentication no

! คำเตือน! ก่อนที่จะดำเนินการโปรดอ่านคู่มือนี้ที่นี่เกี่ยวกับวิธีตั้งค่าการตรวจสอบสิทธิ์ใบรับรอง

หมายเหตุ:sudo /etc/init.d/ssh restartหลังจากที่คุณได้ทำการเปลี่ยนแปลงใช้ เพื่อเชื่อมต่อกับพอร์ตอื่นผ่านการใช้งาน ssh username@hostname.com -p <port_number>SSH:

ติดตั้งไฟร์วอลล์

กรุณาตรวจสอบคำแนะนำนี้เกี่ยวกับวิธีการตั้งค่าที่มีประสิทธิภาพมากและมีประสิทธิภาพไฟร์วอลล์ซึ่งรวมอยู่ในลินุกซ์IPTables

ตั้งค่าสคริปต์เพื่อช่วยคุณในเรื่องความปลอดภัย

หนึ่งที่ผมใช้เองได้อย่างรวดเร็วและมาคิดเป็นfail2ban Fail2ban จะตรวจสอบไฟล์บันทึกของคุณสำหรับการพยายามเข้าสู่ระบบล้มเหลว หลังจากที่อยู่ IP /var/log/fail2ban.logได้เกินจำนวนสูงสุดของความพยายามในการรับรองความถูกต้องก็จะถูกปิดกั้นในระดับเครือข่ายและเหตุการณ์จะถูกบันทึกไว้ใน วิธีติดตั้ง:sudo apt-get install fail2ban

ตรวจสอบประวัติคำสั่งผ่าน ssh

มีคำสั่ง linux ชื่อhistoryซึ่งช่วยให้คุณเห็นคำสั่งที่ได้รับการป้อนข้อมูลจนถึงจุดนั้น ลองพิมพ์historyในเทอร์มินัลเพื่อดูคำสั่งทั้งหมดจนถึงจุดนั้น มันจะช่วยได้ถ้าคุณรู

หากต้องการค้นหาคำสั่งเฉพาะลอง:history | grep command-name

ในการแสดงรายการคำสั่งทั้งหมดหลังจาก ssh :fc -l ssh

นอกจากนี้คุณยังสามารถแก้ไขคำสั่งโดยใช้ vi (ยังไม่ได้ลองเป็นกลุ่มแม้ว่าฉันคิดว่ามันใช้งานได้ดี):fc -e vi

นอกจากนี้คุณยังสามารถลบประวัติ :history -c

หมายเหตุ:หากคุณไม่ได้เป็นแฟนของคำสั่งhistoryนอกจากนี้ยังมีไฟล์ในไดเรกทอรีบ้านของคุณ ( cd ~) เรียกว่า. bash_history (ถ้าคุณใช้ bash) ที่คุณสามารถcatดูทั้งหมดที่พิมพ์ในเปลือก bash


คำตอบที่ดีมาก คุณควรดูคำแนะนำที่ @radu ในaskubuntu.com/a/3906/59250
Cerber


3
  1. Javier ตอบคำถามนี้แล้ว: /var/log/auth.log
  2. ฉันได้พบบทความดี ๆ เกี่ยวกับเรื่องนี้ที่นี่
  3. หากผู้ใช้ของคุณไม่มีสิทธิ์เข้าถึงรูตไฟล์บันทึกของคุณควรปลอดภัย คุณสามารถลองสร้างกฎที่กำหนดเองในไฟล์ sudoers เพื่อ จำกัด สิ่งที่ผู้ใช้ของคุณสามารถเข้าถึงและวิธีการ นอกจากนี้คุณสามารถเพิ่มระดับการบันทึกสำหรับ sshd daemon

3

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

แต่คุณควรระมัดระวังเกี่ยวกับการให้การเข้าถึง ssh พวกเขาต้องการมันจริงหรือ? ไม่ใช่เรื่องธรรมดาที่จะให้สิทธิ์การเข้าถึง ssh เว้นแต่คุณจะอยู่ในธุรกิจการให้บริการเชลล์

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.