Kako znati koje je neuspješne SSH pokušaje imao naš server

Nedavno sam objasnio kako znati koje IP-ove je povezao SSH, ali ... što ako su korisničko ime ili lozinka bili netačni i nisu se povezali?

Drugim riječima, ako neko pokušava pogoditi kako pristupiti našem računaru ili serveru putem SSH-a, to stvarno moramo znati ili ne?

Za to ćemo napraviti isti postupak kao u prethodnom postu, filtrirat ćemo zapis autentifikacije, ali ovaj put, s drugim filterom:

cat /var/log/auth* | grep Failed

Trebali bi pokrenuti gornju naredbu poput korijenili sa sudo to učiniti uz administrativne dozvole.

Ostavljam snimak zaslona kako to izgleda:

Kao što vidite, prikazuje mi mjesec, dan i vrijeme svakog neuspjelog pokušaja, kao i korisnika s kojim su pokušali ući i IP adresu s koje su pokušali pristupiti.

Ali ovo ćemo moći dogovoriti malo više, mi ćemo iskoristiti wow da malo poboljšamo rezultat:

cat /var/log/auth* | grep Failed | awk '{print $2 "-" $1 " " $3 "\t USUARIO: " $9 "\t DESDE: " $11}'

Iznad je JEDNA linija.

Ovdje vidimo kako bi to izgledalo:

Ova linija koju sam vam upravo pokazao ne biste trebali sve pamtiti, možete stvoriti pseudonim za nju je, međutim, rezultat isti kao i u prvoj liniji, samo malo organiziraniji.

To znam da će mnogima biti korisno, ali za one od nas koji upravljamo serverima znam da će nam pokazati neke zanimljive podatke hehe.

Saludos


Ostavite komentar

Vaša e-mail adresa neće biti objavljena. Obavezna polja su označena sa *

*

*

  1. Za podatke odgovoran: Miguel Ángel Gatón
  2. Svrha podataka: Kontrola neželjene pošte, upravljanje komentarima.
  3. Legitimacija: Vaš pristanak
  4. Komunikacija podataka: Podaci se neće dostavljati trećim stranama, osim po zakonskoj obavezi.
  5. Pohrana podataka: Baza podataka koju hostuje Occentus Networks (EU)
  6. Prava: U bilo kojem trenutku možete ograničiti, oporaviti i izbrisati svoje podatke.

  1.   hackloper775 rekao je

    Vrlo dobra upotreba cijevi

    Saludos

    1.    KZKG ^ Gaara rekao je

      Hvala

  2.   Fixoconn rekao je

    Odlično 2 posta

  3.   Mystog @ N rekao je

    Uvijek sam koristio prvu, jer ne znam awk, ali morat ću je naučiti

    cat / var / log / auth * | grep nije uspio

    Ovdje, gdje radim, na Matematičko-računskom fakultetu na Univ de Oriente na Kubi imamo tvornicu "malih hakera" koji neprestano izmišljaju stvari koje ne bi trebali, a ja moram biti s 8 očiju. Tema ssh je jedna od njih. Hvala na tipu.

  4.   hugo rekao je

    Jedna sumnja: ako netko ima server okrenut ka Internetu, ali u iptablesima se otvara ssh port samo za određene interne MAC adrese (recimo iz ureda), pokušaji pristupa s ostalih internih adresa stigli bi do dnevnika autentifikacije i / ili vanjski? Jer sumnjam.

    1.    KZKG ^ Gaara rekao je

      U dnevniku se spremaju samo zahtjevi koje dozvoljava zaštitni zid, ali ih sistem odbija ili odobrava (mislim na prijavu).
      Ako vatrozid ne dozvoljava prolazak SSH zahtjeva, ništa neće doći do dnevnika.

      Ovo nisam probao, ali hajde ... mislim da mora biti ovako 😀

  5.   njakati rekao je

    grep -i nije uspio /var/log/auth.log | awk '{ispiši $ 2 «-» $ 1 »» $ 3 «\ t KORISNIK:» $ 9 «\ t OD:» $ 11}'
    rgrep -i nije uspio / var / log / (prijavljuje mape) | awk '{ispiši $ 2 «-» $ 1 »» $ 3 «\ t KORISNIK:» $ 9 «\ t OD:» $ 11}'

    1.    njakati rekao je

      u centos-redhat ... ... itd ...
      / var / log / secure