Difference between revisions of "Summerschool Aachen 2004/Notes"
(→Captured Data from the Lab: - new names: wireshark, tshark) |
m (Reverted edits by Oxudocopaj (talk) to last revision by Tobias) |
(One intermediate revision by one other user not shown) | |
(No difference)
|
Latest revision as of 17:36, 24 November 2010
General Notes about the Summerschool, Aachen, Software, whatever comes to your mind.
Contents
Lab Net
TSocks
If you still have trouble with socks i suggest the tsocks package, works nicely with openssh and apt-get. I guess you already know about proxy enviroment variables. dante is the other LD wrapper for socks.
Proxy ENV
export http_proxy=http://172.17.23.1:3128 export ftp_proxy=http://172.17.23.1:3128
Socat SSH
socat command line to get SSH working I used these commands to access SSH on $REMOTEMACHINE
$ socat TCP4-LISTEN:31228,reuseaddr \ SOCKS4:172.17.23.1:$REMOTEMACHINE:22,socksport=1080 $ ssh localhost -p31228
corkscrew
ilja@nikita:~/corkscrew-2.0%cat ~/.ssh/config ProxyCommand /home/ilja/corkscrew-2.0/corkscrew 172.17.23.1 3128 %h %p ilja@nikita:~/corkscrew-2.0%
dante
(Running on OpenBSD under VMWare, but should work anywhere...)
$ cat /etc/socks.conf # have a route making all connections to loopback addresses be direct. route { from: 0.0.0.0/0 to: 127.0.0.0/8 via: direct command: connect udpassociate # everything but bind, bind confuses us. } route { from: 0.0.0.0/0 to: 172.17.23.0/24 via: direct } route { from: 0.0.0.0/0 to: 0.0.0.0/0 via: 172.17.23.1 port = 1080 protocol: tcp udp # server supports tcp and udp. proxyprotocol: socks_v4 socks_v5 # server supports socks v4 and v5. method: none #username # we are willing to authenticate via # method "none", not "username". }
Note: On Debian/GNU Linux the config file is called /etc/dante.conf
After configuring dante, the "socksify" script can be used to make applications use the SOCKS proxy.
One of the printers has some issues
While I was sniffing my own traffic I noticed some broadcast from some device (which later turned out to be a printer). The remarkable thing about this packet was that the ethernet frame padding wasn't something like "\x00\x00\x00" instead it was some random string. This is probably an etherleak more info on them here.
Then i decided to do an os fingerprint to see what kind of device it was, the coolest piece of info I got from nmap said:
TCP Sequence Prediction: Class=trivial time dependency Difficulty=0 (Trivial joke)
Then I used isnprobe (you can get that from ftp.ubizen.com) to check the isn's more carefully this is the output:
root@nikita:/home/ilja/isnprober-1.02#./isnprober -n 10 137.226.59.140 -- ISNprober / 1.02 / Tom Vandepoel (Tom.Vandepoel@ubizen.com) -- Using eth0:137.226.59.161 Probing host: 137.226.59.140 on TCP port 80. Host:port ISN Delta 137.226.59.140:80 3146095 137.226.59.140:80 3146096 1 137.226.59.140:80 3146097 1 137.226.59.140:80 3146098 1 137.226.59.140:80 3146099 1 137.226.59.140:80 3146100 1 137.226.59.140:80 3146101 1 137.226.59.140:80 3146102 1 137.226.59.140:80 3146103 1 137.226.59.140:80 3146104 1 root@nikita:/home/ilja/isnprober-1.02#
My guess is that the ISN gets incremented by 1 every second.
-- Ilja van Sprundel
Captured Data from the Lab
I used wireshark and tshark to do some analysis of the collected data.
Statistics
- ca. 16h of traffic
- from 2004-09-29 21:59:04 to 2004-09-30 13:55:18
- number of packets: 1876888
- packets/s: 32.713
- Size: 1.6gb