Archief
- De topics van lang geleden
Ethereal
22-11-2006, 18:32 door Anoniem, 19 reacties
Hallo!
Ik had eigenlijk een vraagje als dat zou mogen over netwerk analyze met
ethereal.Want ik vroeg me eigenlijk af hoe je nou de de inhoud van
pakketjes kan bekijken.Ik ben wel zo ver dat ik de tree way handshake
terug kan van vinden als je bv http://www.google.nl intyped.
Maar waneer ik dan het paket selecteerd als:
TCP http ->1313 [ack] seq=1 Ack=285 win=5323 Len=0
En dan op window size: 5323 click zie alleen :
0030 19 20 e6 02 00 00 00 00 00 00 00 00 ba b2 a6 39 .
.............9
Dus vraag me eigenlijk af hoe je nou kan zien welke informatie nou in de
window staat omdat die daar nu alleen een punt weergeeft.Weet iemand
dit misschien?
Ik had eigenlijk een vraagje als dat zou mogen over netwerk analyze met
ethereal.Want ik vroeg me eigenlijk af hoe je nou de de inhoud van
pakketjes kan bekijken.Ik ben wel zo ver dat ik de tree way handshake
terug kan van vinden als je bv http://www.google.nl intyped.
Maar waneer ik dan het paket selecteerd als:
TCP http ->1313 [ack] seq=1 Ack=285 win=5323 Len=0
En dan op window size: 5323 click zie alleen :
0030 19 20 e6 02 00 00 00 00 00 00 00 00 ba b2 a6 39 .
.............9
Dus vraag me eigenlijk af hoe je nou kan zien welke informatie nou in de
window staat omdat die daar nu alleen een punt weergeeft.Weet iemand
dit misschien?
Reacties (19)
22-11-2006, 19:34 door
ctrlaltdelete
Misschien wordt je wat wijzer met Digital Home NetAnalyzer DL
http://www.qualitylogic.com/genoa_test_tools/digital_home/dh_netanalyzer_dl.html
http://www.qualitylogic.com/genoa_test_tools/digital_home/dh_netanalyzer_dl.html
Jah daar lijkt het op "Save the analysis outputs in a unique compressed
file that can be loaded at a later time" zou wel data zijn waar ik na zoek.Thx!
file that can be loaded at a later time" zou wel data zijn waar ik na zoek.Thx!
23-11-2006, 10:37 door
SirDice
Een ACK packet bevat geen data. Het is een ACKnowledge dat het packetje (waar wel data in zat) met sequence nummer 285 is aangekomen.
Wil je echt alles weten over TCP/IP investeer dan in het boek "TCP/IP Illustrated Volume 1" van Stevens. Misschien niet het beste boek om het uit te leren maar van onschatbare waarde als naslagwerk.
Wil je echt alles weten over TCP/IP investeer dan in het boek "TCP/IP Illustrated Volume 1" van Stevens. Misschien niet het beste boek om het uit te leren maar van onschatbare waarde als naslagwerk.
Een ACK packet bevat geen data. Het is een ACKnowledge dat het
packetje (waar wel data in zat) met sequence nummer 285 is aangekomen
packetje (waar wel data in zat) met sequence nummer 285 is aangekomen
Dat ben ik dus nu aan het uitzoeken ben wel zo ver dat waneer je bv
google.nl intyped die eerst een syn stuurd google een syn+ack terug
stuurd en dan die dan weer een ack terug stuurd waarna get http / 1.1
wordt aangevraagd.Maar kan niet de info vinden of nou alleen TCP paket
word verstuurd met het sequence nummer 285 of dat er nog meer
informatie in het paket zit.Zoals bijvoorbeeld bij syn het geval is die de
aanvraag voor ack doet.
Maar denk wel dat ik het boek ga bestellen van TCP/IP illustrated volume 1
van stevens als daar de informatie in staat die precies weer geeft wat er
gebeurd als een three way handshake plaats is het wel de moeite waard
om het boek te kopen.Ik heb al het boek TCP/IP illustrated volume 2 maar
dat is gericht op netwerk applicaties met c wat overigens enorm leerzaam
is.
23-11-2006, 13:22 door
SirDice
Volume 3 gaat overigens over zaken als TLS en wat losse protocollen.. Ze staan alledrie gebroederlijk naast elkaar in m'n, inmiddels uitpuilende, boekenkast ;)
Volume 1 is een absolute aanrader. Zeer gedetailleerd.
Een SYN bevat ook geen informatie, geen data althans (len=0).
Voorbeeld?
Opzetten connectie van client naar server:
C --- SYN (seq=0)(len=0)-------------------+ S
C +-- SYN (seq=0)/ACK (ack=1)(len=0) --- S
C -----ACK (seq=1)(len=0)--------------------+ S
Nu is er een echte TCP connectie en kan er data verstuurd worden...
Client stuurt een opdracht naar de server:
C --DATA(6 bytes)(seq=1)(len=6)------+S
C +-------------------ACK(ack=7)(len=0)---S
Server stuurt een antwoord terug:
C +--DATA(10 bytes)(seq=1)(len=10)---S
C -----------------ACK(seq=11)(len=0)---+S
Je kunt aan de len= zien hoeveel "data" een pakketje bevat. Het sequence nummer van de ACK (ack=) is het sequencenummer (seq=) + de lengte (len=). Hierdoor ziet de verzendende partij dat het pakketje is aangekomen (de ACK) en hoeveel bytes (sequencenummer + length) er ontvangen zijn.
Wat je echter in de praktijk zult zien is dat er en data verstuurd word en tegelijk het vorige ontvangen pakket ge'ACK'ed wordt. Dat is wat efficienter. Wat ook nog mogelijk is is een zogenaamde delayed ACK. Er wordt dan pas een ACK verstuurd nadat er meerdere pakketten zijn ontvangen. Die ene ACK bevestigd dan het ontvangen van meerdere pakketjes. Ook dat wordt gedaan om de efficiëntie te verhogen.
Volume 1 is een absolute aanrader. Zeer gedetailleerd.
Een SYN bevat ook geen informatie, geen data althans (len=0).
Voorbeeld?
Opzetten connectie van client naar server:
C --- SYN (seq=0)(len=0)-------------------+ S
C +-- SYN (seq=0)/ACK (ack=1)(len=0) --- S
C -----ACK (seq=1)(len=0)--------------------+ S
Nu is er een echte TCP connectie en kan er data verstuurd worden...
Client stuurt een opdracht naar de server:
C --DATA(6 bytes)(seq=1)(len=6)------+S
C +-------------------ACK(ack=7)(len=0)---S
Server stuurt een antwoord terug:
C +--DATA(10 bytes)(seq=1)(len=10)---S
C -----------------ACK(seq=11)(len=0)---+S
Je kunt aan de len= zien hoeveel "data" een pakketje bevat. Het sequence nummer van de ACK (ack=) is het sequencenummer (seq=) + de lengte (len=). Hierdoor ziet de verzendende partij dat het pakketje is aangekomen (de ACK) en hoeveel bytes (sequencenummer + length) er ontvangen zijn.
Wat je echter in de praktijk zult zien is dat er en data verstuurd word en tegelijk het vorige ontvangen pakket ge'ACK'ed wordt. Dat is wat efficienter. Wat ook nog mogelijk is is een zogenaamde delayed ACK. Er wordt dan pas een ACK verstuurd nadat er meerdere pakketten zijn ontvangen. Die ene ACK bevestigd dan het ontvangen van meerdere pakketjes. Ook dat wordt gedaan om de efficiëntie te verhogen.
Je kunt aan de len= zien hoeveel "data" een pakketje bevat. Het
sequence nummer van de ACK (ack=) is het sequencenummer (seq=) +
de lengte (len=). Hierdoor ziet de verzendende partij dat het pakketje is
aangekomen (de ACK) en hoeveel bytes (sequencenummer + length) er
ontvangen zijn.
sequence nummer van de ACK (ack=) is het sequencenummer (seq=) +
de lengte (len=). Hierdoor ziet de verzendende partij dat het pakketje is
aangekomen (de ACK) en hoeveel bytes (sequencenummer + length) er
ontvangen zijn.
Dus als ik het goed begrijp dat bij de three way handshake er geen data in
het paket zit vanwege de len steeds 0 aan geeft? Want wat die weer geeft
met ethreal is als je na google surfed is:
127.0.0.1 66.149.85.99 TCP 1374 HTTP [SYN] seq=0 len=0
66.149.85.99 127.0.0.1 TCP HTTP 1374 [SYN,ACK] seq=0 ack=1 len=0
120.0.0.1 66.149.85.99 TCP 1374 HTTP [ACK] seq=1 ack=1
Op vallend is dat de window met [syn,ack] bv win=8290 weer geeft en verdubbeld is bij [ACK] win=64240.Klopt het dan dat win(window) aangeeft hoevel data in len kan ?
23-11-2006, 16:29 door
SirDice
Tijdens de handshake wordt er nooit data verzonden. De connectie is er immers nog niet.. De "connectie" is er pas na de three-way handshake (SYN-SYN/ACK-ACK).
TCP window size
The TCP receive window size is the amount of received data (in bytes) that can be buffered during a connection. The sending host can send only that amount of data before it must wait for an acknowledgment and window update from the receiving host.
http://en.wikipedia.org/wiki/Transmission_Control_Protocol
De maximale hoeveelheid data in een pakketje is afhankelijk van de [url=http://en.wikipedia.org/wiki/MTU_%28networking%29]MTU[/url].
TCP window size
The TCP receive window size is the amount of received data (in bytes) that can be buffered during a connection. The sending host can send only that amount of data before it must wait for an acknowledgment and window update from the receiving host.
http://en.wikipedia.org/wiki/Transmission_Control_Protocol
De maximale hoeveelheid data in een pakketje is afhankelijk van de [url=http://en.wikipedia.org/wiki/MTU_%28networking%29]MTU[/url].
De RFC's van IP, TCP en HTTP zijn naar mijn mening ook best
goed leesbare documenten over hoe het zou moeten werken. Ze
zijn het makkeijkst te vinden door te googlen op
bijvoorbeeld: rfc tcp
Als je de RFC nummers weet kan je ze ook makkeijk bij het
ietf vinden op http://www.ietf.org/rfc.html
goed leesbare documenten over hoe het zou moeten werken. Ze
zijn het makkeijkst te vinden door te googlen op
bijvoorbeeld: rfc tcp
Als je de RFC nummers weet kan je ze ook makkeijk bij het
ietf vinden op http://www.ietf.org/rfc.html
SirDice,
Thx! goeie ilustratie trouwens van het TCP model maar wat ik me nou
eignelijk afvraag is als ik nou een SYN zou sturen na een server en de
server replyed met SYN-ACK deze verwacht dus een ACK van mij maar als
ik nou een SYN terug zou sturen zou die dan weer een SYN-ACK terug sturen of gaat die server dan trippen omdat die wacht op een ACK.
Thx! goeie ilustratie trouwens van het TCP model maar wat ik me nou
eignelijk afvraag is als ik nou een SYN zou sturen na een server en de
server replyed met SYN-ACK deze verwacht dus een ACK van mij maar als
ik nou een SYN terug zou sturen zou die dan weer een SYN-ACK terug sturen of gaat die server dan trippen omdat die wacht op een ACK.
24-11-2006, 10:45 door
SirDice
Door Koekie
Thx! goeie ilustratie trouwens van het TCP model maar wat ik me nou eignelijk afvraag is als ik nou een SYN zou sturen na een server en de server replyed met SYN-ACK deze verwacht dus een ACK van mij maar als ik nou een SYN terug zou sturen zou die dan weer een SYN-ACK terug sturen of gaat die server dan trippen omdat die wacht op een ACK.
Nee, die server gaat niet trippen, althans een goede server niet, bedenk wat er gebeurd als meerdere clients een connectie maken naar de server. Overigens is iemand anders ook al op dat idee gekomen. Kijk eens naar NMap en dan met name de SYN half open scan, beter bekent als de stealth scan.Thx! goeie ilustratie trouwens van het TCP model maar wat ik me nou eignelijk afvraag is als ik nou een SYN zou sturen na een server en de server replyed met SYN-ACK deze verwacht dus een ACK van mij maar als ik nou een SYN terug zou sturen zou die dan weer een SYN-ACK terug sturen of gaat die server dan trippen omdat die wacht op een ACK.
Waarom doe je dat? Na een three-way handshake wordt er een connectie gelogd. Door de handshake niet helemaal af te ronden wordt de connectie niet gelogd. Nmap doet dat door:
N ----SYN--------+ S
N +--SYN/ACK--- S
N ----RST--------+ S
Er is nu geen connectie die gelogd wordt! Als er een volledige three-way handshake geweest zou zijn wel. Waarom is dat interessant? Een open poort stuurt een SYN/ACK terug, een gesloten poort een RST, komt er helemaal niets terug dan zit er waarschijnlijk een firewall tusen. Hey, zo kun je een
poortscan uitvoeren :))
De RST, is niet noodzakelijk, maar wordt gestuurd om te voorkomen dat de server uit z'n resources zou lopen. Voor elke SYN die ontvangen wordt word er wat geheugen gereserveerd. Omdat er nooit een ACK op de SYN/ACK komt
treed er na een tijdje een time-out op. Dan wordt dat geheugen ook weer vrijgegeven. Door heel veel SYN's te sturen zou je een (slechte) server onderuit kunnen halen omdat'ie op een gegeven moment geen geheugen meer vrij heeft (een DoS dus!).
Maar dan kan je eigenlijk toch ook een anti scan programma er voor
geschrijven want neem nou het geval als iemand 65535 services
scant.Dan wordt dus voor 65535 services iedere keer een stukje een
geheugen vrijgemaakt waardoor je een patroon krijgt en ervan uit kan gaan
dat iemand een syn scan aan het uitvoeren is.Of je kan het detecteren
door dat die 65535 keer een time-out weer geeft of zie ik dat nou verkeerd.
geschrijven want neem nou het geval als iemand 65535 services
scant.Dan wordt dus voor 65535 services iedere keer een stukje een
geheugen vrijgemaakt waardoor je een patroon krijgt en ervan uit kan gaan
dat iemand een syn scan aan het uitvoeren is.Of je kan het detecteren
door dat die 65535 keer een time-out weer geeft of zie ik dat nou verkeerd.
24-11-2006, 12:08 door
SirDice
Het is makkelijker om dat met een IDS te doen ;)
Met snort bijvoorbeeld:
http://www.snort.org/docs/snort_htmanuals/htmanual_260/node11.html#SECTION00317000000000000000
Met snort bijvoorbeeld:
http://www.snort.org/docs/snort_htmanuals/htmanual_260/node11.html#SECTION00317000000000000000
Thx voor de site trouwens is leuk om verder in te verdiepen en dingen te
testen.Ben nu bezig een syn aanvraag te programeren en kom steeds een
stukje verder.Maar blijft lastig want loop steeds tegen nieuwe problemen
op/aan.Zo geeft die met:
struct tcphdr hdr;
hdr.source=htons(sport);
hdr.source=htons(dport);
hdr.seq=0
hdr.ack_syn=0;
hdr.syn=1;
Een malformed packet weer onder ethereal.in de header van de andere
computer gaf die aan:
127.0.0.1 127.0.0.2 TCP 5959 > HTTP [Malformed packet]
Nu ben ik er nog niet echt achter waar nu het probleem zit omdat de
hdr.syn=1; wel is gedeclareerd.Maar nergens kan terug vinden in het
packet.Zo geeft bij een gewone syn aanvraag (Flags:0x0002 (syn) .... ..1.
syn:set) weer.Waneer ik nou de hdr.syn=1; verrander na hdr.syn=0x02; blijft
die in het packet weer geven bij flags: 0x04(don't fragment) terwijl de syn
wel is gedeclareerd.
testen.Ben nu bezig een syn aanvraag te programeren en kom steeds een
stukje verder.Maar blijft lastig want loop steeds tegen nieuwe problemen
op/aan.Zo geeft die met:
struct tcphdr hdr;
hdr.source=htons(sport);
hdr.source=htons(dport);
hdr.seq=0
hdr.ack_syn=0;
hdr.syn=1;
Een malformed packet weer onder ethereal.in de header van de andere
computer gaf die aan:
127.0.0.1 127.0.0.2 TCP 5959 > HTTP [Malformed packet]
Nu ben ik er nog niet echt achter waar nu het probleem zit omdat de
hdr.syn=1; wel is gedeclareerd.Maar nergens kan terug vinden in het
packet.Zo geeft bij een gewone syn aanvraag (Flags:0x0002 (syn) .... ..1.
syn:set) weer.Waneer ik nou de hdr.syn=1; verrander na hdr.syn=0x02; blijft
die in het packet weer geven bij flags: 0x04(don't fragment) terwijl de syn
wel is gedeclareerd.
24-11-2006, 16:21 door
SirDice
Let wel.. Het sequence nummer in wireshark (ethereal) wordt standaard relatief weergegeven.. Dat is dus niet het echte sequence nummer.
Vergeet ook de checksum niet, wellicht geeft wireshark daarom aan dat het malformed is?
En in (raw) socket programmeren ben ik niet zo'n ster, je zou de source van bijv. NMap eens kunnen bekijken.. Die bevat vast een hoop interessante code. Of Volume 2 ;)
Vergeet ook de checksum niet, wellicht geeft wireshark daarom aan dat het malformed is?
En in (raw) socket programmeren ben ik niet zo'n ster, je zou de source van bijv. NMap eens kunnen bekijken.. Die bevat vast een hoop interessante code. Of Volume 2 ;)
SirDice,
Heb het trouwens voor elkaar gekregen dat die alleen een syn
verstuurd.Alleen blijft die nog een malformed packet vermelden bij het
packetje.Een groot deel komt al overeen als ik http://www.google.nl in type.Zo
geeft ethereal weer:
127.0.0.1 127.0.0.2 TCP 5959 > http [syn] seq=0[malformed packet]
Transmission Control protocol
Source port : 5959(5959)
Destination port: http(80)
short segment.Segment/framgent does not contain a full tcp header might
be nmap or someone else deliberately sending unusual packets)
sequence number = 0 (relative sequence number)
header length = 28 bytes;
flags:0x0002(syn)
0 = COngestion window reduced (cwr): Not set
0 =ECN-EChO: Not set
0 = Urgent : Not set
0 = Acknowledgement: Not set
0 = push: Not set
0 = Reset: Not set
1 = syn: set
0 = fin: Not set
window size:320
checksum:0x80f3 [validation disabled]
[Malformed Packet: TCP]
Nou vraag ik me af of dit komt door de options die er niet bij staat waneer
ik nou bij de syn kijk van google nl staat er bij options.
options: 8(bytes)
maximum segment size:1460 bytes
nop
nop
SACK permitted
opvallend is namelijk dat bij de header van tcp.h in /usr/include/netinet/tcp.h nergens iets over options staat dan alleen check en urg_ptr.
Heb het trouwens voor elkaar gekregen dat die alleen een syn
verstuurd.Alleen blijft die nog een malformed packet vermelden bij het
packetje.Een groot deel komt al overeen als ik http://www.google.nl in type.Zo
geeft ethereal weer:
127.0.0.1 127.0.0.2 TCP 5959 > http [syn] seq=0[malformed packet]
Transmission Control protocol
Source port : 5959(5959)
Destination port: http(80)
short segment.Segment/framgent does not contain a full tcp header might
be nmap or someone else deliberately sending unusual packets)
sequence number = 0 (relative sequence number)
header length = 28 bytes;
flags:0x0002(syn)
0 = COngestion window reduced (cwr): Not set
0 =ECN-EChO: Not set
0 = Urgent : Not set
0 = Acknowledgement: Not set
0 = push: Not set
0 = Reset: Not set
1 = syn: set
0 = fin: Not set
window size:320
checksum:0x80f3 [validation disabled]
[Malformed Packet: TCP]
Nou vraag ik me af of dit komt door de options die er niet bij staat waneer
ik nou bij de syn kijk van google nl staat er bij options.
options: 8(bytes)
maximum segment size:1460 bytes
nop
nop
SACK permitted
opvallend is namelijk dat bij de header van tcp.h in /usr/include/netinet/tcp.h nergens iets over options staat dan alleen check en urg_ptr.
SirDice,
Weet jij misschien hoe je de source van nmap kan bekijken? Want ben zo
ver gekomen nou dat de geen malformed packet meer weergeeft maar:
127.0.0.1 127.0.0.2 TCP 5959 --+ http [syn] seq=0 len=0
Het enige probleem is nu nog de options en de maximum segment size
en de checksum waar je overigens gelijk in had want deze staat nu nog op
checksum:0x000 wat een hele kluif zou worden denk ik dit werkende te krijgen.Weet jij trouwens of onder linux ook de options worden gebruikt als nop nop SACK permitted ? Dit geeft die namelijk onder windows met ethereal weer.
ps. Wat trouwens grappig is dat die nu geen melding meer weer geeft als
bij die vorige van:
short segment.Segment/framgent does not contain a full tcp header might
be nmap or someone else deliberately sending unusual packets
Weet jij misschien hoe je de source van nmap kan bekijken? Want ben zo
ver gekomen nou dat de geen malformed packet meer weergeeft maar:
127.0.0.1 127.0.0.2 TCP 5959 --+ http [syn] seq=0 len=0
Het enige probleem is nu nog de options en de maximum segment size
en de checksum waar je overigens gelijk in had want deze staat nu nog op
checksum:0x000 wat een hele kluif zou worden denk ik dit werkende te krijgen.Weet jij trouwens of onder linux ook de options worden gebruikt als nop nop SACK permitted ? Dit geeft die namelijk onder windows met ethereal weer.
ps. Wat trouwens grappig is dat die nu geen melding meer weer geeft als
bij die vorige van:
short segment.Segment/framgent does not contain a full tcp header might
be nmap or someone else deliberately sending unusual packets
01-12-2006, 21:33 door
SirDice
Door Koekie
SirDice,
Weet jij misschien hoe je de source van nmap kan bekijken?
Downloaden http://insecure.org/nmap/download.html kopjeSirDice,
Weet jij misschien hoe je de source van nmap kan bekijken?
Source distribution.
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Toezichthouder informatiebeveiliging Overheid
Rijksinspectie Digitale Infrastructuur (RDI)
Vind je het leuk om als toezichthouder bij te dragen aan de verdere groei in informatie-beveiliging van de overheid en in contact te staan met (belangen) organisaties binnen de overheid? Dan kun je komen bouwen aan toezicht op een veilige en betrouwbare Digitale Infrastructuur in Nederland.
Adviseur Informatiebeveiliging
Je bent een belangrijke speler om invulling te geven aan de gemeentelijke ambities op het gebied van informatiebeveiliging. Deze ambities neem jij op in het Informatie-beveiligingsbeleid Gemeente Zoetermeer. Wil je helpen bij het verbeteren van de informatiebeveiliging in Zoetermeer en het versterken van het cyberbewustzijn binnen onze organisatie? Wacht dan niet en kom ons team informatiebeveiliging versterken!
Digital Designer
Ben jij een Grafisch vormgever, UI-designer, Game-artist of gewoon een ‘self-proclaimed creative genius’, die op zoek is naar een leuke en uitdagende baan waarin je al je creativiteit kwijt kan?Je werkt samen met onze developers en UI/UX-designer aan onze Gamified Cybersecurity Challenges welke jij voorziet van de mooiste designs.
Senior Full Stack Developer
Als full stack developer bij Certified Secure maak je de mooiste cybersecurity challenges die onze deelnemers wereldwijd uitdagen en inspireren. Alle challenges zijn gebaseerd op actuele kwetsbaarheden, je komt dus telkens nieuwe technieken tegen, van machine learning tot web assembly, van Swift UI tot GCP.