Seberapa mendesak *** Sistem memulai kembali *** untuk keamanan?


56

Untuk mempelajari sedikit administrasi server, saya telah membuat server Ubuntu 14.04 sederhana tempat saya menjalankan situs web pribadi. Saya telah mengaturnya untuk menginstal pembaruan keamanan secara otomatis, tetapi tinggalkan pembaruan lainnya. Ini sepertinya bekerja dengan cukup baik. Kadang-kadang saya mendapatkan pesan saat masuk ke server (dengan ssh) mengatakan:

*** System restart required ***

Kali ini terjadi saya reboot Ubuntu sederhana dan semua baik-baik saja. Ini boleh saja karena ini adalah situs web pribadi yang sederhana. Apa yang saya bertanya-tanya tentang, adalah bagaimana ini bekerja untuk webservers yang seharusnya 99,9999etc% waktu Apakah mereka tidak me-restart dan risiko keamanan dilanggar karena pembaruan keamanan tidak diinstal (yang tidak dapat saya bayangkan)? Atau apakah mereka menerima downtime begitu saja (yang tidak dapat saya bayangkan juga)?

Bagaimana saya harus menangani ini jika ini adalah server produksi yang sangat penting yang saya ingin terus dan jalankan? Semua tips dipersilahkan!

[EDIT] Saya tahu saya bisa lakukan cat /var/run/reboot-required.pkgsuntuk mendaftar paket yang menyebabkan reboot. Perintah saat ini menghasilkan yang berikut:

linux-image-3.13.0-36-generic
linux-base
dbus
linux-image-extra-3.13.0-36-generic
linux-base

tetapi bagaimana saya tahu jika pembaruan adalah hal-hal kecil apakah saya memiliki kerentanan keamanan serius jika saya tidak melakukan restart?

[EDIT2] Oke, sekarang saya menggabungkan perintah yang menurut saya berguna menjadi satu:

xargs aptitude changelog < /var/run/reboot-required.pkgs | grep urgency=high

Jika ini tidak menghasilkan apa-apa, sepertinya tidak ada masalah keamanan dengan urgensi tinggi.

Satu pertanyaan terakhir: apakah low,, mediumdan highsatu-satunya kemungkinan yang mendesak, atau adakah yang lebih disukai misalnya criticalatau extremelyimportant?


Saya tidak mengerti pertanyaannya. Situs web dengan lalu lintas yang lebih besar hanya menjadwalkan penghentian ini selama periode waktu dengan lalu lintas yang lebih sedikit. Seberapa mendesaknya itu tergantung pada apa yang sedang diperbarui persis.
Ramhound

14
Saya bertanya-tanya berapa banyak orang yang datang ke sini karena mereka melihat pertanyaan dalam daftar "Pertanyaan Jaringan Panas" dan bertanya-tanya apa bahan peledaknya ... * mengangkat tangan *
David Richerby

6
@Ramhound: Ehm, tidak, mereka secara transparan beralih ke server sekunder selama masa pemeliharaan.
Lightness Races dengan Monica

1
Kembali pertanyaan terakhir: Saya ingin memfilter level rendah dan menengah dan menganggap semua level lain / tidak diketahui mendesak: | grep 'urgency=' | egrep -v '=(low|medium)'
KajMagnus

Jawaban:


45

Jawabannya tidak sederhana karena tergantung pada pembaruan yang dibuat. Jika kernel memiliki masalah keamanan yang serius, maka sebaiknya restart sesegera mungkin. Jika kernel hanya memiliki perbaikan kecil maka restart dapat ditunda.

Jika Anda menjamin ketersediaan> 99,9% maka Anda hampir selalu memiliki sistem berkerumun tempat Anda dapat mem-boot ulang node satu per satu tanpa mengganggu layanan.

Jadi, Anda me-reboot sistem pertama dan menghubungkannya kembali ke cluster. Lalu yang kedua dan seterusnya. Maka layanan tidak akan pernah menjadi tidak tersedia.


2
Terima kasih atas jawaban anda. Saya menambahkan sedikit pertanyaan awal saya; Saya tahu saya bisa lakukan cat /var/run/reboot-required.pkgsuntuk mendapatkan paket yang memerlukan reboot. Tetapi bagaimana saya tahu jika ini hanya perbaikan kecil, atau apakah ini merupakan kerentanan keamanan yang serius?
kramer65

2
@ kramer65 setiap paket memiliki changelog. Misalnya changlog untuk kernel dapat ditemukan di sini .
Uwe Plonus

2
Baiklah, jadi terserah sysadmin (yaitu: dalam kasus ini sendiri) untuk menentukan apakah perubahan itu penting? Saya memiliki terlalu sedikit pengetahuan untuk menentukan ini untuk kernel Linux, apalagi untuk semua miliaran paket lainnya. Apakah tidak ada tempat sentral di mana saya dapat menemukan penentuan apakah pembaruan benar-benar diperlukan untuk keamanan?
kramer65

8
@ kramer65 Jalankan aptitude changelog <package>, berikut ini adalah contoh keluaran: paste.ubuntu.com/8410798 (Ini ada di sistem Debian, bukan Ubuntu, tetapi yang sama juga bisa digunakan di Ubuntu.)
nyuszika7h

5
Terima kasih atas semua bantuannya di sini. Saya akhirnya menggabungkan semua hal yang telah saya pelajari di sini menjadi satu perintah: xargs aptitude changelog < /var/run/reboot-required.pkgs | grep urgency=high(menambahkannya ke pertanyaan awal juga) yang memberikan beberapa keluaran untuk paket mana yang memiliki tambalan yang sangat mendesak. Setelah itu, paket individu tentu saja dapat diperiksa. Terima kasih banyak untuk semua jawaban dan ide!
kramer65

3

addon untuk solusi topik

Saya melakukan pemeriksaan serupa untuk 'persyaratan reboot' untuk sistem pemantauan zabbix

Saya melihat 2 masalah dalam solusi 'Topik':

  1. aptitude biasanya berfungsi buruk dalam skrip. Saya membunuh beberapa jam tetapi masih tidak membuatnya bekerja dengan zabbix
  2. jika hanya 1 changelog yang menyertakan pembaruan mendesak - cek Anda akan selalu menunjukkan hasil positif

Logika saya adalah:

  1. Periksa perubahan terakhir hanya di changelog untuk setiap paket yang membutuhkan reboot sistem
  2. Sebagai output hanya menunjukkan pembaruan prioritas tertinggi

Menggunakan dokumentasi Debian saya menemukan 5 nilai yang mungkin untuk 'urgensi' dan juga fakta bahwa itu dapat diikuti oleh karakter yang sama ("=") atau titik koma (":"). Juga ada karakter huruf besar dan kecil

Jadi saya berakhir dengan yang berikut:

#!/bin/bash
##################################
# Zabbix monitoring script
#
# Checking urgency in changelog 
# for updates which require system restart
#
##################################
# Contact:
#  anton.lugovoi@yandex.ru
##################################
# ChangeLog:
#  20151205    initial creation
#  20151208    check uniq packages only 
##################################

case "$1" in

status)
    if [ -f /var/run/reboot-required ]; then
      echo 1
    else
      echo 0
    fi 
    ;;

urgency)
    if [ -f /var/run/reboot-required.pkgs ]; then
      while read pkg; do
        tmp=`/usr/bin/apt-get changelog $pkg | \
             /bin/grep -m1 -ioP '(?<=[Uu]rgency[=:])(low|medium|high|emergency|critical)' | \
             tr '[:upper:]' '[:lower:]'`
        if [ -n $tmp ]; then
          if   [ "$tmp" == "low" ] && \
               [ "$urgency" != "medium" ] && \
               [ "$urgency" != "high" ] && \
               [ "$urgency" != "emergency" ] && \
               [ "$urgency" != "critical" ]; then 
            urgency=low
          elif [ "$tmp" == "medium" ] && \
               [ "$urgency" != "high" ] && \
               [ "$urgency" != "emergency" ] && \
               [ "$urgency" != "critical" ]; then 
            urgency=medium
          elif [ "$tmp" == "high" ] && \
               [ "$urgency" != "emergency" ] && \
               [ "$urgency" != "critical" ]; then 
            urgency=high
          elif [ "$tmp" == "emergency" ] && \
               [ "$urgency" != "critical" ]; then 
            urgency=emergency
          elif [ "$tmp" == "critical" ]; then 
            urgency=critical
            break
          fi
        fi 
      done < <(sort -u /run/reboot-required.pkgs)
    else
      urgency=none
    fi

    case "$urgency" in
        none)      urgency=0 ;;
        low)       urgency=1 ;;
        medium)    urgency=2 ;;
        high)      urgency=3 ;;
        emergency) urgency=4 ;;
        critical)  urgency=5 ;;
        *)         urgency=42 ;;
    esac

    echo $urgency
    ;;
esac
exit 0

Hasil dari:

  • reboot_required_check.sh status mengembalikan 1 jika reboot diperlukan, 0 jika tidak
  • reboot_required_check.sh urgency mengembalikan level 'urgensi' tertinggi atau '0' jika reboot tidak diperlukan

Semoga ini membantu seseorang menghemat waktu;)


0

Apa yang saya bertanya-tanya tentang, adalah bagaimana ini bekerja untuk webservers yang seharusnya 99,9999etc% waktu Apakah mereka tidak me-restart dan risiko keamanan dilanggar karena pembaruan keamanan tidak diinstal (yang tidak dapat saya bayangkan)? Atau apakah mereka menerima downtime begitu saja (yang tidak dapat saya bayangkan juga)?

Server web besar di-restart ketika * System restart diperlukan * muncul karena alasan keamanan.

Tapi ini transparan bagi pengguna dan situs tidak pernah turun karena server besar sering menjalankan dua atau tiga server yang menyimpan file yang persis sama dan menampilkan situs yang sama. Yang pertama adalah server utama sementara dua yang lain adalah sekunder dan hanya digunakan ketika server utama sedang down.


1
Meskipun secara teori ini benar, Big web serversjalankan versi kustom Linux. Mereka tidak akan melihat System restart requireddialog, mereka memperbarui apa yang mereka butuhkan untuk tetap aman. Dalam kebanyakan kasus, banyak jika tidak semua pembaruan dapat dilakukan ketika sistem sedang berjalan (saya percaya bahkan mungkin untuk memperbarui kernel Linux pada sistem yang berjalan tanpa reboot).
joeeey

Menarik. Saya memiliki server di Amazon dan saya sering memulai ulang karena pesan ini ... Saya menjalankan Ubuntu di server saya. Bagaimana cara menyesuaikannya sehingga saya tidak harus mem-boot-ulangnya sesekali?
rom

Saya tidak punya pengalaman dengan server Amazon. Big web serversdijalankan pada server khusus dan VPS. Karena itu, administrator sistem memiliki kontrol lebih besar atas perangkat lunak. Apakah Amazon memberi Anda akses root shell ke server Anda?
joeeey

Ya itu mungkin untuk memiliki akses root.
rom

Kemudian memperbarui paket secara manual, dan kemudian memulai kembali layanan yang terpengaruh, dan menggunakan sesuatu seperti Ksplice untuk pembaruan kernel akan menjadi salah satu cara. Perlu dicatat bahwa Ksplice freezes execution of a computer so it is the only program runningsaat menerapkan tambalan, jadi mungkin masih ada sedikit downtime (karena proses server web menjadi 'beku'). Di sinilah jawaban oleh @Uwe Plonus masuk
joeeey
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.