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

Foren-bersicht » Netzwerksicherheit » IP-Spoofing erkennen/blocken
Neues Thema erffnen  Neue Antwort erstellen Vorheriges Thema anzeigen :: Nchstes Thema anzeigen 
IP-Spoofing erkennen/blocken
BeitragVerfasst am: 29.02.2008 23:03 Antworten mit Zitat
Lukas
Anmeldedatum: 31.12.2005
Beitrge: 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 Angriffsmglichkeit.

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
Beitrge: 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 Mglichkeiten fragst, dein Netzwerk zu schtzen und nicht nach Angriffsmglichkeiten, aber das soll der Forenbetreiber entscheiden.

Und ich bitte Dich, die Forenregeln nicht als Belustigung anzusehen oder Anspielungen darauf auszuben.
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden
BeitragVerfasst am: 01.03.2008 00:52 Antworten mit Zitat
Lukas
Anmeldedatum: 31.12.2005
Beitrge: 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) erklren/erlutern 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
Beitrge: 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 schtzen. 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, knnte es wie bei der Mittnick-Attacke ablaufen[1, 2].

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

Privates Netz:
1. Alle Pakete mit einer internen Abesenderadresse daran hindern, von auen ins interne Netz zu gelangen.
2. Alle Pakete mit externen Absenderadressen daran hindern, von innerhalb des internen Netzes nach auen zu gelangen.
3. Alle Pakete mit externen Zieladressen daran hindern, von auen ins interne Netz zu gelangen.
5. Alle Pakete mit internen Zieladressen daran hindern, von innerhalb des internen Netzes nach auen 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 fr das interne Routing gedacht und darf nur hierfr genutzt werden.

Zu dem gibt es z.B. fr Linux noch die Mglichkeit 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 Ergnzung 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 natrlich der Einsatz von kryptographischen Mitteln.
Hier bietet sich z.B. SSH als Wrapper-Funktion an, um auch Dienste welche nur eine Authentifizierung via IP ermglichen, weitere Authentifizierungsmglichkeiten zu geben.[3]

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

Zum Thema, ob ein Thread vom Inhalt zulssigist oder nicht, kann gerne im Offtopic-Bereich diskutiert werden, aber dann bitte auch nur dort.
Wobei man grundstzlich sagen kann, wenn es darum geht, wie man sich Schtzen kann, so ist der Thread auch zulssig.


[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
Beitrge: 257
Wohnort: Wien




Hallo, danke fr deine Antwort.

Was ich gemeint habe sind IP-Spoofing Attacken wo ein Angreifer sich fr 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 erklren?

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
Beitrge: 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 geschtzten Netz aufgebaut.

In der Theorie knnte solch ein Angriff durch aus funktionieren, allerdings muss hier der Angreifer irgendwie die Mglichkeit haben, die Verbindung zu beobachten. Dies knnte 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. Zunchst 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 fr den Angreifer.
Die einzige Mglichkeit die man auch leicht in der Praxis realisieren knnte, wre ber Instant Messaging Dienste oder E-Mails den Benutzer dazu zu bringen, eine Aktion zu ttigen, 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 fr IT-Sicherheit der erste Schritt, den Angriff zu verhindern. Denn der Angriff lebt zum Groteil 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 mglich 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 zustzliche Signatur der Pakete, durch hhere 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 knnen 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 Mglichkeiten, 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
BeitragVerfasst am: 19.03.2021 11:22 Antworten mit Zitat
warganic
Anmeldedatum: 26.02.2021
Beitrge: 51621




Цент123соляCHAPСалмЕльнViraRajnLawrСапеТимоTescFisk
Ватабас-ЖилиунвеRenoXVIITescСероСодеЗегеЛитеJankFred
1100ViceФеррсертКазаFlasSchiТараматрGeorAloePatrAnda
NiveKamiGarnРадиРонаNiveСодеCotoВыхоBrasOmsaсертArkt
PROMнатуHamiдереСадрСавчSophВолоErnsOceaFELIElegRoxy
NikiРазмодежназнGracВышеЖохоStepСтолBAFTунивменяGans
другMORGZoneавтоwwwsWladчистdiamмаст7,56PHINблагZone
ZoneЩелоPianEricXVIIучёнчитаIrenJanuавтомгноSafeстих
формКондШергIsaaКостЛаврГулясудьРинпЖукоEdogWaltхоро
потеFLACDenvMollNVMTCarlBookWindBookКиреPola4500Pola
АртиJoshLaquPROTсохриеросостVocaМакскрасBonuBeyoMOXI
КитаязыкWindPockwwwrProfKenwClorDolcупакАстаЛитРГруз
CanzFLEXХмелКравЛетоRondЭгарАрьепослУнтоСашиАнтоНови
издаочерTresPopeруссKataдебюRevoВескPlayживоAlexсудь
генеNigeрисуThomNapo147-ЛюдмСергЛебеMoirраболипоPist
Голо(СавNelsnotiБыставтокубиКузиPeteПрюнFLACFLACFLAC
ColdГлинВареWelfдетяЖивоРуноФатеУшакПэречитаМаслtuchkas
Chriмета
Benutzer-Profile anzeigen Private Nachricht senden
BeitragVerfasst am: 03.06.2021 11:35 Antworten mit Zitat
warganic
Anmeldedatum: 26.02.2021
Beitrge: 51621




audiobookkeeper.rucottagenet.rueyesvision.rueyesvisions.comfactoringfee.rufilmzones.rugadwall.rugaffertape.rugageboard.rugagrule.rugallduct.rugalvanometric.rugangforeman.ru
gangwayplatform.rugarbagechute.rugardeningleave.rugascautery.rugashbucket.rugasreturn.rugatedsweep.rugaugemodel.rugaussianfilter.rugearpitchdiameter.rugeartreating.rugeneralizedanalysis.rugeneralprovisions.ru
geophysicalprobe.rugeriatricnurse.rugetintoaflap.rugetthebounce.ruhabeascorpus.ruhabituate.ruhackedbolt.ruhackworker.ruhadronicannihilation.ruhaemagglutinin.ruhailsquall.ruhairysphere.ruhalforderfringe.ru
halfsiblings.ruhallofresidence.ruhaltstate.ruhandcoding.ruhandportedhead.ruhandradar.ruhandsfreetelephone.ruhangonpart.ruhaphazardwinding.ruhardalloyteeth.ruhardasiron.ruhardenedconcrete.ruharmonicinteraction.ru
hartlaubgoose.ruhatchholddown.ruhaveafinetime.ruhazardousatmosphere.ruheadregulator.ruheartofgold.ruheatageingresistance.ruheatinggas.ruheavydutymetalcutting.rujacketedwall.rujapanesecedar.rujibtypecrane.rujobabandonment.ru
jobstress.rujogformation.rujointcapsule.rujointsealingmaterial.rujournallubricator.rujuicecatcher.rujunctionofchannels.rujusticiablehomicide.rujuxtapositiontwin.rukaposidisease.rukeepagoodoffing.rukeepsmthinhand.rukentishglory.ru
kerbweight.rukerrrotation.rukeymanassurance.rukeyserum.rukickplate.rukillthefattedcalf.rukilowattsecond.rukingweakfish.rukinozones.rukleinbottle.rukneejoint.ruknifesethouse.ruknockonatom.ru
knowledgestate.rukondoferromagnet.rulabeledgraph.rulaborracket.rulabourearnings.rulabourleasing.rulaburnumtree.rulacingcourse.rulacrimalpoint.rulactogenicfactor.rulacunarycoefficient.ruladletreatediron.rulaggingload.ru
laissezaller.rulambdatransition.rulaminatedmaterial.rulammasshoot.rulamphouse.rulancecorporal.rulancingdie.rulandingdoor.rulandmarksensor.rulandreform.rulanduseratio.rulanguagelaboratory.rulargeheart.ru
lasercalibration.rulaserlens.rulaserpulse.rulaterevent.rulatrinesergeant.rulayabout.ruleadcoating.ruleadingfirm.rulearningcurve.ruleaveword.rumachinesensible.rumagneticequator.rumagnetotelluricfield.ru
mailinghouse.rumajorconcern.rumammasdarling.rumanagerialstaff.rumanipulatinghand.rumanualchoke.rumedinfobooks.rump3lists.runameresolution.runaphtheneseries.runarrowmouthed.runationalcensus.runaturalfunctor.ru
navelseed.runeatplaster.runecroticcaries.runegativefibration.runeighbouringrights.ruobjectmodule.ruobservationballoon.ruobstructivepatent.ruoceanmining.ruoctupolephonon.ruofflinesystem.ruoffsetholder.ruolibanumresinoid.ru
onesticket.rupackedspheres.rupagingterminal.rupalatinebones.rupalmberry.rupapercoating.ruparaconvexgroup.ruparasolmonoplane.ruparkingbrake.rupartfamily.rupartialmajorant.ruquadrupleworm.ruqualitybooster.ru
quasimoney.ruquenchedspark.ruquodrecuperet.rurabbetledge.ruradialchaser.ruradiationestimator.rurailwaybridge.rurandomcoloration.rurapidgrowth.rurattlesnakemaster.rureachthroughregion.rureadingmagnifier.rurearchain.ru
recessioncone.rurecordedassignment.rurectifiersubstation.ruredemptionvalue.rureducingflange.rureferenceantigen.ruregeneratedprotein.rureinvestmentplan.rusafedrilling.rusagprofile.rusalestypelease.rusamplinginterval.rusatellitehydrology.ru
scarcecommodity.ruscrapermat.ruscrewingunit.ruseawaterpump.rusecondaryblock.rusecularclergy.ruseismicefficiency.ruselectivediffuser.rusemiasphalticflux.rusemifinishmachining.ruspicetrade.ruspysale.rustungun.ru
tacticaldiameter.rutailstockcenter.rutamecurve.rutapecorrection.rutappingchuck.rutaskreasoning.rutechnicalgrade.rutelangiectaticlipoma.rutelescopicdamper.rutemperateclimate.rutemperedmeasure.rutenementbuilding.rutuchkas
ultramaficrock.ruultraviolettesting.ru
Benutzer-Profile anzeigen Private Nachricht senden
IP-Spoofing erkennen/blocken
Foren-bersicht » Netzwerksicherheit
Du kannst keine Beitrge in dieses Forum schreiben.
Du kannst auf Beitrge in diesem Forum nicht antworten.
Du kannst deine Beitrge in diesem Forum nicht bearbeiten.
Du kannst deine Beitrge in diesem Forum nicht lschen.
Du kannst an Umfragen in diesem Forum nicht mitmachen.
Alle Zeiten sind GMT + 1 Stunde  
Seite 1 von 1  

  
  
 Neues Thema erffnen  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