Si të dimë se çfarë përpjekjesh të pasuksesshme SSH ka pasur serveri ynë

Jo shumë kohë më parë e shpjegova si të dimë cilat IP janë lidhur nga SSH, por ... po sikur emri i përdoruesit ose fjalëkalimi të ishte i pasaktë dhe ata nuk u lidhën?

Me fjalë të tjera, nëse dikush po përpiqet të mendojë se si të hyni në kompjuterin ose serverin tonë përmes SSH, ne me të vërtetë duhet ta dimë, apo jo?

Për këtë ne do të bëjmë të njëjtën procedurë si në postimin e mëparshëm, ne do të filtrojmë regjistrin e vërtetimit, por këtë herë, me një filtër tjetër:

cat /var/log/auth* | grep Failed

Ata duhet të ekzekutojnë komandën e mësipërme si rrënjë, ose me sudo për ta bërë atë me leje administrative.

Unë lë një pamje të ekranit se si duket:

Siç mund ta shihni, kjo më tregon muajin, ditën dhe kohën e çdo përpjekjeje të dështuar, si dhe përdoruesin me të cilin ata u përpoqën të futnin dhe IP-në nga e cila u përpoqën të hynin.

Por kjo mund të rregullohet pak më shumë, ne do ta përdorim i çuditshëm për të përmirësuar rezultatin pak:

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

Më sipër është një linjë.

Këtu shohim se si do të dukej:

Kjo linjë që sapo ju tregova se nuk duhet të mësohen përmendësh të gjitha, ju mund të krijoni një pseudonim për të, rezultati është i njëjtë si me vijën e parë, vetëm pak më i organizuar.

Këtë e di që jo shumë do ta konsiderojnë të dobishme, por për ata prej nesh që administrojnë serverat e di që do të na tregojë disa të dhëna interesante hehe.

të fala


Lini komentin tuaj

Adresa juaj e emailit nuk do të publikohet. Fusha e kërkuar janë shënuar me *

*

*

  1. Përgjegjës për të dhënat: Miguel Ángel Gatón
  2. Qëllimi i të dhënave: Kontrolloni SPAM, menaxhimin e komenteve.
  3. Legjitimimi: Pëlqimi juaj
  4. Komunikimi i të dhënave: Të dhënat nuk do t'u komunikohen palëve të treta përveç me detyrim ligjor.
  5. Ruajtja e të dhënave: Baza e të dhënave e organizuar nga Occentus Networks (BE)
  6. Të drejtat: Në çdo kohë mund të kufizoni, rikuperoni dhe fshini informacionin tuaj.

  1.   hakloper775 dijo

    Përdorim shumë i mirë i tubave

    të fala

    1.    KZKG ^ Gaara dijo

      Faleminderit

  2.   FIXOCONN dijo

    Shkëlqyeshëm 2 postimet

  3.   Mystog @ N dijo

    Gjithmonë e kam përdorur të parën, sepse nuk e di awk, por do të më duhet ta mësoj

    cat / var / log / auth * | grep Dështoi

    Këtu ku unë punoj, në Fakultetin e Matematikës-Informatikë në Univ de Oriente në Kubë, ne kemi një fabrikë të "hakerëve të vegjël" të cilët vazhdimisht po shpikin gjëra që nuk duhet dhe unë duhet të jem me 8 sy. Tema ssh është njëra prej tyre. Faleminderit për tipin tip.

  4.   Hugo dijo

    Një pyetje: nëse dikush ka një server që përballet me internet, por në iptables ai hap portin ssh vetëm për adresa të caktuara të brendshme MAC (le të themi nga një zyrë), përpjekjet e hyrjes nga pjesa tjetër e adresave të brendshme do të arrinin në regjistrin e vërtetimit dhe / ose e jashtme? Sepse kam dyshimet e mia.

    1.    KZKG ^ Gaara dijo

      Në regjistër, ajo që ruhet është vetëm kërkesa e lejuar nga firewall, por e refuzuar ose e aprovuar nga sistemi si i tillë (kam parasysh hyrjen).
      Nëse firewall nuk lejon që kërkesat e SSH të kalojnë, asgjë nuk do të arrijë në regjistër.

      Këtë nuk e kam provuar, por hajde ... Unë mendoj se duhet të jetë kështu

  5.   Pallmë dijo

    grep -i dështoi /var/log/auth.log | awk '{print $ 2 «-» $ 1 »» $ 3 «\ t PERRDORUESI:» $ 9 «\ t NGA:» $ 11}'
    rgrep -i dështoi / var / log / (regjistron dosjet) | awk '{print $ 2 «-» $ 1 »» $ 3 «\ t PERRDORUESI:» $ 9 «\ t NGA:» $ 11}'

    1.    Pallmë dijo

      në centos-redhat et ..etj
      / var / log / sigurt