Willkommen bei Network & Security     remoteshell-security.com
Partnerseiten
login.php?sid=35db2ac11846e5824a4e491a59475083 profile.php?mode=register&sid=35db2ac11846e5824a4e491a59475083 faq.php?sid=35db2ac11846e5824a4e491a59475083 memberlist.php?sid=35db2ac11846e5824a4e491a59475083 search.php?sid=35db2ac11846e5824a4e491a59475083 index.php?sid=35db2ac11846e5824a4e491a59475083

Foren-Übersicht » Netzwerksicherheit » IP-Spoofing erkennen/blocken
Neues Thema eröffnen  Neue Antwort erstellen Vorheriges Thema anzeigen :: Nächstes Thema anzeigen 
IP-Spoofing erkennen/blocken
BeitragVerfasst am: 29.02.2008 23:03 Antworten mit Zitat
Lukas
Anmeldedatum: 31.12.2005
Beiträge: 257
Wohnort: Wien




Hallo

ich glaube zwar nicht, dass es so ist, aber gibt es vielleicht einen Weg IP-Spoofigen zu blockieren/zu erkennen?
Wie steht es mit der Sicherheit des SEQ-Nummern-Verfahren?

Leider kann das ja "leicht" nachgeahmt werden bzw bietet es dank schlechter Implementierung oft eine Angriffsmöglichkeit.

Wie sieht es mit der Sicherheit dieses Verfahrens aus und kann man IP-Spoofing erkennen?

aber vermutlich ist das auch eine sensible Information, die dazu genutzt werden kann um in ein anderes System einzubrechen..... Evil or Very Mad

Very Happy

mfg
Benutzer-Profile anzeigen Private Nachricht senden
BeitragVerfasst am: 01.03.2008 00:38 Antworten mit Zitat
Cerox
Anmeldedatum: 31.12.2005
Beiträge: 782
Wohnort: Engelskirchen




Zitat:
aber vermutlich ist das auch eine sensible Information, die dazu genutzt werden kann um in ein anderes System einzubrechen


Meiner Meinung nach nicht, da du nach Möglichkeiten fragst, dein Netzwerk zu schützen und nicht nach Angriffsmöglichkeiten, aber das soll der Forenbetreiber entscheiden.

Und ich bitte Dich, die Forenregeln nicht als Belustigung anzusehen oder Anspielungen darauf auszuüben.
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden
BeitragVerfasst am: 01.03.2008 00:52 Antworten mit Zitat
Lukas
Anmeldedatum: 31.12.2005
Beiträge: 257
Wohnort: Wien




OT: Hallo, ich mache mich nicht über das Regelwerk lustig sondern über das Problem bzw die Situation mit dem geschlossenen Thread den ich in einem Thread (im OT-Forum) erklären/erläutern werde den ich gerade schreibe.
Es ist auch keine Anspielung auf das Regelwerk (btw: inwiefern darf man keine Anspielungen auf das Regelwerk machen?) sondern eben auch das obene genannte Problem bzw ja den Grund der Schliessung meines Threads.

mfg

EDIT: Ausserdem mache ich mich ja nicht lustig sondern spiele nur darauf an Very Happy wenn auch mit etwas komischer Intention ^^
Benutzer-Profile anzeigen Private Nachricht senden
BeitragVerfasst am: 02.03.2008 16:17 Antworten mit Zitat
duddits
Anmeldedatum: 03.01.2006
Beiträge: 569
Wohnort: /proc




Hallo,

Lukas hat Folgendes geschrieben:

ich glaube zwar nicht, dass es so ist, aber gibt es vielleicht einen Weg IP-Spoofigen zu blockieren/zu erkennen?


Es gibt verschiedene Wege , um sich gegen IP-Spoofing zu schützen. Allerdings einen 100% Schutz gibt es dagegen nicht bzw. sollte man eine Authentifizierung nie, nur auf Grundlage der IP-Adresse machen.

Denn wenn nur die IP-Adresse zur Authentifizierung dient, könnte es wie bei der Mittnick-Attacke ablaufen[1, 2].

Um effektiv gegen IP-Spoofing vorzugehen, bedarf es bestimmter Routing-Regelsätze, die global implementiert werden müssen. D.h. im privaten Netz müssen Vorkehrungen getroffen werden, ebenso auf Seiten des ISP und des Backbone Providers.

Privates Netz:
1. Alle Pakete mit einer internen Abesenderadresse daran hindern, von außen ins interne Netz zu gelangen.
2. Alle Pakete mit externen Absenderadressen daran hindern, von innerhalb des internen Netzes nach außen zu gelangen.
3. Alle Pakete mit externen Zieladressen daran hindern, von außen ins interne Netz zu gelangen.
5. Alle Pakete mit internen Zieladressen daran hindern, von innerhalb des internen Netzes nach außen zu gelangen.
6. Das private Netz, verwendet nur die privaten IP-Adresse nach RFC 1918
7. Die IP-Adresse 0.0.0.0 ist nicht legitim und sollte am Router/Gateway geblockt werden.
8. Die Loopback Adresse 127.0.0.1 ist nur für das interne Routing gedacht und darf nur hierfür genutzt werden.

Zu dem gibt es z.B. für Linux noch die Möglichkeit den rp_filter des Kernels zu nutzen, welche eine IP-Spoof-Protection bildet, in dem versucht wird die Quelladresse zu verifizieren:
Zitat:
> rp_filter - INTEGER
> 2 - do source validation by reversed path, as specified in RFC1812
> Recommended option for single homed hosts and stub network
> routers. Could cause troubles for complicated (not loop free)
> networks running a slow unreliable protocol (sort of RIP),
> or using static routes.
>
> 1 - (DEFAULT) Weaker form of RP filtering: drop all the packets
> that look as sourced at a directly connected interface, but
> were input from another interface.
>
> 0 - No source validation.


So kann man dann je nach Distribution entweder in der /etc/sysctl.conf entsprechendes eintragen, oder in dem entsprechenden Firewall-Script folgende Ergänzung machen:
Code:

[b]im Firewall-Script:[/b]
if [ -e /proc/sys/net/ipv4/conf/all ]; then
  echo "Spoofing-Schutz wird aktiviert...."
  for dev /proc/sys/net/ipv4/conf/*/rp_filter; do
        echo 1>$dev
        # bei bedarf durch 2 ersetzten
  done
else
  echo "Probleme beim Setzen des Spoofing-Schutzes!"
fi

in /etc/sysctl.conf:
duddits@duddits ~ $ su
Passwort:
duddits duddits # nano -w /etc/sysctl.conf
net.ipv4.conf.all.rp_filter=1


Der beste Schutz vor IP-Spoofing ist natürlich der Einsatz von kryptographischen Mitteln.
Hier bietet sich z.B. SSH als Wrapper-Funktion an, um auch Dienste welche nur eine Authentifizierung via IP ermöglichen, weitere Authentifizierungsmöglichkeiten zu geben.[3]

@Lukas
Was genau verstehst du unter dem SEQ-Nummer-Verfahren?

Zum Thema, ob ein Thread vom Inhalt zulässigist oder nicht, kann gerne im Offtopic-Bereich diskutiert werden, aber dann bitte auch nur dort.
Wobei man grundsätzlich sagen kann, wenn es darum geht, wie man sich Schützen kann, so ist der Thread auch zulässig.


[1] http://www.gulker.com/ra/hack/
[ 2] http://www.ti.rwth-aachen.de/teaching/kommunikationsnetze/data/Kommnetz_Folien_281107.pdf
[3] http://www.jfranken.de/homepages/johannes/vortraege/ssh2.de.html

Gruß
Daniel

_________________
Quidquid agis, prudenter agas et respice finem!

Jabber ID: duddits@amessage.info
Webseite: http://www.remoteshell-security.com
Weblog: http://blog.remoteshell-security.com
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Jabber ID
BeitragVerfasst am: 04.03.2008 20:09 Antworten mit Zitat
Lukas
Anmeldedatum: 31.12.2005
Beiträge: 257
Wohnort: Wien




Hallo, danke für deine Antwort.

Was ich gemeint habe sind IP-Spoofing Attacken wo ein Angreifer sich für jemand anders ausgibt um ins interne Netz zu gelangen also zB sich als externer Server ausgibt etc.

Ich hab das reversed path ip validation sehr interessant gefunden bzw den rp_filter, leider weiss ich nicht (trotz sehr langen googelns) ob das nur ne interne Filterung ist oder ob es eben auch externe Antwortpakete "verifizieren" kann.

Kannst du mir vielleicht das mit dem rp_filter/bzw dem reversed path ip validation erklären?

was ich mit SEQ-Nummern Verfahren gemeint habe war die SEQ-Nummern Ausgabe bei einer TCP-Verbindung

mfg
Benutzer-Profile anzeigen Private Nachricht senden
BeitragVerfasst am: 05.03.2008 15:44 Antworten mit Zitat
duddits
Anmeldedatum: 03.01.2006
Beiträge: 569
Wohnort: /proc




Hallo,

also wenn ich dich richtig verstanden habe, ging es dir beim Blockieren von IP-Spoofing vor allem darum, das es nicht zu folgenden Szenario kommen kann:
Ein Benutzer B verbindet sich im Internet mit einem Server S. Nun versucht ein Angreifer A sich in diese Verbindung einzuklinken, in dem er sich als Server ausgibt. Nun hat A hiermit eine Verbindung zu einem Benutzer aus dem internen geschützten Netz aufgebaut.

In der Theorie könnte solch ein Angriff durch aus funktionieren, allerdings muss hier der Angreifer irgendwie die Möglichkeit haben, die Verbindung zu beobachten. Dies könnte er aber nur wenn er Zugang zum Netz des Servers hat oder Zugriff zu einem der Router hat, welche die Pakete ablaufen.
Dies stellt den Angreifer aber in der Praxis vor einigen Problemen. Zunächst einmal muss er wissen, mit welchen Server sich der Benutzer verbindet, dann braucht er Zugriff auf das Netz des Servers. Die Idee sich den Zugriff zu einen der Router zu beschaffen, über die die Pakete laufen. Nachteil an der Idee, IP verwendet unterschiedliche Pfade um an sein Ziel zu gelangen daher bleibt hier nur wenig Spielraum für den Angreifer.
Die einzige Möglichkeit die man auch leicht in der Praxis realisieren könnte, wäre über Instant Messaging Dienste oder E-Mails den Benutzer dazu zu bringen, eine Aktion zu tätigen, so das der Benutzer sich mit dem Angreifer verbindet (da meistens eingehende Verbindung verboten sind, es sei denn, es werden Dienste angeboten).

Um solche Angriffe zu verhindern, ist vor allem eine Sensibilisierung der Benutzer für IT-Sicherheit der erste Schritt, den Angriff zu verhindern. Denn der Angriff lebt zum Großteil durch die Interaktion des Benutzers.

Hier zu sind noch folgende Artikel interessant, die das Thema pinholing beschreiben:
http://www.bford.info/pub/net/p2pnat/
http://www.heise.de/security/Wie-Skype-Co-Firewalls-umgehen--/artikel/82054

Zu den SEQ-Nummern Verfahren welches in TCP eingesetzt wird, muss ganz klar gesagt werden, das es nicht sicher ist. Das liegt daran, das bei der Analyse des Datenverkehrs es einem Angreifer möglich ist, die SEQ-Nummern vorherzusagen um sich so in eine bestehende TCP-Sitzung einzuklinken. Diese Angriffsform nennt man Session Hijacking (wobei es Session Hijacking nicht nur auf TCP-Ebene gibt z.B. auch in PHP-Anwedungen etc.). Abhilfe schaffen hier nur eine zusätzliche Signatur der Pakete, durch höhere Protokolle oder durch IPsec. Siehe hierzu auch die Mitnick-Attacke oben.

Zu deiner Frage zu rp_filter habe ich nochmal einen Blick in die Kernel gemacht und musste feststellen, das die Implementierung von rp_filter mittlerweile anders aussieht:
less /usr/src/linux/Documentation/networking/ip-sysctl.txt:
ip-sysctl.txt hat Folgendes geschrieben:
rp_filter - BOOLEAN
1 - do source validation by reversed path, as specified in RFC1812
Recommended option for single homed hosts and stub network
routers. Could cause troubles for complicated (not loop free)
networks running a slow unreliable protocol (sort of RIP),
or using static routes.

0 - No source validation.

conf/all/rp_filter must also be set to TRUE to do source validation
on the interface

Default value is 0. Note that some distributions enable it
in startup scripts


Da in der Kernel-Dokumentation auch nur ein Verweis auf das RFC 1812 gemacht wurde, lohnt sich ein Blick auf diese.

http://www.faqs.org/rfcs/rfc1812.html:
RFC 1812 hat Folgendes geschrieben:
4.3.2.8 Rate Limiting

A router which sends ICMP Source Quench messages MUST be able to
limit the rate at which the messages can be generated. A router
SHOULD also be able to limit the rate at which it sends other sorts
of ICMP error messages (Destination Unreachable, Redirect, Time
Exceeded, Parameter Problem). The rate limit parameters SHOULD be
settable as part of the configuration of the router. How the limits
are applied (e.g., per router or per interface) is left to the
implementor's discretion.

DISCUSSION
Two problems for a router sending ICMP error message are:
(1) The consumption of bandwidth on the reverse path, and
(2) The use of router resources (e.g., memory, CPU time)

To help solve these problems a router can limit the frequency with
which it generates ICMP error messages. For similar reasons, a
router may limit the frequency at which some other sorts of
messages, such as ICMP Echo Replies, are generated.

IMPLEMENTATION
Various mechanisms have been used or proposed for limiting the
rate at which ICMP messages are sent:

(1) Count-based - for example, send an ICMP error message for
every N dropped packets overall or per given source host.
This mechanism might be appropriate for ICMP Source Quench,
if used, but probably not for other types of ICMP messages.

(2) Timer-based - for example, send an ICMP error message to a
given source host or overall at most once per T milliseconds.

(3) Bandwidth-based - for example, limit the rate at which ICMP
messages are sent over a particular interface to some
fraction of the attached network's bandwidth.


Diesem können wir entnehmen, das ICMP (siehe am besten auch: http://tools.ietf.org/html/rfc792 Page 9) verwendet wird, um eine reversed path validation vorzunehmen. Dabei gibt es wohl verschiedene Möglichkeiten, dies mit ICMP zu realisieren.
So wie ich die Sache sehe, wird beim rp_filter nichts weiter gemacht, als das eine ICMP Nachricht an die Quell-IP-Adresse geschickt wird, um heraus zu finden, ob ein Host mit der Quell-IP-Adresse wirklich existiert.

Gruß
Daniel

_________________
Quidquid agis, prudenter agas et respice finem!

Jabber ID: duddits@amessage.info
Webseite: http://www.remoteshell-security.com
Weblog: http://blog.remoteshell-security.com
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Jabber ID
IP-Spoofing erkennen/blocken
Foren-Übersicht » Netzwerksicherheit
Du kannst keine Beiträge in dieses Forum schreiben.
Du kannst auf Beiträge in diesem Forum nicht antworten.
Du kannst deine Beiträge in diesem Forum nicht bearbeiten.
Du kannst deine Beiträge in diesem Forum nicht löschen.
Du kannst an Umfragen in diesem Forum nicht mitmachen.
Alle Zeiten sind GMT + 1 Stunde  
Seite 1 von 1  

  
  
 Neues Thema eröffnen  Neue Antwort erstellen  


Forensicherheit

Powered by phpBB © 2001-2004 phpBB Group
phpBB Style by Vjacheslav Trushkin
Deutsche Übersetzung von phpBB.de


remoteshell-security.com | Partner | Boardregeln | Impressum