{"id":8,"date":"2006-03-10T17:17:15","date_gmt":"2006-03-10T16:17:15","guid":{"rendered":"http:\/\/my.stargazer.at\/?p=8"},"modified":"2007-06-19T15:45:36","modified_gmt":"2007-06-19T13:45:36","slug":"ssh-dictionary-attacken-und-denyhosts","status":"publish","type":"post","link":"https:\/\/my.stargazer.at\/de\/2006\/03\/10\/ssh-dictionary-attacken-und-denyhosts\/","title":{"rendered":"SSH-Dictionary-Attacken und DenyHosts"},"content":{"rendered":"

Ich beginne meinen Tag gew\u00f6hnlicherweise mit einem Check meiner Server und bekomme bei der auth.log des Sysloggers wie \u00fcblich einen Schreikrampf, da diese stetig w\u00e4chst. Standardbenutzer werden mit einem Dictionary getestet – und wer Accounts wie ‚test‘ mit gleichnamigem Passwort beheimatet wird sehr bald \u00fcber unliebsamen Besuch zu klagen haben.
\n
\nDas Programm DenyHosts, ein Python Script parsed die Logs des SSHds und findet die angegriffenen Accounts und die IP des Angreifers, welche leider zu oft ein Proxy ist. Da ich OpenSSH benutze und dieser so gebaut ist, dass er die Datei \/etc\/hosts.deny beachtet werden die Angreifenden IPs genau dort eingetragen.<\/p>\n

Die Website von DenyHosts<\/a> verr\u00e4t uns die Features:<\/p>\n

\n

Features<\/h4>\n
    \n
  • Parses \/var\/log\/secure to find all login attempts and filters failed and successful attempts.<\/li>\n
  • Synchronization mode (new in 2.0) allows DenyHosts daemons the ability to share data via a centralized server to proactively thwart attacks.\n<\/li>\n
  • Can be run from the command line, cron or as a daemon (new in 0.9)\n<\/li>\n
  • Records all failed login attempts for the user and offending host\n<\/li>\n
  • For each host that exceeds a threshold count, records the evil host\n<\/li>\n
  • Keeps track of each non-existent user (eg. sdadasd) when a login attempt failed.\n<\/li>\n
  • Keeps track of each existing user (eg. root) when a login attempt failed.\n<\/li>\n
  • Keeps track of each offending host (with 0.8+ these hosts can be purged if the associated entry in \/etc\/hosts.deny is expired)\n<\/li>\n
  • Keeps track of suspicious logins (that is, logins that were successful for a host that had many login failures)\n<\/li>\n
  • Keeps track of the file offset, so that you can reparse the same file (\/var\/log\/secure) continuously (until it is rotated).\n<\/li>\n
  • When the log file is rotated, the script will detect it and parse from the beginning.\n<\/li>\n
  • Appends \/etc\/hosts.deny and adds the newly banned hosts\n<\/li>\n
  • Optionally sends an email of newly banned hosts and suspicious logins.\n<\/li>\n
  • Keeps a history of all user, host, user\/host combo and suspicious logins encountered which includes the data and number of corresponding failed login attempts.\n<\/li>\n
  • Maintains failed valid and invalid user login attempts in separate files, such that it is easy to see which valid user is under attack (which would give you the opportunity to remove the account, change the password or change it’s default shell to something like \/sbin\/nologin\n<\/li>\n
  • Upon each run, the script will load the previously saved data and re-use it to append new failures.\n<\/li>\n
  • Resolves IP addresses to hostnames, if available (new in v0.6.0).\n<\/li>\n
  • \/etc\/hosts.deny entries can be expired (purge) at a user specified time (new in 0.8)\n<\/li>\n
  • FreeBSD support (added in 0.7)<\/li>\n<\/ul>\n<\/blockquote>\n

    Kurz gesagt, angreifende IP-Adressen werden von Denyhosts geblockt und an einem zentralen Server gemeldet, mit welchem man synchronisieren kann um Angreifer schon vor ihrem Angriff zu blocken. – Der Haken an der Sache ist jedoch, dass man sehr bald eine lange Liste von IP Adressen und man somit oftmals ganze Netzwerkranges blockiert. Daher bietet es sich an, die Blockade auf einzelne Dienste wie SMTP und SSH zu beschr\u00e4nken, welche ohnehin nur eine begrenzte Anzahl von Benutzern ben\u00f6tigen.<\/p>\n

    Die Installation von DenyHosts war f\u00fcr mich als Gentoo-Benutzer sehr einfach, da sie sich auf ein ‚emerge app-admin\/denyhosts‘ beschr\u00e4nkte, nachdem ich das Paket unmaskiert hatte:<\/p>\n

    echo \"app-admin\/denyhosts ~x86\" >> \/etc\/portage\/package.keywords
    \nemerge app-admin\/denyhosts<\/code><\/p><\/blockquote>\n

    Um sicherzugehen dass mein SSHd mit tcpd Support compiled wurde loggte ich mich auf der lokalen Konsole ein und trug 127.0.0.1 in \/etc\/hosts.deny ein. Das File sieht wie folgt aus:<\/p>\n

    sshd: 127.0.0.1<\/code><\/p><\/blockquote>\n

    Da mein SSHd mit tcpd-Unterst\u00fctzung gebaut wurde verweigert er mir nun den Login via SSH von 127.0.0.1 kommend, was er mit der Meldung „ssh_exchange_identification: Connection closed by remote host<\/strong>“ kund tat.<\/p>\n

    So weit so gut.<\/p>\n

    Die Konfiguration von DenyHosts liegt in \/etc\/denyhosts.conf und verlangt unsere Aufmerksamkeit. Hier die wichtigsten Dinge:<\/p>\n

    Achtung: Dies ist nur ein Auszug aus der Config-Datei!<\/strong><\/p>\n


    \nSECURE_LOG = \/var\/log\/messages # Sofern der SSHd dorthin loggt
    \nDAEMON_LOG = \/var\/log\/denyhosts # Wir wollen wissen was DenyHosts so macht<\/p>\n

    SYNC_SERVER = http:\/\/xmlrpc.denyhosts.net:9911 # Damit wir nun Zentral synchronisieren k\u00f6nnen
    \nSYNC_DOWNLOAD = yes # Wir laden Listen herunter
    \nSYNC_UPLOAD = yes # Wir melden b\u00f6se Hosts ein
    \n<\/code><\/p><\/blockquote>\n

    „rc-update add denyhosts default“ und „\/etc\/init.d\/denyhosts start“ schliessen unsere Arbeit ab und klopfen uns auf die Schulter. Nach nicht allzulanger Zeit bekommen wir die ersten geblockten Hosts, einerseits durch unser Logfile welches gelesen wird – andererseits durch eben erfolgende Angriffe eines Script Kiddies.<\/p>\n","protected":false},"excerpt":{"rendered":"

    Ich beginne meinen Tag gew\u00f6hnlicherweise mit einem Check meiner Server und bekomme bei der auth.log des Sysloggers wie \u00fcblich einen Schreikrampf, da diese stetig w\u00e4chst. Standardbenutzer werden mit einem Dictionary getestet – und wer Accounts wie ‚test‘ mit gleichnamigem Passwort beheimatet wird sehr bald \u00fcber unliebsamen Besuch zu klagen haben.<\/p>\n","protected":false},"author":7,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4],"tags":[34,170],"class_list":["post-8","post","type-post","status-publish","format-standard","hentry","category-it-related-stuff","tag-firewall","tag-security"],"_links":{"self":[{"href":"https:\/\/my.stargazer.at\/de\/wp-json\/wp\/v2\/posts\/8","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/my.stargazer.at\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/my.stargazer.at\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/my.stargazer.at\/de\/wp-json\/wp\/v2\/users\/7"}],"replies":[{"embeddable":true,"href":"https:\/\/my.stargazer.at\/de\/wp-json\/wp\/v2\/comments?post=8"}],"version-history":[{"count":0,"href":"https:\/\/my.stargazer.at\/de\/wp-json\/wp\/v2\/posts\/8\/revisions"}],"wp:attachment":[{"href":"https:\/\/my.stargazer.at\/de\/wp-json\/wp\/v2\/media?parent=8"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/my.stargazer.at\/de\/wp-json\/wp\/v2\/categories?post=8"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/my.stargazer.at\/de\/wp-json\/wp\/v2\/tags?post=8"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}