[ Pobierz całość w formacie PDF ]
865443 TCP bytes were after window
5804 TCP packets for already closed connection
941 TCP packets were window probes
10847459 TCP packets had ACKs
222657 TCP packets had duplicate ACKs
1 TCP packet ACKed unsent data
1200274739 TCP bytes ACKed
141545 TCP packets had window updates
13 TCP segments dropped due to PAWS
4658158 TCP segments were predicted pure-ACKs
24033756 TCP segments were predicted pure-data
8087980 TCP PCB cache misses
305 Bad UDP header checksums
17 Bad UDP data length fields
23772272 UDP PCB cache misses
MultiNet Buffer Statistics:
388 out of 608 buffers in use:
30 buffers allocated to Data.
10 buffers allocated to Packet Headers.
66 buffers allocated to Socket Structures.
57 buffers allocated to Protocol Control Blocks.
163 buffers allocated to Routing Table Entries.
2 buffers allocated to Socket Names and Addresses.
48 buffers allocated to Kernel Fork-Processes.
2 buffers allocated to Interface Addresses.
1 buffer allocated to Multicast Addresses.
1 buffer allocated to Timeout Callbacks.
6 buffers allocated to Memory Management.
2 buffers allocated to Network TTY Control Blocks.
11 out of 43 page clusters in use.
11 CXBs borrowed from VMS device drivers
2 CXBs waiting to return to the VMS device drivers
162 Kbytes allocated to MultiNet buffers (44% in use).
226 Kbytes of allocated buffer address space (0% of maximum).
Connection closed by foreign host.
[68] ->
Whoa! What was all that?
What we did was telnet to port 15 -- the netstat port-- which on some computers runs a daemon
that tells anybody who cares to drop in just about everything about the connection made by all
the computers linked to the Internet through this computer.
So from this we learned two things:
1) Grande.nm.org is a very busy and important computer.
2) Even a very busy and important computer can let the random port surfer come and play.
So my lady friend wanted to try out another port. I suggested the finger port, number 79. So she
gave the command:
[68] ->telnet grande.nm.org 79
Trying 129.121.1.2 ...
Connected to grande.nm.org.
Escape character is '^]'.
finger
?Sorry, could not find "FINGER"
Connection closed by foreign host.
[69] ->telnet grande.nm.org 79
Trying 129.121.1.2 ...
Connected to grande.nm.org.
Escape character is '^]'.
help
?Sorry, could not find "HELP"
Connection closed by foreign host.
[69] ->telnet grande.nm.org 79
Trying 129.121.1.2 ...
Connected to grande.nm.org.
Escape character is '^]'.
?
?Sorry, could not find "?"
Connection closed by foreign host.
[69] ->telnet grande.nm.org 79
Trying 129.121.1.2 ...
Connected to grande.nm.org.
Escape character is '^]'.
man
?Sorry, could not find "MAN"
Connection closed by foreign host.
[69] ->
At first this looks like just a bunch of failed commands. But actually this is pretty fascinating.
The reason is that port 79 is, under IETF rules, supposed to run fingerd, the finger daemon. So
when she gave the command finger and grande.nm.org said ?Sorry, could not find
"FINGER, we knew this port was not following IETF rules.
Now on may computers they don t run the finger daemon at all. This is because finger has so
properties that can be used to gain total control of the computer that runs it.
But if finger is shut down, and nothing else is running on port 79, we woudl get the answer:
telnet: connect: Connection refused.
But instead we got connected and grande.nm.org was waiting for a command.
Now the normal thing a port surfer does when running an unfmiliar daemon is to coax it into
revealing what commands it uses. Help, ? and man often work. But it didn t help us.
But even though these commands didn t help us, they did tell us that the daemon is probably
something sensitive. If it were a daemon that was meant for anybody and his brother to use, it
would have given us instructions.
So what did we do next? We decided to be good Internet citizens and also stay out of jail We
decided we d beter log off.
But there was one hack we decided to do first: leave our mark on the shell log file.
The shell log file keeps a record of all operating system commands made on a computer. The
adminsitrator of an obviously important computer such as grande.nm.org is probably competent
enough to scan the records of what commands are given by whom to his computer. Especially
on a port important enough to be running a mystery, non-IETF daemon. So everything we types
while connected was saved on a log.
So my friend giggled with glee and left a few messages on port 79 before logging off. Oh, dear,
I do believe she s hooked on hacking. Hmmm, it could be a good way to meet cute sysadmins...
So, port surf s up! If you want to surf, here s the basics:
1) Get logged on to a shell account. That s an account with your ISP that lets you give Unix
commands. Or -- run Linux or some other kind of Unix on your PC and hook up to the Internet.
2) Give the command telnet where is the internet
address of the computer you wnat to visit and is whatever looks phun to you.
3) If you get the response connected to , then surf s up! [ Pobierz całość w formacie PDF ]
zanotowane.pl doc.pisz.pl pdf.pisz.pl ocenkijessi.opx.pl
865443 TCP bytes were after window
5804 TCP packets for already closed connection
941 TCP packets were window probes
10847459 TCP packets had ACKs
222657 TCP packets had duplicate ACKs
1 TCP packet ACKed unsent data
1200274739 TCP bytes ACKed
141545 TCP packets had window updates
13 TCP segments dropped due to PAWS
4658158 TCP segments were predicted pure-ACKs
24033756 TCP segments were predicted pure-data
8087980 TCP PCB cache misses
305 Bad UDP header checksums
17 Bad UDP data length fields
23772272 UDP PCB cache misses
MultiNet Buffer Statistics:
388 out of 608 buffers in use:
30 buffers allocated to Data.
10 buffers allocated to Packet Headers.
66 buffers allocated to Socket Structures.
57 buffers allocated to Protocol Control Blocks.
163 buffers allocated to Routing Table Entries.
2 buffers allocated to Socket Names and Addresses.
48 buffers allocated to Kernel Fork-Processes.
2 buffers allocated to Interface Addresses.
1 buffer allocated to Multicast Addresses.
1 buffer allocated to Timeout Callbacks.
6 buffers allocated to Memory Management.
2 buffers allocated to Network TTY Control Blocks.
11 out of 43 page clusters in use.
11 CXBs borrowed from VMS device drivers
2 CXBs waiting to return to the VMS device drivers
162 Kbytes allocated to MultiNet buffers (44% in use).
226 Kbytes of allocated buffer address space (0% of maximum).
Connection closed by foreign host.
[68] ->
Whoa! What was all that?
What we did was telnet to port 15 -- the netstat port-- which on some computers runs a daemon
that tells anybody who cares to drop in just about everything about the connection made by all
the computers linked to the Internet through this computer.
So from this we learned two things:
1) Grande.nm.org is a very busy and important computer.
2) Even a very busy and important computer can let the random port surfer come and play.
So my lady friend wanted to try out another port. I suggested the finger port, number 79. So she
gave the command:
[68] ->telnet grande.nm.org 79
Trying 129.121.1.2 ...
Connected to grande.nm.org.
Escape character is '^]'.
finger
?Sorry, could not find "FINGER"
Connection closed by foreign host.
[69] ->telnet grande.nm.org 79
Trying 129.121.1.2 ...
Connected to grande.nm.org.
Escape character is '^]'.
help
?Sorry, could not find "HELP"
Connection closed by foreign host.
[69] ->telnet grande.nm.org 79
Trying 129.121.1.2 ...
Connected to grande.nm.org.
Escape character is '^]'.
?
?Sorry, could not find "?"
Connection closed by foreign host.
[69] ->telnet grande.nm.org 79
Trying 129.121.1.2 ...
Connected to grande.nm.org.
Escape character is '^]'.
man
?Sorry, could not find "MAN"
Connection closed by foreign host.
[69] ->
At first this looks like just a bunch of failed commands. But actually this is pretty fascinating.
The reason is that port 79 is, under IETF rules, supposed to run fingerd, the finger daemon. So
when she gave the command finger and grande.nm.org said ?Sorry, could not find
"FINGER, we knew this port was not following IETF rules.
Now on may computers they don t run the finger daemon at all. This is because finger has so
properties that can be used to gain total control of the computer that runs it.
But if finger is shut down, and nothing else is running on port 79, we woudl get the answer:
telnet: connect: Connection refused.
But instead we got connected and grande.nm.org was waiting for a command.
Now the normal thing a port surfer does when running an unfmiliar daemon is to coax it into
revealing what commands it uses. Help, ? and man often work. But it didn t help us.
But even though these commands didn t help us, they did tell us that the daemon is probably
something sensitive. If it were a daemon that was meant for anybody and his brother to use, it
would have given us instructions.
So what did we do next? We decided to be good Internet citizens and also stay out of jail We
decided we d beter log off.
But there was one hack we decided to do first: leave our mark on the shell log file.
The shell log file keeps a record of all operating system commands made on a computer. The
adminsitrator of an obviously important computer such as grande.nm.org is probably competent
enough to scan the records of what commands are given by whom to his computer. Especially
on a port important enough to be running a mystery, non-IETF daemon. So everything we types
while connected was saved on a log.
So my friend giggled with glee and left a few messages on port 79 before logging off. Oh, dear,
I do believe she s hooked on hacking. Hmmm, it could be a good way to meet cute sysadmins...
So, port surf s up! If you want to surf, here s the basics:
1) Get logged on to a shell account. That s an account with your ISP that lets you give Unix
commands. Or -- run Linux or some other kind of Unix on your PC and hook up to the Internet.
2) Give the command telnet where is the internet
address of the computer you wnat to visit and is whatever looks phun to you.
3) If you get the response connected to , then surf s up! [ Pobierz całość w formacie PDF ]