Saya perlu bantuan untuk menunjukkan beberapa kesalahan di auth.log saya file di server Ubuntu saya. Beberapa minggu yang lalu, saya menemukan banyak upaya login ke port SSH saya (22) di auth.log , jadi saya mengubah port SSH saya. Itu bersih selama seminggu, dan kemudian saya menemukan banyak upaya login lain melalui port yang berbeda.
Saya mendapatkan banyak duplikat dari garis berwarna merah (pada gambar). Baris yang berulang adalah sebagai berikut:
saslauthd[1140]: pam_unix(smtp:auth): check pass; user unknown
saslauthd[1140]: pam_unix(smtp:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=
saslauthd[1140]: DEBUG: auth_pam: pam_authenticate failed: Authentication failure
saslauthd[1140]: do_auth : auth failure: [user=roselia] [service=smtp] [realm=mail.mydomain.com] [mech=pam] [reason=PAM auth error]
Saya tahu bahwa mereka mencoba masuk ke server surat saya (karena ranahnya adalah mail.mydomain.com ), tapi saya tidak tahu persis apa yang mereka coba lakukan, karena saya tidak tahu apa itu PAM. Apa itu PAM? Dan apa yang harus saya lakukan untuk menghentikan upaya autentikasi ini di server email saya (port 25)?
Saya juga terkadang mendapatkan beberapa log CRON di auth.log saya itu terkait dengan PAM, dan akan sangat bagus jika seseorang dapat memberi tahu saya apa artinya ini juga:
CRON[32236]: pam_unix(cron:session): session opened for user root by (uid=0)
CRON[32235]: pam_unix(cron:session): session opened for user root by (uid=0)
CRON[32236]: pam_unix(cron:session): session closed for user root
CRON[32235]: pam_unix(cron:session): session closed for user root
Jawaban yang Diterima:
Pertama, ini tidak biasa terlihat di server email. Setiap Mail Server di Internet melihat ini jika port 25 terbuka ke web. Bahkan gateway email dan server email di tempat kerja saya terkena ini, alasan mengapa banyak dari upaya ini disaring dan diblokir adalah IDS/IPS (Intrustion Detection / Prevention System) di perbatasan jaringan yang merujuk ke banyak sumber OSINT (Open Source Intelligence) untuk membuat kumpulan IP buruk berbasis reputasi yang diblokir. Beberapa dari penyelidikan ini berhasil, tetapi tidak berhasil saat dicoba.
Kemungkinan besar, ini bukan kekuatan kasar yang ditargetkan terhadap server Anda, ini adalah "pemindai dan probe Internet" yang melakukan pekerjaan mereka ke setiap server SMTP yang menghadap Internet. Ini mungkin robot spam yang mencoba menyelidiki relai terbuka, dan jika mereka tidak menemukan relai terbuka, mereka kemungkinan akan mencoba dan mendapatkan akses ke akun untuk menggunakan server SMTP sebagai relai email. Atau ini adalah pemindai layanan yang mencoba melihat apakah Anda memiliki 'sandi yang lemah' sehingga mereka dapat mengeksploitasinya dan kemudian mengeksploitasi server Anda untuk mengirim email mereka sendiri melalui server email Anda.
Terkait:Hibernasi hilang dari menu daya dan ketika saya menekan tombol daya laptop?Selama Anda mengikuti praktik keamanan lain dari kata sandi yang kuat, tidak memberikan akses kepada pengguna kecuali mereka membutuhkannya, dll., Anda harus melakukannya dengan baik dalam hal mereka tidak membobol server Anda. Saya tidak akan terlalu peduli dengan kegagalan otentikasi, dan lebih peduli jika otentikasi berhasil.
Opsi keamanan tambahan adalah mengatur Fail2Ban yang akan berfungsi untuk melarang pengguna, namun saya belum menjalankan ini dengan benar dan belum punya waktu untuk menggalinya agar fail2ban berfungsi untuk server email saya ke autoban IP jika gagal terlalu sering untuk mengautentikasi). Namun, berhati-hatilah dengan ini, karena ini juga dapat memblokir Anda jika Anda tidak hati-hati. (Setelah saya memiliki konfigurasi Fail2Ban yang 'berfungsi', saya akan membagikannya sebagai komentar untuk jawaban ini, tetapi sulit untuk membuatnya berperilaku seperti yang saya inginkan)
Adapun cron:session entri di auth.log . Anda , itu hanya catatan bahwa cron sistem daemon menjalankan cron tugas dari /etc/crontab , /etc/cron.{d,daily,hourly,monthly,weekly}/* , dan root crontab pengguna per jadwal yang ditetapkan untuk tugas cron sebagai pengguna root (di mana crontab diatur untuk dijalankan sebagai root ). Itu biasanya OK, asalkan Anda benar-benar memeriksa setiap crontab di bawah akun root untuk memastikan tidak ada yang 'buruk' berjalan secara otomatis sebagai root .