Difference between revisions of "Summerschool Aachen 2004/Notes"

From C4 Wiki
Jump to: navigation, search
m (Reverted edits by Oxudocopaj (talk) to last revision by Tobias)
 
(5 intermediate revisions by 4 users not shown)
Line 1: Line 1:
 +
General Notes about the Summerschool, Aachen,  Software, whatever comes to your mind.
  
 +
= 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 [http://www.atstake.com/research/advisories/2003/a010603-1.txt 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 [[Tools/Tshark|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
 +
 +
 +
 +
[[Category:Summerschools]]

Latest revision as of 17:36, 24 November 2010

General Notes about the Summerschool, Aachen, Software, whatever comes to your mind.

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