Paano malalaman kung anong hindi matagumpay na pagtatangka ng SSH ang mayroon sa aming server

Di nagtagal ay nagpaliwanag ako kung paano malaman kung aling mga IP ang nakakonekta sa SSH, ngunit ... paano kung ang username o password ay hindi tama at hindi sila kumonekta?

Sa madaling salita, kung may sumusubok hulaan kung paano i-access ang aming computer o server sa pamamagitan ng SSH, kailangan talaga nating malaman, tama?

Para doon gagawin namin ang parehong pamamaraan tulad ng sa nakaraang post, susuriin namin ang tala ng pagpapatotoo ngunit sa oras na ito, na may ibang filter:

cat /var/log/auth* | grep Failed

Dapat nilang patakbuhin ang utos sa itaas tulad ng ugat, o kasama sudo upang gawin ito sa mga pahintulot sa administrasyon.

Nag-iiwan ako ng isang screenshot ng hitsura nito:

Tulad ng nakikita mo, ipinapakita nito sa akin ang buwan, araw at oras ng bawat nabigong pagtatangka, pati na rin ang gumagamit kung saan sinubukan nilang ipasok at ang IP kung saan sinubukan nilang mag-access.

Ngunit maaari itong isaayos nang kaunti pa, gagamitin namin ang awkward upang mapagbuti nang kaunti ang resulta:

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

Ang nasa itaas ay ISANG linya.

Narito nakikita natin kung paano ito magiging hitsura:

Ang linyang ipinakita ko lamang sa iyo ay hindi dapat kabisaduhin lahat, maaari kang lumikha ng isang bansag para sa kanya, ang resulta ay kapareho ng sa unang linya, medyo maayos lamang.

Alam kong ito ay hindi magiging kapaki-pakinabang sa marami, ngunit para sa amin na namamahala ng mga server alam ko na magpapakita ito sa amin ng ilang mga kagiliw-giliw na data hehe.

Regards


Iwanan ang iyong puna

Ang iyong email address ay hindi nai-publish. Mga kinakailangang patlang ay minarkahan ng *

*

*

  1. Responsable para sa data: Miguel Ángel Gatón
  2. Layunin ng data: Kontrolin ang SPAM, pamamahala ng komento.
  3. Legitimation: Ang iyong pahintulot
  4. Komunikasyon ng data: Ang data ay hindi maiparating sa mga third party maliban sa ligal na obligasyon.
  5. Imbakan ng data: Ang database na naka-host ng Occentus Networks (EU)
  6. Mga Karapatan: Sa anumang oras maaari mong limitahan, mabawi at tanggalin ang iyong impormasyon.

  1.   hackloper775 dijo

    Napakahusay na paggamit ng mga tubo

    Regards

    1.    KZKG ^ Gaara dijo

      Salamat sa iyo

  2.   FIXOCONN dijo

    Magaling ang 2 post

  3.   Mystog @ N dijo

    Palagi kong ginagamit ang una, dahil hindi ko alam ang awk, ngunit kakailanganin kong malaman ito

    pusa / var / log / auth * | Nabigo ang grep

    Dito kung saan ako nagtatrabaho, sa Faculty of Mathematics-Computing sa Univ de Oriente sa Cuba, mayroon kaming isang pabrika ng "maliit na mga hacker" na patuloy na nag-iimbento ng mga bagay na hindi dapat at dapat kasama ko ang 8 mata. Ang ssh tema ay isa sa mga ito. Salamat sa tip dude.

  4.   Hugo dijo

    Isang tanong: kung ang isang tao ay may isang server na nakaharap sa internet ngunit sa mga iptable bubukas lamang ang ssh port para sa ilang mga panloob na mga MAC address (sabihin natin mula sa isang tanggapan), ang mga pagtatangka sa pag-access mula sa natitirang mga panloob na mga address ay maaabot ang tala ng pagpapatunay at / o panlabas? Dahil mayroon akong mga pagdududa.

    1.    KZKG ^ Gaara dijo

      Sa log kung ano ang nai-save ay ang mga kahilingan lamang na pinapayagan ng firewall, ngunit tinanggihan o naaprubahan ng system tulad nito (Ibig kong sabihin ang pag-login).
      Kung hindi pinapayagan ng firewall na pumasa ang mga kahilingan ng SSH, walang maaabot ang log.

      Hindi ko ito nasubukan, ngunit halika ... Sa palagay ko dapat ganito

  5.   Ungal ng asno dijo

    bigo ang grep -i /var/log/auth.log | awk '{print $ 2 «-» $ 1 »» $ 3 «\ t USER:» $ 9 «\ t MULA SA:» $ 11}'
    Nabigo ang rgrep -i / var / log / (logrotates folder) | awk '{print $ 2 «-» $ 1 »» $ 3 «\ t USER:» $ 9 «\ t MULA SA:» $ 11}'

    1.    Ungal ng asno dijo

      sa centos-redhat… ..etc ……
      / var / log / secure