dnnWerk.at - Michaels Blog

Kennen wir doch alle, wenn wir unsere IIS-Logs durchforsten: Irgendwelche Hacker versuchen (meist über Bots), sich unter bekannten Login-Adressen (z.B. für WordPress oder Joomla) einzuloggen. Natürlich gelingt das nicht, der Webserver retourniert einen HTTP-404-Fehler ("Nicht gefunden") - und der Angreifer weiß, welches CMS hier nicht installiert ist.

Was aber, wenn wir ihn in die Irre führen? Wenn wir ihm suggerieren, dass diese Url doch existiert, aber er keinen Zugriff darauf hat? Mit dem bereis in Teil 2 installierten Url Rewriter Modul fangen wir den Angreifer bereits am IIS ab - und belasten so unser DNN-System gar nicht erst.

Andere CMS

Zu diesem Zwecke installieren wir eine Regel, die dem Angreifer beim Zugriff auf eine Login-Url den Fehler HTTP-403 ("Not allowed") zurückgibt. Wir haben ja bereits einige Regeln angelegt (z.B. zum Umleiten von HTTP auf HTTPS) - diese ergänzen wir nun um folgendes:

<rewrite>
   <rules>
      <rule name="Other CMS Logins" enabled="true" stopProcessing="true">
         <match url=".*" />
         <conditions logicalGrouping="MatchAny">
            <add input="{URL}" pattern=".*joomla.*" />
            <add input="{URL}" pattern="/administrator*" />
            <add input="{URL}" pattern="/umbraco*" />
            <add input="{URL}" pattern="/typo3*" />
            <add input="{URL}" pattern="/phpmyadmin*" />
            <add input="{URL}" pattern=".*/wp-.*" />
         </conditions>
         <action type="CustomResponse" statusCode="403" statusReason="Forbidden: Access is denied." statusDescription="You do not have permission to view this directory or page using the credentials that you supplied." />
      </rule>

Diese Eingabemuster können natürlich beliebig erfänzt werden, und müssen sich nicht ausschließlich auf CMS-Systeme beziehen. Um beispielsweise den Zugriff auf Filezilla-Server-Konfigurationsdateien zu blockieren (auch wenn Filezilla gar nicht installiert ist), so hängt man einfach noch folgendes dazu:

            <add input="{URL}" pattern=".*filezilla.*" />

Dateinamenserweiterungen

DNN basiert auf ASP.Net - es liegt also in der Natur der Sache, dass bestimmte Dateinamenserweiterungen, die auf andere Tecnologien hinweisen, wie PHP, ColdFusion oder Perl nicht auf der Website vorkommen. Sinnvollerweise können wir also auch hier potenzielle Angreifer in die Irre führen.

      <rule name="File Extensions" enabled="true" stopProcessing="true">
         <match url=".*" />
         <conditions logicalGrouping="MatchAny">
            <add input="{URL}" pattern="*.asp" />
            <add input="{URL}" pattern="*.cfm" />
            <add input="{URL}" pattern="*.php" />
            <add input="{URL}" pattern="*.pl" />
            <add input="{URL}" pattern="*.py" />
            <add input="{URL}" pattern="*.rb" />
            <add input="{URL}" pattern="*.ini" />
            <add input="{URL}" pattern="*.ftpconfig" />
         </conditions>
         <action type="CustomResponse" statusCode="403" statusReason="Forbidden: Access is denied." statusDescription="You do not have permission to view this directory or page using the credentials that you supplied." />
      </rule>

DNN spezifische Blockaden

Auch folgende Urls werden von Angreifern immer wieder versucht, führen aber ins Leere. Dabei bezieht es sich auf Urls, die von DNN nicht mehr verwendet werden. Die Täuschung besteht also darin, dem Angreifer vozugaukeln, dass hier eine ältere DNN-Version vorliegt.

      <rule name="DNN specific security" enabled="true" stopProcessing="true">
         <match url=".*" />
         <conditions logicalGrouping="MatchAny">
            <add input="{URL}" pattern="login\.aspx" />
            <add input="{URL}" pattern="register\.aspx" />
         </conditions>
         <action type="CustomResponse" statusCode="403" statusReason="Forbidden: Access is denied." statusDescription="You do not have permission to view this directory or page using the credentials that you supplied." />
      </rule>