ICMP ist doch ein einweg Protokoll oder ?
Also müsste es aus diesen Informationen
bestehen:
-Meine IP Addresse
-Mein Quell-Port
-Daten (Message code u. a.)
>Ziel IP
>?? Ziel Port ??
so müsste es doch möglich sein, das ich meine IP „SPOOFE“, also verändere, und
das Packet dann abschicke.
Ich denke viele Serverattacken basieren darauf, aber wie kann ich das in Win98
machen ?
ICMP-Paketformat
Da wirst Du wohl programmieren muessen.
Ich habe fuer Win noch von keinem Programm gehoert, mit dem man IP-Adressen spoofen kann. Ist wohl auch gut so, sonst fangen alle moeglichen User an, „Tests“ im Netz des eigenen Unternehmens anzustellen.
ICMP ist aehnlich wie UDP „shoot and forget“, also prinzipiell Einwegkommunikation.
Was das ICMP-Format angeht, kann ich Dir helfen (leider verschiebt der „wer-weiss-was“-Server die Zeichnung - hoffentlich kannst Du sie noch erkennen):
±---------------------------------------------------------------------+
¦ MAC Header ¦ IP Header ¦ UDP Header ¦ ICMP Header/Data ¦ MAC Trailer ¦
±---------------------------------------------------------------------+
¦ ¦
±---------------------------------+ ±--------+
¦0 8 16 24 31¦
±--------------±--------------±------------------------------+
¦ Type ¦ Code ¦ Checksum ¦
±--------------------------------------------------------------¦
¦ ICMP Message Data… ¦
±--------------------------------------------------------------+
TYPE field:
±------------------------------------------------+
¦ TYPE (dec)¦ ICMP Message Type ¦
±----------±------------------------------------¦
¦ 0 ¦ Echo reply ¦
¦ 3 ¦ Destination unreachable ¦
¦ 4 ¦ Source quench ¦
¦ 5 ¦ Redirect (change route) ¦
¦ 8 ¦ Echo request ¦
¦ 11 ¦ Time exceeded for datagram ¦
¦ 12 ¦ Parameter problem on datagram ¦
¦ 13 ¦ Timestamp request ¦
¦ 14 ¦ Timestamp reply ¦
¦ 15 ¦ Information request (obsolete) ¦
¦ 16 ¦ Information reply (obsolete) ¦
¦ 17 ¦ Address mask request ¦
¦ 18 ¦ Address mask reply ¦
±------------------------------------------------+
ECHO REPLY (Type=0)
±------------------------------------------------------------------+
¦ 0 8 16 24 31 ¦
¦ ±--------------±--------------±------------------------------+ ¦
¦ ¦ Type (0) ¦ Code (0) ¦ Checksum ¦ ¦
¦ ±------------------------------±------------------------------¦ ¦
¦ ¦ Identifier ¦ Sequence Number ¦ ¦
¦ ±--------------------------------------------------------------¦ ¦
¦ ¦ Optional Data ¦ ¦
¦ ±--------------------------------------------------------------¦ ¦
¦ ¦ … ¦ ¦
¦ ±--------------------------------------------------------------+ ¦
¦ The ICMP Echo Reply datagram is sent in response to an ICMP ¦
¦ Echo Request. The process is more commonly called a „ping“. ¦
¦ See the Echo Request (Type 8) format below. ¦
±------------------------------------------------------------------+
DESTINATION UNREACHABLE (Type=3)
±------------------------------------------------------------------+
¦ 0 8 16 24 31 ¦
¦ ±--------------±--------------±------------------------------+ ¦
¦ ¦ Type (3) ¦ Code (0-12) ¦ Checksum ¦ ¦
¦ ±--------------------------------------------------------------¦ ¦
¦ ¦ Unused (must be zero) ¦ ¦
¦ ±--------------------------------------------------------------¦ ¦
¦ ¦ Internet Header + first 64 bits of datagram ¦ ¦
¦ ±--------------------------------------------------------------¦ ¦
¦ ¦ … ¦ ¦
¦ ±--------------------------------------------------------------+ ¦
¦ ¦
¦ ±--------------------------------------------------------+ ¦
¦ ¦ CODE field ¦ Description ¦ ¦
¦ ±---------------±---------------------------------------¦ ¦
¦ ¦ 0 ¦ Network Unreachable ¦ ¦
¦ ¦ 1 ¦ Host Unreachable ¦ ¦
¦ ¦ 2 ¦ Protocol Unreachable ¦ ¦
¦ ¦ 3 ¦ Port Unreachable ¦ ¦
¦ ¦ 4 ¦ Fragmentation needed and DF set ¦ ¦
¦ ¦ 5 ¦ Source route failed ¦ ¦
¦ ¦ 6 ¦ Destination network unknown ¦ ¦
¦ ¦ 7 ¦ Destination host unknown ¦ ¦
¦ ¦ 8 ¦ Source host isolated ¦ ¦
¦ ¦ 9 ¦ Communication with destination ¦ ¦
¦ ¦ ¦ net administratively prohibited ¦ ¦
¦ ¦ 10 ¦ Communication with destination ¦ ¦
¦ ¦ 11 ¦ host administratively prohibited ¦ ¦
¦ ¦ 12 ¦ Host unreachable for type of service ¦ ¦
¦ ±--------------------------------------------------------+ ¦
±------------------------------------------------------------------+
SOURCE QUENCH (Type=4)
±------------------------------------------------------------------+
¦ 0 8 16 24 31 ¦
¦ ±--------------±--------------±------------------------------+ ¦
¦ ¦ Type (4) ¦ Code (0) ¦ Checksum ¦ ¦
¦ ±--------------------------------------------------------------¦ ¦
¦ ¦ Unused (must be zero) ¦ ¦
¦ ±--------------------------------------------------------------¦ ¦
¦ ¦ Internet Header + first 64 bits of original datagram ¦ ¦
¦ ±--------------------------------------------------------------¦ ¦
¦ ¦ … ¦ ¦
¦ ±--------------------------------------------------------------+ ¦
¦ The ICMP Source Quench message is used by IP routers to reduce ¦
¦ network congestion. If a device, or devices, are generating ¦
¦ traffic faster than the router can process the traffic, packets ¦
¦ may be discarded. The router may send a Source Quench message ¦
¦ to the sending device requesting that it reduce it’s rate of ¦
¦ datagram transmission. Congestion occurs for many reasons. Most ¦
¦ commonly, it occurs when a large amount of traffic from a high ¦
¦ speed LAN needs to cross a low speed WAN link. The router that ¦
¦ makes the LAN-WAN connection experiences congestion when it’s ¦
¦ capacity to buffer incoming traffic is exceded. ¦
±------------------------------------------------------------------+
REDIRECT (Type=5)
±------------------------------------------------------------------+
¦ 0 8 16 24 31 ¦
¦ ±--------------±--------------±------------------------------+ ¦
¦ ¦ Type (5) ¦ Code (0-3) ¦ Checksum ¦ ¦
¦ ±--------------------------------------------------------------¦ ¦
¦ ¦ Gateway Internet Address ¦ ¦
¦ ±--------------------------------------------------------------¦ ¦
¦ ¦ Internet Header + first 64 bits of original datagram ¦ ¦
¦ ±--------------------------------------------------------------¦ ¦
¦ ¦ … ¦ ¦
¦ ±--------------------------------------------------------------+ ¦
¦ ¦
¦ ±--------------------------------------------------------------+ ¦
¦ ¦ Code ¦ Meaning ¦ ¦
¦ ±-----±-------------------------------------------------------¦ ¦
¦ ¦ 0 ¦ Redirect Datagrams for the Net (obsolete) ¦ ¦
¦ ¦ 1 ¦ Redirect Datagrams for the Host ¦ ¦
¦ ¦ 2 ¦ Redirect Datagrams for the Type of Service and Net ¦ ¦
¦ ¦ 3 ¦ Redirect Datagrams for the Type of Service and Host ¦ ¦
¦ ±--------------------------------------------------------------+ ¦
¦ ¦
¦ If an IP Host on a directly connected network sends a datagram ¦
¦ to an IP router for delivery to a device on another network, and ¦
¦ the router knows that a better route to the destination network ¦
¦ exists, then the IP router will send an ICMP Redirect message to ¦
¦ the Host to notify it of the preferred route. The Gateway ¦
¦ Internet Address in the Redirect message is the IP address of ¦
¦ the router that the Host should use to reach the destination ¦
¦ network. Note that router forwards the original packet before ¦
¦ the Redirect message is sent. ¦
±------------------------------------------------------------------+
ECHO REQUEST (Type=8)
±------------------------------------------------------------------+
¦ 0 8 16 24 31 ¦
¦ ±--------------±--------------±------------------------------+ ¦
¦ ¦ Type (8) ¦ Code (0) ¦ Checksum ¦ ¦
¦ ±------------------------------±------------------------------¦ ¦
¦ ¦ Identifier ¦ Sequence Number ¦ ¦
¦ ±--------------------------------------------------------------¦ ¦
¦ ¦ Optional Data ¦ ¦
¦ ±--------------------------------------------------------------¦ ¦
¦ ¦ … ¦ ¦
¦ ±--------------------------------------------------------------+ ¦
¦ The ICMP Echo Request datagram is used to test connectivity. ¦
¦ An Echo Request is sent to a remote device and the remote ¦
¦ device, if active, returns an Echo Reply datagram. ¦
±------------------------------------------------------------------+
TIME EXCEEDED (Type=11)
±------------------------------------------------------------------+
¦ 0 8 16 24 31 ¦
¦ ±--------------±--------------±------------------------------+ ¦
¦ ¦ Type (11) ¦ Code (0-1) ¦ Checksum ¦ ¦
¦ ±--------------------------------------------------------------¦ ¦
¦ ¦ Unused (must be zero) ¦ ¦
¦ ±--------------------------------------------------------------¦ ¦
¦ ¦ Internet Header + first 64 bits of datagram ¦ ¦
¦ ±--------------------------------------------------------------¦ ¦
¦ ¦ … ¦ ¦
¦ ±--------------------------------------------------------------+ ¦
¦ ¦
¦ ±--------------------------------------------------------------+ ¦
¦ ¦ Code ¦ Meaning ¦ ¦
¦ ±-----±-------------------------------------------------------¦ ¦
¦ ¦ 0 ¦ Time-To-Live exceeded ¦ ¦
¦ ¦ 1 ¦ Fragment Reassembly Time Exceeded ¦ ¦
¦ ±--------------------------------------------------------------+ ¦
¦ ¦
¦ Time To Live Exceeded: ¦
¦ ¦
¦ When a route is lost on an internet, the fact that the route has ¦
¦ been lost is not immediately known to all routers on the ¦
¦ internet becaus routing information updates take time to ¦
¦ propagate across the network. During that time, it is possible ¦
¦ for routing loops to exist. A routing loop could cause a packet ¦
¦ to circle the internet endlessly, being forwarded from one router¦
¦ to the next, never able to reach it’s destination. For this ¦
¦ reason, every IP datagram that is transmitted has a Time-to-Live ¦
¦ field in the IP header that specifies how long the datagram ¦
¦ should be allowed to exist on the internet. As the datagram is ¦
¦ processed by a router, the TTL field is decremented. If the TTL ¦
¦ field reaches zero, the packet is discarded by the router. The ¦
¦ router then sends a Time To Live Exceeded message to the ¦
¦ originating Host. ¦
¦ ¦
¦ Fragment Reassembly Time Exceeded: ¦
¦ ¦
¦ When a datagram is fragmented during transit through the internet¦
¦ the destination host must collect the fragments and reassemble ¦
¦ the datagram. When the first fragment of the datagram arrives, ¦
¦ the receiving host starts a timer and considers it an error if ¦
¦ the timer expires before the entire packet is reassembled. When ¦
¦ this occurs, the destination host sends an ICMP Fragment ¦
¦ Reassembly Time Exceeded message to the originating host and ¦
¦ discards the fragment that it received before the timer expired. ¦
±------------------------------------------------------------------+
PARAMETER PROBLEM (Type=12)
±------------------------------------------------------------------+
¦ 0 8 16 24 31 ¦
¦ ±--------------±--------------±------------------------------+ ¦
¦ ¦ Type (12) ¦ Code (0-1) ¦ Checksum ¦ ¦
¦ ±--------------±----------------------------------------------¦ ¦
¦ ¦ Pointer ¦ Unused (must be zero) ¦ ¦
¦ ±--------------------------------------------------------------¦ ¦
¦ ¦ Internet Header + first 64 bits of datagram ¦ ¦
¦ ±--------------------------------------------------------------¦ ¦
¦ ¦ … ¦ ¦
¦ ±--------------------------------------------------------------+ ¦
¦ ¦
¦ ±--------------------------------------------------------------+ ¦
¦ ¦ Code ¦ Meaning ¦ ¦
¦ ±-----±-------------------------------------------------------¦ ¦
¦ ¦ 0 ¦ An incorrect IP Datagram Header was received. ¦ ¦
¦ ¦ 1 ¦ A Required Option was missing in the received ¦ ¦
¦ ¦ ¦ IP datagram. ¦ ¦
¦ ±--------------------------------------------------------------+ ¦
¦ ¦
¦ Pointer: The pointer is used by the CODE 0 option to indicate ¦
¦ which byte of the IP Datagram Header was incorrect. ¦
¦ ¦
¦ The destination host uses the ICMP Parameter Problem message ¦
¦ to notify the sending host that a datagram was received that ¦
¦ contained an incorrect value or option in the IP Header. ¦
±------------------------------------------------------------------+
TIMESTAMP REQUEST/REPLY (Type=13/14)
±------------------------------------------------------------------+
¦ 0 8 16 24 31 ¦
¦ ±--------------±--------------±------------------------------+ ¦
¦ ¦ Type (13/14) ¦ Code (0) ¦ Checksum ¦ ¦
¦ ±------------------------------±------------------------------¦ ¦
¦ ¦ Identifier ¦ Sequence Number ¦ ¦
¦ ±--------------------------------------------------------------¦ ¦
¦ ¦ Originate Timestamp ¦ ¦
¦ ±--------------------------------------------------------------¦ ¦
¦ ¦ Receive Timestamp ¦ ¦
¦ ±--------------------------------------------------------------¦ ¦
¦ ¦ Transmit Timestamp ¦ ¦
¦ ±--------------------------------------------------------------+ ¦
¦ ¦
¦ Type 13 = Request ¦
¦ Type 14 = Reply ¦
¦ ¦
¦ Originate Timestamp: Is filled in by the original sender just ¦
¦ before the packet is transmitted. ¦
¦ ¦
¦ Receive Timestamp: Is filled immediately upon receipt of a ¦
¦ request. ¦
¦ ¦
¦ Transmit Timestamp: Is filled immmediately before the reply is ¦
¦ transmitted. ¦
¦ ¦
¦ Hosts use the three timestamp fields to compute estimates of the ¦
¦ delay time between them and synchronize their clocks. ¦
±------------------------------------------------------------------+
TIMESTAMP REQUEST/REPLY (Type=17/18)
±------------------------------------------------------------------+
¦ 0 8 16 24 31 ¦
¦ ±--------------±--------------±------------------------------+ ¦
¦ ¦ Type (17/18) ¦ Code (0) ¦ Checksum ¦ ¦
¦ ±------------------------------±------------------------------¦ ¦
¦ ¦ Identifier ¦ Sequence Number ¦ ¦
¦ ±--------------------------------------------------------------¦ ¦
¦ ¦ Address Mask ¦ ¦
¦ ±--------------------------------------------------------------+ ¦
¦ ¦
¦ Type 17=Address Mask Request ¦
¦ Type 18=Address Mask Reply ¦
±------------------------------------------------------------------+
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
ICMP ist doch ein einweg Protokoll oder ?
Also müsste es aus diesen Informationen
bestehen:
-Meine IP Addresse
-Mein Quell-Port
-Daten (Message code u. a.)
>Ziel IP
>?? Ziel Port ??so müsste es doch möglich sein, das ich
meine IP „SPOOFE“, also verändere, und
das Packet dann abschicke.
Ich denke viele Serverattacken basieren
darauf, aber wie kann ich das in Win98
machen ?Da wirst Du wohl programmieren muessen.
Ich habe fuer Win noch von keinem
Programm gehoert, mit dem man IP-Adressen
spoofen kann. Ist wohl auch gut so, sonst
fangen alle moeglichen User an, „Tests“
im Netz des eigenen Unternehmens
anzustellen.ICMP ist aehnlich wie UDP „shoot and
forget“, also prinzipiell
Einwegkommunikation.
Was das ICMP-Format angeht, kann ich Dir
helfen (leider verschiebt der
„wer-weiss-was“-Server die Zeichnung -
hoffentlich kannst Du sie noch erkennen):
Erstmals danke für die genaue Beschreibung.
Wenn ich das Modem dirket anspreche, dann
müsste ich ja Spoofen können oder ?
Wenn dies gut geht, dann sollte ein
sicherer Provider dieses Packet doch gar nicht erst durchlassen oder ? Ich meine,
wenn ich eine IP habe die so aussieht:
195.3.95.x.x dann sollte ein Packet mit Source 204.12.40.x.x nicht durchgehen
… zuviele X
195.3.95.x
204.12.40.x
da waren ein x zuviel drann
Mit dem Modem hat das nichts zu tun. Die Adresse ist in Deinem Rechner hinterlegt (wird über das Protokoll PPP übertragen). Das Modem merkt nichts davon, ob PPP, SLIP oder HDLC als Layer-2-Protokoll übertragen wird. Du mußt also Deinen TCP/IP-Stack im Rechner ansprechen.
Ob Dein Provider darauf aufpaßt, hängt von seinem Equipment ab und wie leistungsfähig es ist. Den Routern ist Deine Source-Adresse so gut wie wurscht. Im IP zählt nur die Destination-Adresse. Das bedeutet aber auch, dass wenn Du Deine Adresse wirklich änderst, Du „lediglich“ eine DoS-Attacke (Denial of Service) absetzen könntest. In ein Netzwerk einbrechen kannst Du damit nicht, da Du die Antworten schließlich nicht bekommst (wg. der falschen Source-Adresse).
Damit der Provider das merkt, muss er die Router entsprechend konfiguriert haben und Managementstationen aufgestellt haben, die ungültige Source-Adressen anzeigen. Ich denke, das ist selten der Fall.
Gruss
Stefan
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]