allemaal leuk en wel al da artikeltjes, maar zou het niet fijn zijn als iemand
ze kon vertalen naar nederlands???? het zou erg fijn zijn als iemand dat kon
doen , webmaster misschien??

Ehmmm als je ze niet in de originele taal kunt lezen hoor je ook niet echt tot
de doelgroep.....

1ste alinea vertaald via: http://dictionary.reference.com/translate/text.html

IP spoofing is the most exciting topic you will hear wannabe hackers talking
about. It is also a subject about which no one knows much. Before we
continue I would like to tell you that IP Spoofing is quite difficult to understand
and a lot of people have trouble understanding how it is done. The other
downside it has is the fact that it can almost not be done using a Windows
system and a system administrator can easily protect his system from IP
spoofing IP Spoofing is a trick played on servers to fool the target computer
into thinking that it is receiving data from a source other than you. This in turn
basically means to send data to a remote host so that it believes that the
data is coming from a computer whose IP address is something other than
yours. Let's take an example to make it clear.

Ip het voor de gek houden is het opwindendste onderwerp u wannabe
hakkers zult horen sprekend over. Het is ook een onderwerp waarover
niemand veel kent. Alvorens wij verdergaan zou ik u willen vertellen dat IP
het Voor de gek houden vrij moeilijk is te begrijpen en heel wat mensen
probleem begrijpend hebben hoe het wordt gedaan. Andere downside het
heeft is het feit dat het bijna kan worden gedaan niet gebruikend een
systeem van Vensters en een systeembeheerder zijn systeem tegen IP voor
de gek houdenip Voor de gek houden kan gemakkelijk beschermen is een
truc die op servers aan dwaas de doelcomputer wordt gespeeld in het
denken dat het gegevens uit een bron buiten u ontvangt. Dit betekent
beurtelings fundamenteel om gegevens naar een verre gastheer te
verzenden zodat het gelooft dat de gegevens uit een computer komen het
waarvan IP adres iets buiten van u is. Neem een voorbeeld om het duidelijk
te maken.

Gelukkig is het sequence number guessing niet meer zo eenvoudig als
weergegevn in het algoritme in het artikel :

Thus, from the above sections we can conclude that the sequence number
gets incremented in the following cases and manners:

Cases Increment

Transfer of FIN Packet 1
Transfer of SYN Packet 1
Transfer of ACK Packet 0
Transfer of SYN/ACK Packet 1
Transfer of FIN/ACK Packet 1
Passage of 1 second 128,000
Establishment of 1 connection 64,000

Doe maar eens een NMAP scan op een willekeurige host. Er wordt dan
ook een analyse gedaan van seq. numer increments...indien simpel staat
er easy indien moeilijker tot bv very difficult.

Bovendien is het een koud kunstje om op een W2K bak je Source ip en /of
je MAC adres te spoofen (Cain bv.)

Mocht het nog niet duidelijk zijn: Eigenlijk komt het er op neer dat je iets
verstuurt met een vals afzendersadres. De geaddresseerde zal dus in het
afzendadres een vals adres aantreffen.

Reageren op zulke mailtjes zal tot gevolg hebben dat degene wiens adres is
misbruikt (als afzendadres) door degene die een adres spooft de reactie
ontvangt. Al ooit een automatische reactie van een virusscanner ontvangen
die zegt dat het door jouw verzonden mailtje een virus bevat, terwijl jij zeker
denkt te weten dat je niets verzonden hebt aan dat adres?

In dat geval kan het zijn dat:
(a) je computer besmet is met een virus, of
(b) een virus zichzelf verzonden heeft met jouw adres als afzender (spoofing).

nou snap ik het!

Het artikel klopt zelfs niet eens op sommige plekken..
neem bijvoorbeeld dit:

1. REAL sends a SYN packet to VICTIM.
2. VICTIM sends back a SYN/ACK packet to REAL.
3. REAL acknowledges this by replying with a SYN packet.

de 3e manier van communiceren is niet SYN maar ACK
daar staat ACKnowledge voor ...

Tis ook best wel jatwerk:
http://neworder.box.sk/newsread.php?newsid=3825

Ja idd :) whehe
ik wist ook niet dat NACK bestond zo ver mijn kennis gaat
heeft ie het over RST :P

The NACK option:

A new NACK option would be defined which contained a 32 bit
OFFSET field from the ACK field of the message it is contained
in, a 32 bit LENGTH field, and a 32 bit SACKED field which
contains the total number of unacknowledged bytes in the
receivers buffer.

The receiver would keep track of the most recent hole in its
receive buffer and if a threshold number of packets beyond this
hole were received it would send out a NACK for that hole. The
current hole pointer would then be moved to the next hole in
the receive buffer (if any). The NACK would contain the offset
and length of the hole and the total number of unacknowledged
bytes in the buffer.

The sender upon receiving a NACK would:
1. Cut the congestion window by 1/2 (al la Reno)
2. Set variable sacked equal to SACKED field in NACK option.
3. Use min(snd_wnd, cwnd+sacked) as the effective window size.
4. Retransmit the offending segment (or segments).
5. Set retransmission timer to at least 1 RTT.

The net effect of this change is that retransmission is now
primarily the responsibility of the NACK option. Time-outs
should only occur when NACKs or re-transmitted segments are
lost. The actual algorithm is quite similar to Reno.

The primary advantage of this approach is that it is simpler
and a much smaller source delta of the existing TCP
implementations. The sender keeps no additional information
beyond the sacked variable. The receiver needs only to keep
track of the oldest hole in its receiver buffer and the total
number of unacknowledged bytes.

A secondary advantage is that only one NACK entry is needed.
The original SACK option was based upon the assumption that
at least 6 sacked ranges were required. As far as I can tell the
need for multiple ranges is eliminated by sending the SACKED
field. In particular if one resets the transmission timer there
appears to be no need for the sender to keep track of exactly
which segments are in the receivers buffer. If no re-transmitted
segments or NACKs are lost no unnecessary re-retransmits
will be performed. (Even if a retransmit is lost the Tahoe
algorithm with prevent and serious duplicate retransmissions.)

If desired dropped NACK's can be handled by having the receiver
send NACKs whenever it would previously send duplicate ACKs
and/or by sending the n most recent holes in the NACK where n
is some small threshold.

There is no way to really detect a dropped retransmit which
would cause the original Tahoe TCP congestion control algorithm
to be invoked. IE the congestion window would be decreased to
one segment and slow start would be invoked to fill the pipe. I
don't think this is a problem because if you lost a segment and
its retransmission you are probably experiencing sever
congestion and want to take sever corrective action anyway.
The sender resetting the retransmit timer will however result
in an extra round trip delay in such case (which should be rare).

zet er de nieuwste sygate maar eens op je pc dan zijn ze zo uit gespooft
versie 5.5 zit alles op die eikels de gene die mijn pc krackt moet nog geboren
worden .luister mij spoofen ze all 2 jaar op mijn mac en op mijn ip adres.der
is nog nooit niet een persoon die dat ooit gelukt is.op de nieuwste software
van sygate versie 5.5 zit anti ip spoofing op en anti mac spoofing gaat zo
maar door probeer hem maar eens .ik heb er van alle soorten firewalls all op
gehad als norton maar die hackers zetten hem vlot uit je norton firrewall oooo
wat is die goed zeg norton 2 keer niks eene grote bout op zijn tilburgs gezegt
voor mij is sygate den beste firewall die er is echt raad ik iedereen aan. de
groeten uit tilburg .....................

'hihi'

Ben jij dan zo'n expert. Als je dat dan al bent moet je niet zo neerbuigend
doen tegen diegene die wat minder bekwaam zijn. Maar een inhoudelijk
antwoord op dit forum geven. In mijn opzicht hoor jij dan niet thuis bij de
doelgroep waar wij van gebruik kunnen/willen maken.

Enig idee hoe ik dan mn IP kan veranderen?