Kramses blog

IPv6 is coming, except in Denmark?

Thu, 1 Jul 2010 08:06:04 +0200

IPv6 is coming, no doubt.

The level of interest at tech news sites like Version2.dk is growing - search for IPv6. The danish Science Minister Charlotte Sahl-Madsen was reported this week for talking about IPv6 (terrible article but hey, interest)

But still the level is nowhere close to being enough. So lets get started, push IPv6 now!

Why push IPv6

It has gained momentum - enough that it will be the new version
Making the transition will require some thought - better be preparing now, instead of having to quickly add IPv6
Keep transition period short - yeah yeah, we will have IPv4 on the big internet for 10+ years, but no way in hell am I going to do dual stacking for so long.

I have started to run IPv6 in production at home for some years, but now I am also running IPv6 in production at our company Solido Networks and I will probably switch IPv6 on by default for new customers. The old customers will soon get statistics about how many clients are asking for IPv6 AAAA records when doing lookups, and then they can select for themselves when they want to add AAAA.

My goal will be to enable everything for IPv6 this year, and probably start turning IPv4 off on the inside next year. We have devices that can still serve users using IPv4, even if the inside is becoming IPv6-only.

What are others doing?

This is just a quick examples, you can sign up for a newsletter at The IPv6 portal newsroom for more news about IPv6.

this one I got from QpoX on IRC and it is very nice, T-Mobile is pushing IPv6. Hard.

"T-Mobile USA makes heavy use of NAT44 and bogon addresses. Going forward, this isn't sustainable. So they've decided that future cellular deployments will be IPv6-only, with NAT64 to access the "legacy" IPv4 Internet (slides | video)."

Wauw, they are going for the full monty, so why are Denmark so far behind?

So my proposal now to you is, ask for IPv6 whenever you buy equipment, demand IPv6 when you get new devices - you are going to be using those devices for some years right?

In fact I kicked Juniper twice yesterday - because their line of SSL VPN appliances does NOT support IPv6. Yeah, thats right - I will NOT buy devices in 2010 that does not support IPv6, and I dont think you should either. What is even worse is that I cannot seem to find any information about plans to support IPv6 on those specific Juniper devices.

In other news I know that the Cisco ASA line does support IPv6 in their VPN.

Get started

OK, lets say I have convinced some of you to look at IPv6, how to get started. This is a short list, but should be enough for a start:

Ask your ISP for IPv6, show them you care - create demand
Get IPv6 - go to tunnelbroker, SixXs or Hurricane Electric are both recommended
or use 6to4 - Uni-C has a 6to4 gateway so performance can be great, if you are close to it.
Buy the O'Reilly book IPv6 Network Administration by Niall Richard Murphy, David Malone (no we dont get proceeds :-) )
Join us! Join the mailinglist on this site and at Digitaliser.dk IPv6 i Danmark

The book of Xen, review

Thu, 24 Jun 2010 09:22:13 +0200

The book of Xen: a practical guide for the system administrator by Chris Takemura and Luke S. Crawford

ISBN: 978-1593271862

Paperback: 312 pages

Publisher: No Starch Press October 8, 2009

Review by Henrik Lund Kramshoej, hlk@kramse.org

June 2010

Practical use and short cut to running Xen quickly.

Content

This book is a how-to and a Xen guru standing behind you guiding you into the wonderful world of the Xen hypervisor.

Beginning from a nice and readable overview of virtualization technologies and the Xen hypervisor it goes through every major component of a Xen installation.

The second chapter begin with installing Xen without too much detail and then quickly allows you to run a Xen environment - getting your feet into the matter immediately. Further it quickly in chapter 3 moves into the various ways you can start creating and installing virtual systems in very different ways - using easy tools, quick and dirty tools and the right ways to install systems - named domU's.

The result of the first three chapters, if you follow instructions and read the 40 pages - you will have Xen running. Wauw that was fun and in itself a feat. The next chapters 4,5,6 are dedicated to providing more nuts and bolts to explore the storage areas, networking options available and management tools available for Xen - required reading if you expect to run Xen in production.

Running Xen in production also requires you to have expert knowledge and chapter 7, 9 and 10 contains exactly the experience from the authors, which will save a lot of your time. Since the authors have also tried Xen with other Unix-like operating systems and running various OS under Xen they give good advise to some pitfalls, and what is possible with Xen. Since this is a moving target the content in this areas will vary according to the releases of these operating systems, but an overview is always welcome. A short chapter 11 is also included outlining the possibilities for getting a support, commercial version of Xen Citrix XenServer.

The remaining chapters and appendixes not listed above are tips and tricks for running Xen and reference documentation allowing you to quickly find the bits you need to tune your Xen installation.

Target audience

Focus of this book is about guiding a Linux system administrator into the world of Xen. This target audience will quickly feel at home by being pointed in a specific direction in the first chapters and then having all the options presented afterwards. The compressed version of all the existing material regarding Xen will allow even a busy administrator to pick up the book and install a Xen server while the advanced chapter will allow them to change bits and pieces later.

If you are an absolute beginner you will need to read more information about installing the example CentOS - but you will be able to get a running Xen server in a short while.

Practical book

The structure of this book is very workbook-like and encourages you to run the many examples and experiment while doing them. Each one of the labs can also be performed in a short while allowing you to make use of short breaks from other stuff and do these.

The books does not have a lot of pages, but a lot of insight and the author clearly has great knowledge and experience in the reverse engineering arena. He also brings you up to speed by allowing you to start running the programs immediately, and while they run you can read the manuals how to do more advanced stuff by yourself later :-)

The techniques and methods described will also allow you to dive into programs that are not meant for debugging, because the author describes how to attack programs - while manuals typically tell you what options you have, but not the situations you should use those options.

To summarize the Good stuff

Short - this book is short, so you can actually finish it
Practical - using the procedures described you will easily get some things running
Complete - this book is very complete in that it describes enough for you to use Xen

The Bad stuff about this book

The subject of Xen and virtualization move very quickly so by the time you have finished the book there will probably be more features available in the world of Xen. The good part though is that you have an understanding of the basics, to allow you to learn the rest for yourself.

Conclusion

This book is very recommended if you like me have a hard time getting started with Xen. The book outlines the steps for an easy start and give you in depth basic knowledge of Xen. Even if the book is published years ago the advise is sound and enough to get you started using Xen.

I noticed that some updates are available, but I don't think I really needed them while installing my Xen setups - I did a few to make use of more of the book :-)

Juniper SRX210 Junos 10.2 flow based IPv6 forwarding

Wed, 2 Jun 2010 11:50:46 +0200

I have previously talked about Juniper SRX and IPv6 forwarding, where it is possible to get them to forward IPv6 packets. In packet-based mode:

[edit security forwarding-options]
hlk@bender# show
family {
    inet6 {
        mode packet-based;
    }
}

I was thus very interested when I got hold of the release notes for JUNOS 10.2 which told about flow-based forwarding. I downloaded the 10.2 relase and upgraded my small testsystem which is a SRX210B - low memory model. It needed some cleanup to free space, and update went smoothly - but slowly! Good dammmmmn slow!

But sorry, getting ahead of myself here. To change your SRX device into flow-based go to security and forwarding options:

[edit security forwarding-options]
hlk@bender# set family inet6 mode flow-based
[edit security forwarding-options]
hlk@bender# exit
[edit]
hlk@bender# commit
warning: You have enabled/disabled inet6 flow.
You must reboot the system for your change to take effect.
If you have deployed a cluster, be sure to reboot all nodes.
commit complete
[edit]

Then reboot using:

hlk@bender# exit 
Exiting configuration mode

hlk@bender> request system reboot 
Reboot the system ? [yes,no] (no) yes 

Shutdown NOW!
[pid 1274]

hlk@bender>                                                                                
*** FINAL System shutdown message from hlk@bender ***                        
System going down IMMEDIATELY

and you are done - and have an IPv6 capable firewall :-)

I will suggest that you try to change this option immediately after upgrading, so consider this post a heads-up for that :-) Especially since it takes about 5 minutes from reboot requested until system is running again - maybe my configuration is somehow borken?!

work work work 2010 is busy!

Wed, 28 Apr 2010 10:59:32 +0200

Wauw its been a while!

I will start blogging RSN, so watch out - just checking that everything is still running smoothly with the Ecto blog editor.

I have a few book reviews, done - but not posted

i have done a lot of amazing stuff lately, ok maybe not epic - but funny things that I would like to share.

Tonight is also DNSSEC at BSD-DK, so maybe we will meet?

Ohh and BTW, communication from me on blog, twitter, company homepage, etc. is going to be in english from now on. Tired of writing things in two languages!

DNSSEC in your BIND

Sat, 9 Jan 2010 12:56:23 +0100

This is a blog entry I have wanted to write for so loooong, and why didn't I?

Perhaps because I thought it would be hard and complex, but it isn't hard to DNSSEC enable your resolving/caching nameserver!

Luckily for me Tykling has done all the hard work and thus I asked him and he helped me :-)

So this entry is a 3..2..1 step to DNSSEC enabling your resolving/caching BIND DNS server, mine runs on OpenBSD with the built-in chrooted BIND, so the config is in /var/named/etc/named.conf and the resulting parts are:

Step 1 - enable DNSSEC

To enable DNSSEC then add option dnssec-enable yes, *doh* sounds easy and it is!

But Since DNSSEC is not implemented on all domains and TLDs there is a DNSSEC Look-aside Validation which can be enabled, and you can read more about it at ISC.org. To use it in BIND just add the DNSSEC options for DLV also, and my options in named.conf became:

options {
        random-device "/dev/random";
        directory "/";
        //listen-on    { any; };
        listen-on    { 10.0.42.1; };
        listen-on-v6 { any; };
        version "";     // remove this to allow version queries
        allow-query { any; };
        //allow-recursion { clients; };
        allow-recursion { localnets; }; 
        
        #dnssec stuff
        dnssec-enable yes;
        dnssec-validation yes;
        dnssec-lookaside . trust-anchor dlv.isc.org.;
};

Remember to also add the DLV key:

trusted-keys {
        dlv.isc.org. 257 3 5 "BEAAAAPHMu/5onzrEE7z1egmhg/WPO0+juoZrW3euWEn4MxDCE1+lLy2 brhQv5rN32RKtMzX6Mj70jdzeND4XknW58dnJNPCxn8
+jAGl2FZLK8t+ 1uq4W+nnA3qO2+DL+k6BD4mewMLbIYFwe0PG73Te9fZ2kJb56dhgMde5 ymX4BI/oQ+cAK50/xvJv00Frf8kw6ucMTwFlgPe+jnGxPPEmHAte/URk Y6
2ZfkLoBAADLHQ9IrS2tryAe7mbBZVcOwIeU/Rw/mRx/vwwMCTgNboM QKtUdvNXDrYJDSHZws3xiRXF1Rf+al9UmZfSav/4NWLKjHzpT59k/VSt TDN0YUuWrBNh";
};

Step 2 - enable logging and reload

Then I recommend adding/changing your logging, to see if it all is okay - remember to turn off logging you dont want afterwards!

logging {
        category lame-servers { null; };
        #category "default" { default_log; };
        category "default" { null; };
        category "general" { null; };
        category "resolver" { null; };
        category "queries" { null; };
        #category dnssec { dnssec_log; };
        category dnssec { null; };
        category "unmatched" { null; };
        category "notify" { null; };
        category "xfer-out" { null; };
      channel default_log {
            syslog local5;
            print-category yes;
            print-severity yes;
            severity debug 3;
      };
      channel dnssec_log {
            syslog local5;
            print-category yes;
            print-severity yes;
            severity debug 3;
      };

};

This concludes changes to BIND config, and you can reload - using rndc reload is the recommended way. If you haven't configured rndc then do that while you are messing with BIND :-) Information about rndc, rndc-confgen etc. can be found in the official BIND documentation.

I also had to flush before it worked for me, so please do a rndc flushname isc.org before doing the testing :-)

Step 3 - testing with dig +dnssec

Testing can be done using dig and isc.org, such as: dig +dnssec isc.org which should return something like this - note the flags: qr rd ra ad

hlk@bigfoot:hlk$ dig +dnssec isc.org

; <<>> DiG 9.6.0-APPLE-P2 <<>> +dnssec isc.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6172
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 6, ADDITIONAL: 15

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;isc.org.			IN	A

;; ANSWER SECTION:
isc.org.		5858	IN	A	149.20.64.42
isc.org.		5858	IN	RRSIG	A 5 2 43200 20100204224723 20100105224723 8496 isc.org. dlNvDaFZz5j+t5ofBf3qxXzGBuU4GcSXp8CG88VNV0Gq6jQ1q9i3JR8v DAltKQDrqU4HF0Lb4j6esDG0LchxDPtKkSsXSOK7kkWKyHOAH6PyZJV7 pnHkPbTi34/JVeAIQbtTsBKVgpCDWRZQf+n+XRXJLeXR+J8YEmYZbaw1 byA=
isc.org.		5858	IN	RRSIG	A 5 2 43200 20100204224723 20100105224723 60726 isc.org. qPCMrR7ZU9m5I6YRWpkZAaOG2tuROiTpNUHEYfDTv6OefvZ+Gza8LnzL 1jc4FloQ7QnoD77yRWFX4kb2tHTL2UtwecxGDdNdlXJz+plvkkkNzoZQ ZmFcPIQyI7HgseEU7CDQti/SCOKQauy5b/C9/vyNTYdI3eUAUxFuMchn 7+4=

;; AUTHORITY SECTION:
isc.org.		85058	IN	NS	sfba.sns-pb.isc.org.
isc.org.		85058	IN	NS	ns.isc.afilias-nst.info.
isc.org.		85058	IN	NS	ams.sns-pb.isc.org.
isc.org.		85058	IN	NS	ord.sns-pb.isc.org.
isc.org.		41858	IN	RRSIG	NS 5 2 43200 20100204224723 20100105224723 8496 isc.org. kunUxOBMfD3KKzz+KSKcPBUH4MpP0bsDAf/sDrm46TdOgnAhAIwUsIyX 5Fmu4zZq+98SJvinGZBqZRL6PNkIXpgAdA8veQkfXmrI+15j9lt2rLCA 9nqpTI1pNpYcQn9xwa6LaZff3Iczwgp+nuk1K3QNA7nDbxvoT/WVy66p tkE=
isc.org.		41858	IN	RRSIG	NS 5 2 43200 20100204224723 20100105224723 60726 isc.org. ULyIuNNZuwbEYPJARrqODsz4p8NNevFlcNSFa7cH5py/Z5ryh7somzv/ F4RsYWNcjMIHwXIWuocBOJuPItd4o6ScAxZhZWqVU2JktPENTYK8DeH5 MRlIZ9ybbNNQTJOsoboBSqdLfsKxqJpVHWbD/bYY4wk1piIvU2FWyU1+ LCQ=

;; ADDITIONAL SECTION:
ns.isc.afilias-nst.info. 83696	IN	A	199.254.63.254
ns.isc.afilias-nst.info. 83696	IN	AAAA	2001:500:2c::254
ams.sns-pb.isc.org.	83696	IN	A	199.6.1.30
ord.sns-pb.isc.org.	83696	IN	A	199.6.0.30
sfba.sns-pb.isc.org.	83696	IN	A	149.20.64.3
sfba.sns-pb.isc.org.	40496	IN	AAAA	2001:4f8:0:2::19
ams.sns-pb.isc.org.	40496	IN	RRSIG	A 5 4 43200 20100204224723 20100105224723 8496 isc.org. Xy6vkzeaEyCDLKsd6j8e3cdoNjSRcRAz62j1+6+UskWMjK2KA7sTiGDL MqYqQmclPB+T5RTKEG8yp/EJajlJ4YfTHI9FAJ6ZVlY9gnMhGxlt4nXc oB0wG4NYjWWk0htXK3c3AFNDTKon/hjC/1ADVf3jQ8f3L7hyYR/GONi8 nnM=
ams.sns-pb.isc.org.	40496	IN	RRSIG	A 5 4 43200 20100204224723 20100105224723 60726 isc.org. rr1JzQ0CmcShnEgWcvQWmwcLrJ5w+YrPDBfyKW2KDnWlF/PlMhgZ1dZG WkuMdy5W7ctEBQIFaONsOhqmkmBv+qpuns0Zi7UvHLic5Ue4ejEqRXRg 9T+AfwAC9mhsSKqVk++mk9CsvVWS5IAuInp1RjrSnKSN40h1nLxqB1Gu P2U=
ord.sns-pb.isc.org.	40496	IN	RRSIG	A 5 4 43200 20100204224723 20100105224723 8496 isc.org. tyYY1ai9P8RF5W0Uh77TDvK7EP9wQhZvI3SiKpqyBFUZFZgconO9RT4m WFpA/qMjyOZkQpiF2XYrLnhB/inom0oPoP3bEtmz/bGGfuA3+A37Xt4O +0wlP4dUABbRiVfZaq0OLLgGuARb3MId/0U0nfOZzEI2HE8XJ6CU1lfr 3wQ=
ord.sns-pb.isc.org.	40496	IN	RRSIG	A 5 4 43200 20100204224723 20100105224723 60726 isc.org. Nh30w6C2qdo/4i+SGgAZTVTO3DgS26VaqNKn4D22F3XMzaB/NUKHTmfV CQAHcP2H1Nhe4wKpBT5dgA5V3mVy8AQx3hqUIM8v0sC30+wA2cWo21W2 WiM+JMRvgnVUPsakf3cC/4mnkCMaCtOAz1qCp/YejW/o4oQw/JElcB+Z opk=
sfba.sns-pb.isc.org.	40496	IN	RRSIG	A 5 4 43200 20100204224723 20100105224723 8496 isc.org. UtMbLiGx6wYueq1BKK2xxqRzwMFG5mGhEbRedebCN/9xIffNddXejgjB 7M5K7t3Lnw4xbuLUS6a4QXp1HeEjs0/ZvSSe8/SQ2F4ss5kXltsqB0Uw NAofTaKVt29sHKFbeCR9jQZQ5veSAYA2SIRuiMU0Xo2zYHCEQS8sJ0wp ORs=
sfba.sns-pb.isc.org.	40496	IN	RRSIG	A 5 4 43200 20100204224723 20100105224723 60726 isc.org. sB1jkBcC0Q2+aeUwKU7QtIX1iGpmykDCYKqjKg28iZyMkfDG/YQUexh7 qZyZWzggWK/uhMNbV2yI4MtLpr4cdlO+f6b6lsXOA5p2BAMo3xkC+4a+ w6tm1jUZKvUOwPIqGlokiP80GKa27XqqRi/2/MqbuypbmhkH0NIUMUfc N4g=
sfba.sns-pb.isc.org.	40496	IN	RRSIG	AAAA 5 4 43200 20100204224723 20100105224723 8496 isc.org. ksZMMvnO8DliFjtXOiB2Qa6+n000DA/glF+qsxG/3Pd7y4j70UY8XjGB mJunm2jsDK6JsXdVDIGZK4qErE0sWDCj0kYoL9nkOPbB/PGVsfMpJ57f ZSc5OcOFunevHkoq/Q3ptTNxI+OrVIMVI+IKqtr8FsCyP4aCKBh6D84I GhU=
sfba.sns-pb.isc.org.	40496	IN	RRSIG	AAAA 5 4 43200 20100204224723 20100105224723 60726 isc.org. puTPShhX8KT7ufaPNkRPVjli2Iavnayn86ygUdIpsTisQYf72Gj63yTc NC46hiz7rXOgE5DizNj22UFKJWjhDuCBPGTYB7OEDVShLZglJeqfWfxt 2DRK7cvweORlUT7spPam8d0AmoioUOwe/drwbWPnNg7jW7Z8oiPPb74E ZcE=

;; Query time: 12 msec
;; SERVER: 10.0.42.1#53(10.0.42.1)
;; WHEN: Sat Jan  9 15:42:12 2010
;; MSG SIZE  rcvd: 2275

Thats all, and copy pasting the blog entry took longer than actually doing it :-) Thanks to Tykling, now I will go bother him to help me get a domain configured with DNSSEC.

PS since there are some problems with firewalls and filtering of IPv6 fragments .org domains don't work after doing above - Tykling has a workaround for PF YMMV and expect another blog entry later about that.

Juletip 12: SYN scan IPv6 with scapy

Mon, 14 Dec 2009 17:57:20 +0100

Så er der blevet tid til at skrive næste indlæg, øv hvor kan tiden flyve når man har det sjovt - eller arbejder.

De planlagte indlæg tager også længere tid end forventet, måske fordi jeg leger så godt :-) Planen for de indlæg der mangler er nogle helt nede på jorden eksempler med pakker, til rigtige formål. Altså eksempler på programmer som man reelt kan bruge i sit eksisterende arsenal med Nmap, Python, Perl, Nemesis osv.

Det første som er blevet mere færdigt er en lille sød IPv6 portscanner, som snildt kan udvides med mere funktionalitet. Ideen med portscanneren er at scanne porte på IPv6, med SYN pakker - hvor eksempelvis Nmap scanner med connect scans :-). Lad os ikke forhale det længere, jeg er jo bagude i forvejen:

#! /usr/local/bin/python2.5
# Simple SYN portscanner for IPv6
# Henrik Kramshoej, december 2009
import sys
from scapy.all import *

def main():
	from optparse import OptionParser
    
	parser = OptionParser()
	parser.add_option("-d", "--dest",
                      dest="target", default="::1",
                      help="Target for port scan")
	parser.add_option("-g", "--source-port", 
                      dest="sport", default=23,
                      help="Use given port as source port")
	parser.add_option("-1", "--port1",
                      dest="port1", default=1,
                      help="Starting port in port range to scan.")
	parser.add_option("-2", "--port2",
                      dest="port2", default=10,
                      help="End port in port range to scan.")
	(options, args) = parser.parse_args()

	print "Simple IPv6 SYN Portscanner"
	print "Target: "+ str(options.target) + " ports: " + str(options.port1) + "-"+ str(options.port2)
	a=IPv6(nh=06, dst=options.target, version=6L, hlim=255, fl=0L)
	print a.show()
	b=TCP(sport=options.sport, dport=(int(options.port1),int(options.port2)))
	ans,unans=sr(a/b)
	
	print "Source\t\t\tport\t\tflags"
	ans.summary( lambda(s,r) : r.sprintf("%IPv6.src% {TCP:%TCP.sport%}\t{ICMP:%ICMP.type%}\t{TCP:%TCP.flags%}"))
main()

Hent det på http://www.kramse.org/files/tools/net/misc/syn6can.py Når man afvikler programmet mod min ene OpenBSD server får man (port 37 er åben):

hlk@bigfoot:scapy$ sudo  ./syn6can.py -d 2001:16d8:dd0f:cf0f::1 -1 30 -2 38 
Simple IPv6 SYN Portscanner
Target: 2001:16d8:dd0f:cf0f::1 ports: 30-38
###[ IPv6 ]###
  version= 6L
  tc= 0
  fl= 0L
  plen= None
  nh= TCP
  hlim= 255
  src= 2001:16d8:dd0f:cf0f:223:6cff:fe9a:f52c
  dst= 2001:16d8:dd0f:cf0f::1
None
Begin emission:
...*.*.*Finished to send 9 packets.
.*.*.*.*.*..*
Received 21 packets, got 9 answers, remaining 0 packets
Source			port		flags
2001:16d8:dd0f:cf0f::1 30		RA
2001:16d8:dd0f:cf0f::1 msg_auth		RA
2001:16d8:dd0f:cf0f::1 32		RA
2001:16d8:dd0f:cf0f::1 dsp		RA
2001:16d8:dd0f:cf0f::1 34		RA
2001:16d8:dd0f:cf0f::1 35		RA
2001:16d8:dd0f:cf0f::1 36		RA
2001:16d8:dd0f:cf0f::1 time		SA
2001:16d8:dd0f:cf0f::1 38		RA

og med Wireshark kan man se at det er et SYN scan, med det fleste porte som svarer med RESET - undtagen "time":

Mangler i programmet er dog pt.:

Flere options ville være rart, blandt andet afkodning af Nmap style portnr i stil med: -p1-1024,1580,6000-6010
Måske noget OS detection - med p0f?
Pænere præsentation af resultaterne, så man fik både portnr som tal og som tekst, "37 vs time"

Konklusionen idag er at man godt kan bruge Mac OS X med Scapy 2.0.1 fra Mac ports, men skal huske at kalde den rigtige python - check det før du kører programmerne! Ligeledes er der noget at lære om afkodning af options og Python - som jeg stadig er nybegynder i. Programmet ovenfor er sådan set vildt avanceret, men Scapy gør en stor del af arbejdet for os. Hvem havde troet man kunne lave en portscanner på så få linier?

Email address change for Henrik Kramshoej

Mon, 14 Dec 2009 07:16:24 +0100

Hi There

I am changing my email adress, the one I thought I would keep until I die ... hlk@kramse.dk

You should update your address book if you want to continue sending me email. The new address is: hlk@kramse.org

The new address has been available for some time and the old one will be removed December 2010

Thanks in advance Henrik

PS You can always find updated contact information at: http://kramshoej.tel

Juletip 11: N900 tcpdump

Sat, 12 Dec 2009 09:32:36 +0100

Update 15:14: Jeg er en tumpe, tcpdump virker - hvis man vælger det rigtige interface :-)

Hovsa, jeg tror julemanden kom forbi, for jeg har fået fat på en N900 til lidt leg :-)

Jeg har tidligere snakket en del om min Nokia N810 som jeg har leget en del med, både med tcpdump, airodump osv. - det er en sød lille hackerplatform. Dog er den lidt begrænset med specs:

Procesor TI OMAP 2420, 400Mhz
Memory DDR RAM 128MB
Flash 256MB
Storage Up to 2GB internal memory

Men den virker fint - bortset fra at Metasploit er for langsomt, men dog kan starte op.

Nå men en Nokia N900 har vist disse specs:

Processor: TI OMAP 3430: ARM Cortex-A8 600 MHz,
Grafik PowerVR SGX with OpenGL ES 2.0 support
Memory Up to 1GB of application memory (256 MB RAM, 768 MB virtual memory)

Vrooooom tænker jeg straks - udover at en N900 jo også er en telefon. Så i med et SIM kort, det gjorde jeg igår efter en 12 timers arbejdsdag. Sorry derfor juletip er forsinket, men de kommer!

Hvis du støder på en N900 er der dog lidt tip, blandt andet skal du smide flere repositories ind. Det vigtigste lige for julekalenderen er nok fremantle tools der blandt andet giver tcpdump :-).

Nokia-N900-42-11:~# apt-get install tcpdump
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following extra packages will be installed:
  libpcap0.8
The following NEW packages will be installed:
  libpcap0.8 tcpdump
0 upgraded, 2 newly installed, 0 to remove and 2 not upgraded.
Need to get 404kB of archives.
After this operation, 926kB of additional disk space will be used.
Do you want to continue [Y/n]? Y
WARNING: The following packages cannot be authenticated!
  libpcap0.8 tcpdump
Install these packages without verification [y/N]? y
Get:1 http://repository.maemo.org fremantle/tools/free libpcap0.8 0.9.8-5+0m5 [93,9kB]
Get:2 http://repository.maemo.org fremantle/tools/free tcpdump 3.9.5-2osso2 [310kB]
Fetched 404kB in 0s (629kB/s)
Selecting previously deselected package libpcap0.8.
(Reading database ... 22804 files and directories currently installed.)
Unpacking libpcap0.8 (from .../libpcap0.8_0.9.8-5+0m5_armel.deb) ...
Selecting previously deselected package tcpdump.
Unpacking tcpdump (from .../tcpdump_3.9.5-2osso2_armel.deb) ...
Setting up libpcap0.8 (0.9.8-5+0m5) ...
Setting up tcpdump (3.9.5-2osso2) ...

NB: ovenstående er copy-pastet fra en SSH session, jeg har selvfølgelig smidt gainroot og OpenSSH server ind også :-) Derefter kan man starte tcpdump som vi plejer:

Nokia-N900-42-11:~# tcpdump -n icmp
tcpdump: WARNING: wmaster0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wmaster0, link-type IEEE802_11 (802.11), capture size 96 bytes
13:32:03.561267 IP 10.0.42.104 > 10.0.42.95: ICMP echo reply, id 34528, seq 0, length 64
13:32:04.600025 IP 10.0.42.104 > 10.0.42.95: ICMP echo reply, id 34528, seq 1, length 64
13:32:05.514087 IP 10.0.42.104 > 10.0.42.95: ICMP echo reply, id 34528, seq 2, length 64
13:32:06.545337 IP 10.0.42.104 > 10.0.42.95: ICMP echo reply, id 34528, seq 3, length 64

Hmm der er noget galt - for vi ser kun pakkerne ud af vores interface. Øv, det begrænser jo brugbarheden en del - det ryger på todolisten. Min N810 sniffer fint både med tcpdump, dsniff osv. - ligesom en Nmap nemt udføres med den platform.

Tcpdump virker, hvis man vælger interface wlan0, altså tcpdump -ni wlan0

Men et andet værktøj kan installeres fra samme repository, hcidump fra pakken bluez-hcidump som er værktøjer fra http://www.bluez.org/ - vupti så har jeg altså (endelig) fået fat i noget Bluetooth sniffer værktøj.

Nokia-N900-42-11:~# hcidump -?
HCI sniffer - Bluetooth packet analyzer ver 1.42
hcidump: invalid option -- ?
Usage: hcidump [OPTION...] [filter]
  -i, --device=hci_dev       HCI device
  -l, --snap-len=len         Snap len (in bytes)
  -p, --psm=psm              Default PSM
  -m, --manufacturer=compid  Default manufacturer
  -w, --save-dump=file       Save dump to a file
  -r, --read-dump=file       Read dump from a file
  -s, --send-dump=host       Send dump to a host
  -n, --recv-dump=host       Receive dump on a host
  -d, --wait-dump=host       Wait on a host and send
  -t, --ts                   Display time stamps
  -a, --ascii                Dump data in ascii
  -x, --hex                  Dump data in hex
  -X, --ext                  Dump data in hex and ascii
  -R, --raw                  Dump raw data
  -C, --cmtp=psm             PSM for CMTP
  -H, --hcrp=psm             PSM for HCRP
  -O, --obex=channel         Channel for OBEX
  -P, --ppp=channel          Channel for PPP
  -D, --pppdump=file         Extract PPP traffic
  -A, --audio=file           Extract SCO audio data
  -B, --btsnoop              Use BTSnoop file format
  -V, --verbose              Verbose decoding
  -Y, --novendor             No vendor commands or events
  -N, --noappend             No appending to existing files
  -4, --ipv4                 Use IPv4 as transport
  -6  --ipv6                 Use IPv6 as transport
  -h, --help                 Give this help list
      --usage                Give a short usage message
Nokia-N900-42-11:~# hcidump -w hcidump-test.cap      
HCI sniffer - Bluetooth packet analyzer ver 1.42
device: hci0 snap_len: 1028 filter: 0x0
^C
Nokia-N900-42-11:~# ls -ltr
-rw-r--r--    1 root     root     16613337 Dec 13 13:55 hcidump-test.cap

Jeg prøvede at åbne filen i Wireshark og den åbner fint, men afkodningen er ret basal. I developer tools er der yderligere arping, traceroute osv. Så platformen, som er bygget på Linux og vist med en open source Wireless driver denne gang!, er godt på vej til at blive spændende.

Nu kunne man jo fortsætte i samme stil og opremse hvad en N900 kunne bruges til, men pointen er (i modsætning til iPhøne) at en N900/N810 er en Linux baseret platform og mange af vores sædvanlige værktøjer kan oversættes til denne platform, med få eller ingen ændringer.

Kort konklusion er altså at man ikke behøver en hel computer, selvom netbooks er små, men at håndholdte begynder at kunne nok til at lave pentest on the road - mens man spiller Mahjoong hvis nogen spørger :-)

Juletip 10: tiden flyver, og man føler man går i ring

Thu, 10 Dec 2009 18:58:38 +0100

Øv, jeg mangler stadig julegaverne ...

Men dagen idag skal handle om NTP, eller mere specifikt om NTP Denial of Service, altså ude af drift angreb mod NTP server. Først finder man indlæg som CVE-2009-3563 google søgning.

Super, der er noget nyt DoS - men hvordan verificerer vi så denne? Hvis bare der var et tool der kunne lave pakkerne der får NTP serveren til at gå i smadder - så kan vi vurdere hvor alvorlig rapporterne om denne sårbarhed er. Tilfældigt dumper der så følgende ind i mailen:

hlk,
We wanted to let you know that there are new pcaps on pcapr. If you don't want to receive this alert, you can turn off notifications in your profile: http://www.pcapr.net/profile.

   ntp_single_byte_dos.pcap (ntp)
   ntp.pcap (ntp)

Thanks,
The Pcapr Team
http://www.pcapr.net
http://www.mudynamics.com

Ahh, der er nogen der har leget med det og der er en beskrivelse og et pakkedump:

Med det vi kender fra pakkekalenderen ved vi nu:

Vi kan bygge pakkerne med C og libnet
Vi kan bygge pakkerne med Python - eller Perl, Ruby, ... der findes pcap ting til mange scripting sprog efterhånden
Vi kan afspille pakkerne igen med tcpreplay

Det nemmeste ville nok være at indstille to sårbare maskiner til disse adresser, 1.0.0.1 og 2.0.0.2, hvor efter man blot kunne afspille pakkerne ... meeeen tcpreplay kan faktisk godt ændre lidt på pakkerne.

Desværre har jeg ikke fået efterprøvet det, så dagens indlæg bliver måske mere en teaser - at I selv med den viden der er præsenteret ovenfor nemt og relativt hurtigt kan lave et hackerscript der kan afprøve dette - i et lukket lab netværk selvfølgelig!

Jeg opdaterer her med et script hvis jeg får tid til det, sorry

Juletip 9: Scapy sendpfast'er than anything else

Wed, 9 Dec 2009 12:42:59 +0100

Igår så vi på PCS og optimerede afsendelse af pakkerne, ved at lave nogle fornuftige ændringer i det første eksempelprogram.

Idag vil jeg så råt kaste et nyt værktøj ind, Scapy som ligeledes kan lave pakker. Programmet, eller bibliotekerne om man vil er ligesom PCS skrevet i Python og det virker ret nemt.

Fidusen ved Scapy er at man stakker sine pakker sammen - lidt ligesom dominobrikker og så gør Scapy forøvrigt en hel masse. Resultatet bliver nogle små programmer der er nemme at forstå, men som kan lave alverdens ballade på netværk :-) Jeg sad faktisk igår og legede med tanken om at lave onde NTP pakker til CVE-2009-3563 som Signout snakkede om på IRC.

Nå tilbage til Scapy som har en god dokumentation så man kan komme igang, eksempelvis en Ethernet pakke med en ARP pakke ovenpå:

>>> ans,unans=srp(Ether(dst="ff:ff:ff:ff:ff:ff")/ARP(pdst="192.168.1.0/24"),timeout=2)

Som er lige direkte fra dokumentationen, eller noget så simpelt som en ping pakke, IP med en ICMP ovenpå - med default indstillinger (afviklet på en BackTrack):

hlk@bt4-pre:~$ cat first.py 
#! /usr/bin/env python

import sys
from scapy import sr1,IP,ICMP

p=sr1(IP(dst=sys.argv[1])/ICMP())
if p:
	p.show()

hlk@bt4-pre:~$ sudo python first.py 10.0.42.1
Begin emission:
............Finished to send 1 packets.
.....*
Received 18 packets, got 1 answers, remaining 0 packets
###[ IP ]###
  version= 4L
  ihl= 5L
  tos= 0x0
  len= 28
  id= 24724
  flags= 
  frag= 0L
  ttl= 255
  proto= icmp
  chksum= 0xf2f0
  src= 10.0.42.1
  dst= 10.0.42.91
  options= ''
###[ ICMP ]###
     type= echo-reply
     code= 0
     chksum= 0xffff
     id= 0x0
     seq= 0x0
###[ Padding ]###
        load= '\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'

Dette program viser så svaret der kommer tilbage, men hvis man vil se begge pakker kan man ændre så man tildeler værdien af pakken til en variabel a istedet:

hlk@bt4-pre:~$ cat show1.py 
#! /usr/bin/env python

import sys
from scapy import sr1,IP,ICMP

a=IP(dst=sys.argv[1])/ICMP()
a.show()
p=sr1(a)
if p:
	p.show()
hlk@bt4-pre:~$ sudo python show1.py 10.0.42.1
###[ IP ]###
  version= 4
  ihl= 0
  tos= 0x0
  len= 0
  id= 1
  flags= 
  frag= 0
  ttl= 64
  proto= icmp
  chksum= 0x0
  src= 10.0.42.91
  dst= 10.0.42.1
  options= ''
###[ ICMP ]###
     type= echo-request
     code= 0
     chksum= 0x0
     id= 0x0
     seq= 0x0
Begin emission:
..................Finished to send 1 packets.
.....*
Received 24 packets, got 1 answers, remaining 0 packets
###[ IP ]###
  version= 4L
  ihl= 5L
  tos= 0x0
  len= 28
  id= 32448
  flags= 
  frag= 0L
  ttl= 255
  proto= icmp
  chksum= 0xd4c4
  src= 10.0.42.1
  dst= 10.0.42.91
  options= ''
###[ ICMP ]###
     type= echo-reply
     code= 0
     chksum= 0xffff
     id= 0x0
     seq= 0x0
###[ Padding ]###
        load= '\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'

Så vil den printe pakken a som vi sender og pakken p som vi modtager - super!

Lad os nu antage at vi ønsker at ændre felterne i pakken, svarende til de tidligere eksempler med PCS:

hlk@bt4-pre:~$ cat show2.py 
#! /usr/bin/env python

import sys
from scapy import sr1,IP,ICMP

print "Send"
a=IP(dst=sys.argv[1],id=1234,ttl=64)/ICMP(type=8, code=0,id=37123)/"Hello World!"
a.show()

print "Receive"
p=sr1(a)
if p:
	p.show()
hlk@bt4-pre:~$ sudo python show2.py 10.0.42.1
Send
###[ IP ]###
  version= 4
  ihl= 0
  tos= 0x0
  len= 0
  id= 1234
  flags= 
  frag= 0
  ttl= 64
  proto= icmp
  chksum= 0x0
  src= 10.0.42.91
  dst= 10.0.42.1
  options= ''
###[ ICMP ]###
     type= echo-request
     code= 0
     chksum= 0x0
     id= 0x9103
     seq= 0x0
###[ Raw ]###
        load= 'Hello World!'
Receive
Begin emission:
....................Finished to send 1 packets.
.....*
Received 26 packets, got 1 answers, remaining 0 packets
###[ IP ]###
  version= 4L
  ihl= 5L
  tos= 0x0
  len= 40
  id= 26454
  flags= 
  frag= 0L
  ttl= 255
  proto= icmp
  chksum= 0xec22
  src= 10.0.42.1
  dst= 10.0.42.91
  options= ''
###[ ICMP ]###
     type= echo-reply
     code= 0
     chksum= 0x1d0d
     id= 0x9103
     seq= 0x0
###[ Raw ]###
        load= 'Hello World!'
###[ Padding ]###
           load= '\x00\x00\x00\x00\x00\x00'

Det gik da vist meget nemt! Samtidig sparede vi også noget ARP/Ethernet snask, og hele fidusen lå i to linier, den første der opbygger pakken og den anden som er en send-receive:

a=IP(dst=sys.argv[1],id=1234,ttl=64)/ICMP(type=8, code=0,id=37123)/"Hello World!"
p=sr1(a)

Bemærk hvorledes man nemt smider rådata ind i pakken :-) Hvis vi ikke ønsker at se på pakkerne vi modtager er det mere effektivt blot at bruge send, men mere interessant er der en sendpfast. Denne funktion kræver dog en Ethernet header, men så bruges den ellers på følgende måde:

hlk@bt4-pre:~$ cat first-icmp.py 
#! /usr/bin/env python
import sys
from scapy import srloop,send,sendpfast,sr1,Ether,IP,ICMP

a=Ether()/IP(dst=sys.argv[1],id=1234,ttl=64)/ICMP(type=8, code=0,id=37123)/"Hello World!"
p=sendpfast(a, loop=100)


hlk@bt4-pre:~$ time sudo python first-icmp.py 10.0.42.1
sending out eth0 
processing file: /tmp/fileSBo7B9
...
processing file: /tmp/fileSBo7B9
processing file: /tmp/fileSBo7B9
Actual: 100 packets (5400 bytes) sent in 0.24 seconds
Rated: 221474.9 bps, 1.69 Mbps/sec, 4101.39 pps

Statistics for network device: eth0
	Attempted packets:         100
	Successful packets:        100
	Failed packets:            0
	Retried packets (ENOBUFS): 0
	Retried packets (EAGAIN):  0

real	0m0.282s
user	0m0.100s
sys	0m0.117s

Sejt, den sendte lige 100 pakker på 0.282s?! Hvordan det, jo den lavede pakken færdig og den blev gemt som en fil, alle referencerne til processing file: ovenfor. Derefter sendte den med programmet tcpreplay som blev vist på juletip 7 . Det er altså konklusionen at Python med Scapy kan være både nemt og hurtigt :-)

Jeg vil anbefale jer at se lidt mere på Scapy - selv har jeg set alt for lidt på det og vi har kun lige ridset lidt i overfladen :-( Så hent en BackTrack og kom igang!

Juletip 8: Faster, Pussycat! Kill! Kill!

Tue, 8 Dec 2009 16:13:31 +0100

Ups, tiden flyver - og idag skete der andre ting som kom i vejen. Men jeg vil aligevel lige forsøge at smide et blogindlæg i pakkekalenderen.

Dagens indlæg omhandler hastighed, med en tam reference til Russ Meyer - men hastighed er nøgleordet idag. Jeg har forøvrigt set et par Russ Meyer film og de er sjove/underlige. Lidt ligesom Orgazmo.

De sidste par dage (undtagen igår :-( ) har vi jo snakket om pakker der blev lavet med python, og det er jo meget sjovt - men måske lidt for langsomt hvis man ikke tænker sig om. Alt efter formålet er der jo nogle gange man gerne vil have lidt smæk på, eksempelvis ligesom med ping -f:

hlk@bigfoot:network$ time sudo ping -f -c 10000 10.0.42.1 
PING 10.0.42.1 (10.0.42.1): 56 data bytes
..Request timeout for icmp_seq 7648
.
--- 10.0.42.1 ping statistics ---
10000 packets transmitted, 10000 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.603/0.867/19.408/0.544 ms
    8.10s real     0.06s user     0.58s system

Ping med -f option er Flood ping, og kræver derfor superuser rettigheder. Det er en nem måde at teste en forbindelse, hurtigt. Men hvad så med vores python programmer? 100 pings?

hlk@bigfoot:network$ time for i in `jot 100`^Jdo^Jsudo python icmpv4test-hlk.py ^Jdone 

Found Darwin
Ethernet
dst: 0:40:63:c9:f3:11
src: 0:23:6c:9a:f5:2c
type: 0x800
IPv4
version 4
hlen 5
tos 0
length 28
id 1234
flags 0
offset 0
ttl 64
protocol 1
checksum 0
src 10.0.42.95
dst 10.0.42.1
options []

ICMPv4 Echo Request
type 8
code 0
checksum 0

ICMPv4 Echo
id 37123
sequence 0
... 100 gange
    8.46s real     0.06s user     0.06s system

Ikke vildt vel? 100 pakker på 8 sekunder - yay! Men også vildt unfair, jeg slår lige print sætningerne fra:

hlk@bigfoot:network$ time for i in `jot 100`^Jdo^Jsudo python icmpv4test-hlk.py ^Jdone 
    7.93s real     0.04s user     0.06s system
hlk@bigfoot:network$

Det gav sgu ikke meget? Men hvis vi så ændrer python programmet til at have en løkke internt:

hlk@bigfoot:network$ cat icmpv4test-hlk.py 
#!/usr/bin/env python
...
		for i in range(1, 101):
			e = ethernet()
			e.type = 0x0800
			e.src = "\x00\x23\x6c\x9a\xf5\x2c"
			e.dst = "\x00\x40\x63\xc9\xf3\x11"
			e.type = 0x0800
...
hlk@bigfoot:network$ time sudo python icmpv4test-hlk.py  
    0.30s real     0.24s user     0.04s system

Aha, det gav bonus! Min maskine skal ikke starte python 100 gange! Man kan endda flytte løkken ned til der hvor pakken sendes - hvis applikationen ikke kræver pakken ændres mellem hver afsendelse.

hlk@bigfoot:network$ cat icmpv4test-hlk.py 
#!/usr/bin/env python
...
		packet.encode()
		output = PcapConnector(devname)
		for i in range(1, 101):
			n_out = output.write(packet.bytes, 42)
hlk@bigfoot:network$ time sudo python icmpv4test-hlk.py  
    0.09s real     0.05s user     0.04s system

Godt, det giver altså en meget bedre hastighed og vi kan altså godt lave mange pakker med python - lad os prøve med lad os sige 10000 pakker?

hlk@bigfoot:network$ cat icmpv4test-hlk.py 
#!/usr/bin/env python
...
		output = PcapConnector(devname)
		for i in range(1, 10001):
			n_out = output.write(packet.bytes, 42)

		print "Packets sent: "+ str(i)

hlk = hlktest()
hlk.test_icmpv4_ping()
 
hlk@bigfoot:network$ time sudo python icmpv4test-hlk.py  
Packets sent: 10000
    0.26s real     0.06s user     0.10s system

OK, nu er vi jo meget hurtigere end ping programmet var! Men vi udførte heller ikke samme arbejde, så lad os prøve at opdatere med et enkelt felt, ECHO pakkens id:

hlk@bigfoot:network$ cat icmpv4test-hlk.py 
#!/usr/bin/env python
...
		for i in range(1, 10001):
			echo.id = i
			packet = Chain([e, ip, icmp, echo])
			packet.calc_checksums()
			packet.encode()
			output = PcapConnector(devname)
			n_out = output.write(packet.bytes, 42)

		print "Packets sent: "+ str(i)

hlk = hlktest()
hlk.test_icmpv4_ping()
 

hlk@bigfoot:network$ time sudo python icmpv4test-hlk.py  
Packets sent: 10000
    8.66s real     7.50s user     1.02s system

Så hvad er konklusionen idag?
Jo, den er at

en 2.8GHz Intel Core 2 Duo med 1067MHz DDR3 kan fylde et wireless netværk op med pakker *duuuh*
Python med lidt omtanke kan på en sådan en svend med lidt omtanke producere lige så meget som ping -f

Faktisk overraskede det mig lidt at python programmet er så effektivt, men vores moderne CPU ER åbenbart ret kraftige ;-) Det kunne være sjovt at gentage eksperimentet med min Thinkpad X31 og gigabit Ethernet kortet - så kan det være det bliver nødvendigt med "pcap replay" programmer.

Juletip 7: Vi sender sender sender pakker pakker pakker

Mon, 7 Dec 2009 15:14:59 +0100

sorry det er mandag og alting har drillet, der kommer ikke noget Juletip 7 idag, hvis jeg føler mig inspireret opdateres indlægget måske senere på måneden med et tip :-(

Update onsdag 9. dec: her kommer så Juletip 7, lidt forsinket:

Vi har nu set på nogle eksempler på pakker man kan bygge med PCS, men ofte er det jo et stort bøvl, hvis man "bare skal have noget trafik". Derfor vil jeg idag præsentere et lækkert program der som input tager noget eksisterende trafik, i PCAP filer selvfølgelig, og smider det ud på netværket igen.

Programmet findes på BackTrack og hedder tcpreplay og har en del options:

hlk@bt4-pre:~$ tcpreplay
ERROR:  The intf1 option is required
tcpreplay: Command line arguments required
tcpreplay (tcpreplay) - Replay network traffic stored in pcap files
USAGE:  tcpreplay [ - [] | --[{=| }] ]... 

   -q, --quiet                Quiet mode
   -T, --timer=str            Select packet timing mode: select, ioport, rdtsc, gtod, nano, abstime
       --sleep-accel=num      Reduce the amount of time to sleep by specified usec
       --rdtsc-clicks=num     Specify the RDTSC clicks/usec
   -v, --verbose              Print decoded packets via tcpdump to STDOUT
   -A, --decode=str           Arguments passed to tcpdump decoder
   -K, --enable-file-cache    Enable caching of packets to internal memory
   -c, --cachefile=str        Split traffic via a tcpprep cache file
   -i, --intf1=str            Server/primary traffic output interface
   -I, --intf2=str            Client/secondary traffic output interface
   -l, --loop=num             Loop through the capture file X times
       --pktlen               Override the snaplen and use the actual packet len
   -L, --limit=num            Limit the number of packets to send
   -x, --multiplier=str       Modify replay speed to a given multiple
   -p, --pps=num              Replay packets at a given packets/sec
   -M, --mbps=str             Replay packets at a given Mbps
   -t, --topspeed             Replay packets as fast as possible
   -o, --oneatatime           Replay one packet at a time for each user input
   -P, --pid                  Print the PID of tcpreplay at startup
   -V, --version              Print version information
   -h, --less-help            Display less usage information and exit
   -H, --help                 Display usage information and exit
   -!, --more-help            Extended usage information passed thru pager
       --save-opts[=arg]      Save the option state to a config file
       --load-opts=str        Load options from a config file

Options are specified by doubled hyphens and their name
or by a single hyphen and the flag character.

tcpreplay is a tool for replaying network traffic from files saved with
tcpdump or other tools which write pcap(3) files.

Men frygt ej! Først laver man en capture fil, eksempelvis med Wireshark eller tcpdump - og HUSK -s option så du får hele pakken med!:

hlk@bt4-pre:~$ sudo tcpdump -w ping-pong.cap -s 1500 icmp and src 10.0.42.91 &
[1] 23396
hlk@bt4-pre:~$ tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 1500 bytes
ping -c 10 10.0.42.1
PING 10.0.42.1 (10.0.42.1) 56(84) bytes of data.
64 bytes from 10.0.42.1: icmp_seq=1 ttl=255 time=4.99 ms
64 bytes from 10.0.42.1: icmp_seq=2 ttl=255 time=3.35 ms
64 bytes from 10.0.42.1: icmp_seq=3 ttl=255 time=3.65 ms
64 bytes from 10.0.42.1: icmp_seq=4 ttl=255 time=3.24 ms
64 bytes from 10.0.42.1: icmp_seq=5 ttl=255 time=3.39 ms
64 bytes from 10.0.42.1: icmp_seq=6 ttl=255 time=3.20 ms
64 bytes from 10.0.42.1: icmp_seq=7 ttl=255 time=3.16 ms
64 bytes from 10.0.42.1: icmp_seq=8 ttl=255 time=3.22 ms
64 bytes from 10.0.42.1: icmp_seq=9 ttl=255 time=3.15 ms
64 bytes from 10.0.42.1: icmp_seq=10 ttl=255 time=3.36 ms

--- 10.0.42.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9015ms
rtt min/avg/max/mdev = 3.151/3.474/4.991/0.525 ms
hlk@bt4-pre:~$ fg
sudo tcpdump -w ping-pong.cap -s 1500 icmp and src 10.0.42.91
^C10 packets captured
10 packets received by filter
0 packets dropped by kernel

Nu har vi således en fil med 10 ICMP ECHO request, vi tog kun ICMP og min source:

Denne fil kan vi så afspille efter behov med programmet tcpreplay:

hlk@bt4-pre:~$ sudo tcpreplay -i eth0 ping-pong.cap 
sending out eth0 
processing file: ping-pong.cap
Actual: 10 packets (960 bytes) sent in 9.18 seconds
Rated: 106.4 bps, 0.00 Mbps/sec, 1.11 pps

Statistics for network device: eth0
	Attempted packets:         10
	Successful packets:        10
	Failed packets:            0
	Retried packets (ENOBUFS): 0
	Retried packets (EAGAIN):  0

Super, det lader til at det virker :-) (og jeg checkede med tcpdump på 10.0.42.1 at pakkerne kom frem :-) )

Det næste du så kan gøre er at lege med hastighed, sætte den til max med -t option eller gange med option -x. Du kan også loope, så 1000 pakker med max speed bliver:

hlk@bt4-pre:~$ sudo tcpreplay -i eth0 -t -l 100 ping-pong.cap 
sending out eth0 
processing file: ping-pong.cap
...
processing file: ping-pong.cap
processing file: ping-pong.cap
processing file: ping-pong.cap
processing file: ping-pong.cap
Actual: 1000 packets (98000 bytes) sent in 0.47 seconds
Rated: 2075479.7 bps, 15.83 Mbps/sec, 21178.36 pps

Statistics for network device: eth0
	Attempted packets:         1000
	Successful packets:        1000
	Failed packets:            0
	Retried packets (ENOBUFS): 0
	Retried packets (EAGAIN):  0

Konklusionen idag er at man ikke altid behøver at bygge pakkerne selv, men man kan vælge at gentage en opsamlet datastrøm.

Juletip 6: Vi bygger IPv6 pakker med PCS

Sun, 6 Dec 2009 10:49:58 +0100

Dagen idag bliver lidt kortere, men forhåbentlig så mere fokuseret :-)

Målet idag er således at vise hvordan man bygger IPv6 pakker med PCS som vi igår brugte til IPv4 pakker.

Til at starte med er det relativt nemt at ændre lidt imports, som man ligeledes skal opdatere hvis det er andre typer pakker man vil sende:

from pcs.packets.ethernet import ethernet
from pcs.packets.ipv6 import *
from pcs.packets.icmpv6 import *
from pcs import *

Tilsvarende ændrer man selvfølgelig til IPv6 på Ethernet niveau og på IPv6 niveau:

		ip6 = ipv6()
		ip6.traffic_class = 0
		ip6.flow = 0
		ip6.length = 0
		ip6.next_header = 0x3a
		ip6.hop = 255
		ip6.src = inet_pton(AF_INET6, "2001:16d8:dd0f:cf0f:223:6cff:fe9a:f52c")
		ip6.dst = inet_pton(AF_INET6, "2001:16d8:dd0f:cf0f:240:63ff:fec9:f311")
		print ip6

Men husk der er nogle andre felter i en IPv6 pakke:

 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Version| Traffic Class |           Flow Label                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Payload Length        |  Next Header  |   Hop Limit   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                         Source Address                        +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                      Destination Address                      +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Disse felter i pakken er således defineret og der er nogle interessante observationer. Den første er at headeren IKKE behøver noget padding, der er færre felter og adresserne er 4 gange så store. Det med at headeren har et fast format burde gøre det nemmere at afkode i hardware og med færre felter, hvoraf en del er indenfor de første 64-bit burde ligeledes optimere behandlingen af IPv6 og medføre flere pakker per sekund.

Version er 4-bit og burde vel være 6? Men ligesom med IPv4 har man glemt at skrive at der rent faktisk skal checkes for dette.

Traffic class svarer til Type of Service fra IPv4 og giver mulighed for at identificere og skelne mellem forskellige prioriteter for IPv6 pakkerne.

Flow label kan bruges af en afsender til pakker som skal have speciel behandling af IPv6 routere, eksempelvis ikke-standard quality of service eller "real-time" service.

Payload Length er længden af pakken efter headeren - inklusiv eventuelle andre headere.

Next Header er en nyt ting i IPv6, flere headere på IP niveau. Denne feature gør 1) IPv6 headeren har en konstant størrelse og er den som routere typisk vil se på, med afsender og modtager 2) der kan udvides med ny funktionalitet sidenhen. Der er defineret et antal headere - men det vil vi ikke gennemgå idag.

Hop limit er helt tilsvarende Time to Live fra IPv4 og er en tæller som angiver hvor mange hops en pakke må sendes over, før den eventuelt smides væk. Det sikrer at hvis der er routing loops så fjernes pakken når denne tæller rammer 0.

Source og Destination er ligesom på IPv4 naturligvis afsender og modtager - men der er jo ingen garantier for at det er den rigtige afsender, man kan således spoofe afsender adresser, hvorfor man har defineret IPsec OG gode internetudbydere bør implementere både ingress og egress filtering af trafik. IPv6 adresserne er 128-bit og der har været meget snak om det kæmpe adresserum - selvom det ikke er eneste ændring fra IPv4.

ICMPv6 ECHO test program

Godt så lad os se på ICMPv6 test programmet, som er modificeret fra eksemplet igår:

#!/usr/bin/env python
# Copyright (c) 2006, Neville-Neil Consulting
# All rights reserved.
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions are
# met:
#
# Redistributions of source code must retain the above copyright notice,
# this list of conditions and the following disclaimer.
#
# Redistributions in binary form must reproduce the above copyright
# notice, this list of conditions and the following disclaimer in the
# documentation and/or other materials provided with the distribution.
#
# Neither the name of Neville-Neil Consulting nor the names of its 
# contributors may be used to endorse or promote products derived from 
# this software without specific prior written permission.
#
# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
# OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
#
# File: $Id: icmpv4test.py,v 1.8 2006/09/05 07:30:56 gnn Exp $
#
# Author: George V. Neville-Neil
#
# Description: This module performs a self test on the IPv4 packet.
# That is to say it first encodes a packet, then decodes it and makes
# sure that the data matches.
import sys

if "-l" in sys.argv:
		sys.path.insert(0, "../") # Look locally first
		sys.argv.remove("-l") # Needed because unittest has issues

from pcs.packets.ethernet import ethernet
from pcs.packets.ipv6 import *
from pcs.packets.icmpv6 import *
from pcs import *

class hlktest():
	def test_icmpv6_ping(self):
		import os
		uname = os.uname()[0]
		if uname == "FreeBSD":
			devname = "edsc0"
		elif uname == "Linux":
			devname = "lo"
		elif uname == "Darwin":
			print "Found Darwin"
			devname = "en1"
		else:
			print "unknown host os %s" % uname
			return

		e = ethernet()
		e.src = "\x00\x23\x6c\x9a\xf5\x2c"
		e.dst = "\x00\x40\x63\xc9\xf3\x11"
		e.type = 0x86dd
		print e
		
		ip6 = ipv6()
		ip6.traffic_class = 0
		ip6.flow = 0
		ip6.length = 0
		ip6.next_header = 0x3a
		ip6.hop = 255
		ip6.src = inet_pton(AF_INET6, "2001:16d8:dd0f:cf0f:223:6cff:fe9a:f52c")
		ip6.dst = inet_pton(AF_INET6, "2001:16d8:dd0f:cf0f:240:63ff:fec9:f311")
		print ip6

		icmp6 = icmpv6(ICMP6_ECHO_REQUEST)
		icmp6.type = 128
		icmp6.code = 0
		icmp6.cksum = 0 
		icmp6.id=0xa03b
		icmp6.sequence=0x00
		
#		icmp6.checksum = icmp6.cksum(icmp6) & 0xffff
		icmp6.checksum = 0x5e8a
		print icmp6
		
		ip6.length = len(icmp6.bytes)# note that IPv6 payload length is PAYLOAD only
		print ip6.length
		
		packet = Chain([e, ip6, icmp6])
		packet.encode()
		output = PcapConnector(devname)
		n_out = output.write(packet.bytes, len (packet.bytes))
		print n_out

hlk = hlktest()
hlk.test_icmpv6_ping()

og ligesom igår kan det betale sig at downloade det :-)

Der er nogle ting der er anderledes, eksempelvis Payload length som nu kun er for indholdet efter IPv6 header, dvs ip6.length er kun icmp6.bytes. Jeg havde ligeledes lidt bøvl med checksummerne, så jeg kørte programmet og Wireshark var så flink at fortælle hvad checksum burde have været :-) Der mangler også at angive nogle bytes til data delen - men det må så være jeres opgave :-) (Jeg opdaterer senere hvis jeg løser det, jeg lærer jo også! )

Run the program

Men programmet køres ligesom igår, inkl debug info og giver resulatet som ses i Wireshark:

hlk@bigfoot:hlk$ sudo python icmpv6test-hlk.py  
Found Darwin
Ethernet
dst: 0:40:63:c9:f3:11
src: 0:23:6c:9a:f5:2c
type: 0x86dd
version 6
traffic_class 0
flow 0
length 0
next_header 58
hop 255
src 2001:16d8:dd0f:cf0f:223:6cff:fe9a:f52c
dst 2001:16d8:dd0f:cf0f:240:63ff:fec9:f311

type 128
code 0
checksum 24202
id 41019
sequence 0

8
62
hlk@bigfoot:hlk$

Det var alt for idag :-)

PS undervejs da jeg havde problemer stødte jeg på følgende program ICMPv6 ECHO program skrevet med PCS, som dog ikke virker 100% http://sources.zabbadoz.net/ipv6/CSCsd13298/

Juletip 5: Vi bygger pakker

Sat, 5 Dec 2009 14:19:37 +0100

Pakker er der nok af på vores IP netværk og de fleste kommer (forhåbentlig) fra applikationer som vi bruger. Andre igen kommer fra kernen, som svar på problemer. Enhelt tredie kategori er pakker vi selv bygger og det kan man gøre med mange værktøjer, eksempelvis:

Det første er et C bibliotek som har været tilgængeligt i mange år. Hvis man kaster sig over libnet vil man måske i første omgang mene det er lidt gammeldags, men i forhold til at skrive C programmer der direkte bygger pakkerne var det et stort fremskridt. Idag er der mange af vores programmer og hackerprogrammer der benytter libnet, så der er en stor sandsynlighed for at I har libnet installeret allerede.

Hvis man programmerer i C er det naturligt at vælge libnet og man kan læse mere på hjemmesiden http://libnet.sourceforge.net/ og det lader til at den oprindelige URL jeg ellers har brugt http://www.packetfactory.net er død :-(

Går man tilbage til eksempelvis dsniff pakken er det en af de pakker som benytter libnet og det er alt jeg ville sige om libnet idag, ligeså er scapy heller ikke på programmet idag, men måske en anden dag :-)

Idag skal det altså handle om Packet Construction Set, PCS

Packet Construction Set PCS

Jeg formoder I selv kan hente det på hjemmesiden og udpakke det.

PCS Install

Når man således har hentet og udpakket det skal man installere det, men først skulle jeg lige smide et ekstra bibliotek ind, som hedder Cython: C-Extensions for Python. Det gjorde jeg nemt på min Mac med Macports og jeg anbefaler at man så vidt muligt bruger pakkesystemerne - men ofte er små værktøjer som PCS ikke med.

Bemærk også at PCS bruger python26, dvs Python version 2.6 - så jeg måtte også lige installere python26

På min Mac var det altså kun at udføre følgende:

hlk@bigfoot:scripts$ sudo port install py26-cython
--->  Computing dependencies for py26-cython
--->  Fetching python26
--->  Attempting to fetch Python-2.6.4.tar.bz2 from http://arn.se.distfiles.macports.org/python26
--->  Verifying checksum(s) for python26
--->  Extracting python26
--->  Applying patches to python26
--->  Configuring python26
--->  Building python26
--->  Staging python26 into destroot
--->  Installing python26 @2.6.4_0+darwin
--->  Activating python26 @2.6.4_0+darwin
To fully complete your installation and make python 2.6 the default, please run
	sudo port install python_select  
	sudo python_select python26
--->  Cleaning python26
--->  Fetching py26-cython
--->  Attempting to fetch Cython-0.11.3.tar.gz from http://arn.se.distfiles.macports.org/python
--->  Verifying checksum(s) for py26-cython
--->  Extracting py26-cython
--->  Configuring py26-cython
--->  Building py26-cython
--->  Staging py26-cython into destroot
--->  Installing py26-cython @0.11.3_0
--->  Activating py26-cython @0.11.3_0
--->  Cleaning py26-cython
hlk@bigfoot:scripts$ sudo port install python_select 
--->  Computing dependencies for python_select
--->  Cleaning python_select
hlk@bigfoot:scripts$ sudo python_select python26
Selecting version "python26" for python

og hvis du oplever problemer senere så kan det være du mangler andre dependencies. Næste skridt var at læse PCS filerne README og INSTALL:

Installation Instructions for Packet Construction Set (PCS)

PCS follows the normal Python conventions for building and installing
and there is very little, if any, magic.  To install the library and
the associated packet classes into your system do:

> python setup.py config  
> python setup.py install 

To test your installation do:

> cd tests/ 
> python *.py

Some tests fail if you do not have enough privileges to work with the
Berkeley Packet Filter.  If you wish to run those tests run them
using sudo.

To build the documentation you will need pdflatex and a BSD version of
make(1) installed.  Go into the docs directory and build the
documentation:

> cd docs/ 
> bsdmake all

you will see PDF versions of the docs.

Det lyder jo fint, så hvad sker der - husk selv sudo under install delen:

hlk@bigfoot:pcs-0.6$ python -V
Python 2.6.4
hlk@bigfoot:pcs-0.6$ python setup.py config 
running config
found {'libraries': ['pcap'], 'library_dirs': ['/usr/lib'], 'include_dirs': ['/usr/include/pcap']}

Aha, det lader til at PCS bruger libpcap packet capture, det giver mening - endnu et af vores standardbiblioteker, som forøvrigt stammer fra tcpdump :-)

hlk@bigfoot:pcs-0.6$ sudo python setup.py install 
running install
running build
running build_py
creating build/lib.macosx-10.4-i386-2.6
creating build/lib.macosx-10.4-i386-2.6/pcs
copying pcs/__init__.py -> build/lib.macosx-10.4-i386-2.6/pcs
creating build/lib.macosx-10.4-i386-2.6/pcs/packets
copying pcs/packets/__init__.py -> build/lib.macosx-10.4-i386-2.6/pcs/packets
copying pcs/packets/arp.py -> build/lib.macosx-10.4-i386-2.6/pcs/packets
...
byte-compiling /usr/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/pcs/packets/udpv6.py to udpv6.pyc
byte-compiling /usr/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/pcs/packets/vlan.py to vlan.pyc
running install_egg_info
Writing /usr/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/pcs-0.6-py2.6.egg-info

Færdig, PCS er installeret

Running PCS

Super, vi har installeret PCS - lad os så komme igang. Det naturlige er at se på nogle af eksempelprogrammerne under pcs-0.6/scripts og jeg har klippet icmpv4test.py op og molestreret det således:

#!/usr/bin/env python
# Copyright (c) 2006, Neville-Neil Consulting
# All rights reserved.
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions are
# met:
#
# Redistributions of source code must retain the above copyright notice,
# this list of conditions and the following disclaimer.
#
# Redistributions in binary form must reproduce the above copyright
# notice, this list of conditions and the following disclaimer in the
# documentation and/or other materials provided with the distribution.
#
# Neither the name of Neville-Neil Consulting nor the names of its 
# contributors may be used to endorse or promote products derived from 
# this software without specific prior written permission.
#
# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
# OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
#
# File: $Id: icmpv4test.py,v 1.8 2006/09/05 07:30:56 gnn Exp $
#
# Author: George V. Neville-Neil
#
# Description: This module performs a self test on the IPv4 packet.
# That is to say it first encodes a packet, then decodes it and makes
# sure that the data matches.
import sys

if "-l" in sys.argv:
		sys.path.insert(0, "../") # Look locally first
		sys.argv.remove("-l") # Needed because unittest has issues

from pcs.packets.ethernet import ethernet
from pcs.packets.ipv4 import *
from pcs.packets.icmpv4 import *
from pcs import *

class hlktest():
	def test_icmpv4_ping(self):
		import os
		uname = os.uname()[0]
		if uname == "FreeBSD":
			devname = "edsc0"
		elif uname == "Linux":
			devname = "lo"
		elif uname == "Darwin":
			print "Found Darwin"
			devname = "en1"
		else:
			print "unknown host os %s" % uname
			return

		e = ethernet()
		e.type = 0x0800
		e.src = "\x00\x00\x00\x00\x00\x00"
		e.dst = "\xff\xff\xff\xff\xff\xff"
		e.type = 0x0800
		print e
		ip = ipv4()
		ip.version = 4
		ip.hlen = 5
		ip.tos = 0
		ip.length = 28
		ip.id = 1234
		ip.flags = 0
		ip.offset = 0
		ip.ttl = 64
		ip.protocol = IPPROTO_ICMP
		ip.src = inet_atol("10.0.42.95")
		ip.dst = inet_atol("10.0.42.44")
		print ip
		
		icmp = icmpv4()
		icmp.type = 8
		icmp.code = 0
		icmp.cksum = 0
		print icmp
		echo = icmpv4echo()
		echo.id = 37123
		echo.sequence = 0
		print echo
		ip.len = len(ip.bytes) + len(icmp.bytes) + len(echo.bytes)
		packet = Chain([e, ip, icmp, echo])
		packet.calc_checksums()
		packet.encode()
		output = PcapConnector(devname)
		n_out = output.write(packet.bytes, 42)

hlk = hlktest()
hlk.test_icmpv4_ping()

og sorry, hvis I prøver at copy paste det, python er ret pernitten med indrykning så det er bedre at downloade det :-) Men under alle omstændigheder så burde det være tydeligt hvad der sker og det er yderst letlæseligt. Når man kører programmet får man følgende output, mig der har tilføjet lidt print for at vise hvad der sker:

hlk@bigfoot:hlk$ sudo python icmpv4test.py  
Found Darwin
Ethernet
dst: ff:ff:ff:ff:ff:ff
src: 0:0:0:0:0:0
type: 0x800
IPv4
version 4
hlen 5
tos 0
length 28
id 1234
flags 0
offset 0
ttl 64
protocol 1
checksum 0
src 10.0.42.95
dst 10.0.42.44
options []

ICMPv4 Echo Request
type 8
code 0
checksum 0

ICMPv4 Echo
id 37123
sequence 0

og en tcpdump der kører samtidig viser:

hlk@bigfoot:hlk$ sudo tcpdump -ni en1 icmp 
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on en1, link-type EN10MB (Ethernet), capture size 65535 bytes
16:08:02.872460 IP 10.0.42.95 > 10.0.42.44: ICMP echo request, id 37123, seq 0, length 8
16:12:09.288684 IP 10.0.42.95 > 10.0.42.44: ICMP echo request, id 37123, seq 0, length 8

Øv, der kommer jo ikke noget svar?! Men det er jo helt naturligt, se på Ethernet pakken, dst og src - ahhhh. Hvordan er det lige med Ethernet, ja normalt bruger vi ARP - men vores program har hardcodet ff:ff:ff:ff:ff:ff og 0:0:0:0:0:0, hmmm det må vi gøre noget ved. Først henter vi MAC adresserne med arp og ifconfig:

hlk@bigfoot:hlk$ arp -an
? (10.0.42.1) at 0:0:24:c8:b2:4c on en1 ifscope [ethernet]
? (10.0.42.44) at 0:40:63:c9:f3:11 on en1 ifscope [ethernet]
hlk@bigfoot:hlk$ ifconfig en1
en1: flags=8963 mtu 1500
	inet6 fe80::223:6cff:fe9a:f52c%en1 prefixlen 64 scopeid 0x5 
	inet 10.0.42.95 netmask 0xffffff00 broadcast 10.0.42.255
	inet6 2001:16d8:dd0f:cf0f:223:6cff:fe9a:f52c prefixlen 64 autoconf 
	ether 00:23:6c:9a:f5:2c 
	media: autoselect status: active
	supported media: autoselect

og retter programmet:

		e.src = "\x00\x23\x6c\x9a\xf5\x2c"
		e.dst = "\x00\x40\x63\xc9\xf3\x11"

og vupti :-)

16:15:37.114776 IP 10.0.42.95 > 10.0.42.44: ICMP echo request, id 37123, seq 0, length 8
16:15:37.117927 IP 10.0.42.44 > 10.0.42.95: ICMP echo reply, id 37123, seq 0, length 8

Så det er altså relativt nemt med PCS at bygge pakkerne - men man overtager en del af arbejdet selv :-) Det var alt for idag.

Juletip 4: IPv4 gråzoner og magiske konstanter

Fri, 4 Dec 2009 13:08:57 +0100

4. december og jeg har stadig ikke købt julegaver :-(

Idag skal det handle om IPv4, selvom det meste i denne kalender handler om IPv4 :-) Men mere præcist snakker jeg idag om IPv4 pakkens header. Lad os derfor tage en tur tilbage med tidsmaskinen til RFC-791 og snakke om IP protokollerne:

        INTERNET PROTOCOL
                                    
                                    
      DARPA INTERNET PROGRAM
                                    
      PROTOCOL SPECIFICATION
                                                                    
         September 1981


          prepared for
Defense Advanced Research Projects Agency
 Information Processing Techniques Office
          1400 Wilson Boulevard
        Arlington, Virginia  22209

Wauuw, vi taler altså om protokoller som stammer fra de tidlige 1980'ere? Ja, selvom vi skifter vores gadgets i samme tempo som konen køber sko og tøj så bruger vi en oldgammel teknologi! - eller ok, måske ikke oldgammel, men så ihvertfald 25 år gammel da, som i internetår ER oldgammelt, men næppe er på radaren for en arkæolog. Til gengæld skal det måske bemærkes at IP erstattede en ældre protokol og hele historien om routere på internet generelt er spændende.

Personligt undersøgte jeg en masse dokumenter da jeg skrev mit speciale om IPv6, og det er fantastisk hvor holdbare ideerne omkring netværk og pakkekommunikation har vist sig at være. Nå lad os komme igang.

Hvad kendetegner internet idag, det er et fælles adresserum baseret på 32-bit adresser, og så et nyt adresserum på 128-bit (IPv6). Typisk skriver vi adresserne i dot-notation, dvs med 10.0.2.1 eller evt. med subnetmasken 10.0.2.1/24 - altså en subnetmaske på 24 bit=255.255.255.0. Faktisk er det underveje blevet besluttet at subnetmasker SKULLE være et antal 1-bit efterfulgt af 0-bit. Denne notation kaldes for CIDR notation, efter princippet om Classless Inter-Domain Routing. Men hov, det betyder jo at man har ændret IP undervejs?

Ja, IP protokollerne udvikles hele tiden, konservativt og langsomt med de eksisterende protokoller - men der sker en udvikling. Se bare på IPv6 hvorlænge den har været undervejs, selvom den i praksis vil lette en hel masse.

Godt, vi har altså IP som er en samling netværkprotokoller, hvor en af dem hedder IP som er karakteriseret ved:

Best effort - pakkerne sendes ud på netværket og vi håber den kommer frem
Uafhængigt af hardware som benyttes både netværket og systemerne vil være heterogene (smart!)
Lagdelt - både i designet, der er flere lag - men også implementationen er typisk holdt adskilt
Netværket antages at tabe pakker og end-to-end princippet er centralt.

Princippet med at opdele det komplekse problem giver god mening, og man kan løse problemerne uafhængigt. Ligeledes er det forudseende at man ikke forsøger at forudsige hvad der vil ske i al fremtid. Så med end-to-end princippet overlader man et stort arbejde til end-to-end protokoller. Tænk bare på HTTP som blev opfundet i 1990'erne. Ønsker man at læse mere om dette anbefales RFC-1958 Architectural Principles of the Internet fra 1996.

Så IP er altså både et sammensurium af protokoller og en protokol selv, og min favorittegning af dette er:

Tegningen viser lagdelingen og vi har talt om ARP og hardwarenære ting tidligere og idag er det så IP laget.

IPv4 pakken

Ser vi nu idag udelukkende på IP pakkernes headere (godt dansk ord headere ...) er der fra RFC-791 følgende oversigt, alle felter er big-endian, eller network byte order:

    0                   1                   2                   3   
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Version|  IHL  |Type of Service|          Total Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Identification        |Flags|      Fragment Offset    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Time to Live |    Protocol   |         Header Checksum       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Source Address                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Destination Address                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Options                    |    Padding    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Example Internet Datagram Header

Disse felter i pakken er således defineret og der er nogle interessante observationer:

Version er 4-bit og burde vel være 4? Jo, den er 4 - men det behøver man vel ikke checke? I version 6 er det ligeledes antaget at værdien ER 6, men det er ikke beskrevet at man skal checke dette ... pudsigt. Dette fik jeg forklaret af Radia Perlman på en konference.

Internet Header Length er naturligvis længden på pakken, antallet af 32-bit words i headeren.

Type of Service er interessant, selvom det har levet en kummerlig tilværelse i mange år er der kommet mere fokus på det i de senere år. Blandt andet revolutionen med IP telefoni, streaming af lyd og video giver et ønske om bedre kvalitet af internetforbindelserne.

Total length er hele pakkens længde i bytes, og bemærk af der kan ske fragmentering i IP - hvor en stor pakke opdeles i mindre, så modtageren kan godt risikere at få data over flere pakker - hvor fragmentation offset således ikke er 0. Når vi nu snakker om fragmenter kan vi angive at identification bruges til at identificere pakkerne - som de oprindeligt blev sendt. Tidligere blev dette IP ID felt blot talt een op for hver pakke - men dette kunne faktisk bruges til stealth scanning og de fleste implementationer er mere tilfældige idag.

Time to Live er en valgfri øvre grænse for levetiden for en IP pakke, som tælles ned på routere på vejen fra afsender til modtager. Hvis den når 0 smides pakken væk og der sendes en ICMP fejlbesked tilbage til afsenderen. Denne besked hedder ICMP time exceeded in-transit og udnyttes blandt andet af traceroute programmet. Traceroute er forøvrigt lidt af et hack udviklet af Van Jacobson omkring 1988.

Protocol er feltet der angiver næste protokol, dvs typiske værdier er ICMP protokol 1, TCP 6, UDP 17, samt IPsec protokollerne ESP 50 og AH 51 du kan finde en liste i /etc/protocols

Flags er et bit-felt der bruges som en del af fragmentering.

Various Control Flags.
Bit 0: reserved, must be zero
Bit 1: (DF) 0 = May Fragment,  1 = Don't Fragment.
Bit 2: (MF) 0 = Last Fragment, 1 = More Fragments.

En vigtig information her er at man med Dont Fragment kan angive at pakkerne IKKE må fragmenteres og det benyttes som en central del af Path MTU (PMTU), hvor man sender store pakker for at finde den største pakkestørrelse som der kan sendes fra en afsender til en modtager - for at undgå fragmenter. PMTU er noget man gerne vil have så man bør tillade ICMP svar tilbage på dette. Samlet set tillader jeg følgende icmptypes 3,4,11,12. Disse typer kan findes i manaul siden for icmp på OpenBSD:

3 unreach Destination unreachable
4 squench Packet loss, slow down
11 timex Time exceeded
12 paramprob Invalid IP header

Header checksum er en checksum på selve headeren. Denne checksum har vist sig at være problematisk, idet den skal udregnes for hver router på vejen i den tidskritiske løkke. Samtidig viser det sig at mange protokoller over og under IP udregner deres egne checksummer - og værdien var derfor til at overse. Header checksum er sparet væk i IPv6.

Source og Destination er naturligvis afsender og modtager - men der er jo ingen garantier for at det er den rigtige afsender, man kan således spoofe afsender adresser, hvorfor man har defineret IPsec OG gode internetudbydere bør implementere både ingress og egress filtering af trafik.

Hvorfor nu denne lange gennemgang af felter? Jo, der er nogle felter som er foruddefineret - SKAL bruges sådan og sådan. Men der er et antal felter som er mere valgfrie, eksempelvis TTL Time to live. Hvad er en god værdi for en TTL? og svaret er naturligt nok, stor nok til at kunne nå frem til modtageren :-) I visse operativsystemer, eksempelvis OpenBSD har man valgt værdien 255. Dvs den højeste værdi og derfor ved man med sikkerhed at en pakke med værdien 255 ikke har krydset nogen routere på vejen - enkelt og smart.

Når forskellige implementationer af IP således vælger forskelligt kan vi benytte dette til at identificere operativsystemerne som har sendt pakkerne. TTL feltet er et godt udgangspunkt og vi kan lave vores egen lille undersøgelse på værdierne:

64 Mac OS X, Linux, FreeBSD
128 Windows 2000
255 OpenBSD

Hmmm, det kunne tyde på at vi ikke alene ud fra TTL kan bestemme OS entydigt øv. Men der findes mange andre felter og der har været meget research indenfor dette område, blandt andet klassikeren "ICMP Usage In Scanning" af Ofir Arkin fra 2001. Siden dengang er der kommet flere værktøjer som forsøger at identificere operativsystemerne Xprobe/Xprobe2, p0f eller mit foretrukne værktøje Nmap.

OS detection

Så der findes altså programmer der kan se på pakkerne for os og gætte operativsystemet, med en vis usikkerhed.

hlk@bigfoot:hlk$ sudo nmap -O -p1-100 10.0.42.13 

Starting Nmap 5.10BETA1 ( http://nmap.org ) at 2009-12-04 14:52 CET
Nmap scan report for 10.0.42.13
Host is up (0.0013s latency).
Not shown: 99 closed ports
PORT   STATE SERVICE
80/tcp open  http
MAC Address: 00:00:AA:AB:9F:06 (Xerox)
Device type: WAP|printer
Running: Apple embedded, Canon embedded, Kyocera embedded, Xerox embedded
OS details: VxWorks: Apple AirPort Extreme v5.7 or AirPort Express v6.3; Canon imageRUNNER printer (5055, C3045, C3380, or C5185); Kyocera FS-4020DN printer; or Xerox Phaser 8860MFP printer
Network Distance: 1 hop

OS detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 1.74 seconds

Det lyder sandsynligt at det er en Xerox enhed, eftersom MAC adressen også er registreret til Xerox. Note: og bemærk også at netop pakkerne som Nmap sender for at finde ud af OS ligeledes afslører at det er Nmap der forsøger dette :-) Lad os prøve en mere:

hlk@bigfoot:hlk$ sudo nmap -O -p1-100 10.0.42.5  

Starting Nmap 5.10BETA1 ( http://nmap.org ) at 2009-12-04 14:58 CET
Nmap scan report for 10.0.42.5
Host is up (0.0054s latency).
Not shown: 97 closed ports
PORT   STATE SERVICE
22/tcp open  ssh
23/tcp open  telnet
80/tcp open  http
MAC Address: 00:14:BF:60:19:A2 (Cisco-Linksys)
Device type: switch
Running: Linksys embedded
OS details: Linksys SRW2000-series switch
Network Distance: 1 hop

OS detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 2.95 seconds

Wauw - det passer perfekt, switchen er en ældre Linksys SRW-2008 switch, og her er en pointe - Nmap og de andre programmet slår op i tabeller for at identificere OS - og her er der åbenbart noget unikt fra Linksys SRW2000-series, hvor der for andre er mere usikkerhed. Specielt er der mange små embedded enheder som bruger Linux idag og de vil naturligvis ligne hinanden.

Med nogle operativsystemer får vi således ret præcise resultater:

hlk@bigfoot:hlk$ sudo nmap -O -p1-100 10.0.42.15

Starting Nmap 5.10BETA1 ( http://nmap.org ) at 2009-12-04 15:00 CET
Nmap scan report for 10.0.42.15
Host is up (0.0018s latency).
Not shown: 97 closed ports
PORT   STATE SERVICE
22/tcp open  ssh
80/tcp open  http
88/tcp open  kerberos-sec
MAC Address: 00:16:CB:AC:1D:9F (Apple Computer)
Device type: general purpose
Running: Apple Mac OS X 10.5.X
OS details: Apple Mac OS X 10.5 - 10.6 (Leopard - Snow Leopard) (Darwin 9.0.0b5 - 10.0.0)
Network Distance: 1 hop

OS detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 1.70 seconds

Mens andre ikke er med i de kendte fingerprints - min OpenBSD 4.6 eksempelvis:

hlk@bigfoot:hlk$ sudo nmap -O -p1-100 10.0.42.44 

Starting Nmap 5.10BETA1 ( http://nmap.org ) at 2009-12-04 15:02 CET
Nmap scan report for turbi (10.0.42.44)
Host is up (0.0011s latency).
Not shown: 95 closed ports
PORT   STATE SERVICE
13/tcp open  daytime
21/tcp open  ftp
22/tcp open  ssh
37/tcp open  time
80/tcp open  http
MAC Address: 00:40:63:C9:F3:11 (VIA Technologies)
No exact OS matches for host (If you know what OS is running on it, see http://nmap.org/submit/ ).
TCP/IP fingerprint:
OS:SCAN(V=5.10BETA1%D=12/4%OT=13%CT=1%CU=41602%PV=Y%DS=1%DC=D%G=Y%M=004063%
OS:TM=4B191674%P=i386-apple-darwin9.8.0)SEQ(SP=100%GCD=1%ISR=102%TI=RD%CI=R
OS:I%II=RI%TS=22)SEQ(SP=105%GCD=1%ISR=10B%TI=RD%CI=RI%II=RI%TS=21)SEQ(SP=10
OS:5%GCD=1%ISR=107%TI=RD%CI=RI%II=RI%TS=21)SEQ(SP=108%GCD=1%ISR=107%TI=RD%C
OS:I=RI%II=RI%TS=21)SEQ(SP=105%GCD=1%ISR=106%TI=RD%CI=RI%II=RI%TS=22)ECN(R=
OS:Y%DF=Y%T=40%W=4000%O=M5B4NNSNW0%CC=N%Q=)T1(R=Y%DF=Y%T=40%S=O%A=S+%F=AS%R
OS:D=0%Q=)T2(R=N)T3(R=N)T4(R=Y%DF=Y%T=40%W=0%S=A%A=Z%F=R%O=%RD=0%Q=)T5(R=Y%
OS:DF=Y%T=40%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)T6(R=Y%DF=Y%T=40%W=0%S=A%A=Z%F=R%
OS:O=%RD=0%Q=)T7(R=N)U1(R=Y%DF=N%T=FF%IPL=38%UN=0%RIPL=G%RID=718F%RIPCK=G%R
OS:UCK=G%RUD=G)U1(R=Y%DF=N%T=FF%IPL=38%UN=0%RIPL=G%RID=6ECD%RIPCK=G%RUCK=G%
OS:RUD=G)U1(R=Y%DF=N%T=FF%IPL=38%UN=0%RIPL=G%RID=2E13%RIPCK=G%RUCK=G%RUD=G)
OS:U1(R=Y%DF=N%T=FF%IPL=38%UN=0%RIPL=G%RID=15CA%RIPCK=G%RUCK=G%RUD=G)U1(R=Y
OS:%DF=N%T=FF%IPL=38%UN=0%RIPL=G%RID=A8E0%RIPCK=G%RUCK=G%RUD=G)IE(R=Y%DFI=S
OS:%T=FF%CD=S)

Network Distance: 1 hop

OS detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 12.59 seconds

Usikkerheden bliver ligeledes forværret hvis der ikke modtages svar fra både åbne og lukkede porte. Over internet vil det således ofte være sværere at bruge dette alene til at identificere OS. I disse tilfælde vil man bruger Nmap eller telnet til at interagere med portene - og det kan Nmap gøre med -A option.

hlk@bigfoot:hlk$ sudo nmap -A -p1-100 10.0.42.44 

Starting Nmap 5.10BETA1 ( http://nmap.org ) at 2009-12-04 15:05 CET
Warning: Unable to open interface vmnet1 -- skipping it.
Warning: Unable to open interface vmnet8 -- skipping it.
Nmap scan report for turbi (10.0.42.44)
Host is up (0.0014s latency).
Not shown: 95 closed ports
PORT   STATE SERVICE VERSION
13/tcp open  daytime
21/tcp open  ftp     bsd-ftpd
22/tcp open  ssh     OpenSSH 5.3 (protocol 2.0)
|  ssh-hostkey: 1024 4b:8d:0c:ed:33:ce:39:bd:75:89:b1:b1:e8:15:86:b4 (DSA)
|_ 2048 45:38:a1:8e:ab:e1:f9:b3:d7:c7:11:00:37:41:6c:55 (RSA)
37/tcp open  time    (32 bits)
80/tcp open  http    Apache httpd
|_ html-title: Test Page for Apache Installation
MAC Address: 00:40:63:C9:F3:11 (VIA Technologies)
No exact OS matches for host (If you know what OS is running on it, see http://nmap.org/submit/ ).
TCP/IP fingerprint:
OS:SCAN(V=5.10BETA1%D=12/4%OT=13%CT=1%CU=40390%PV=Y%DS=1%DC=D%G=Y%M=004063%
OS:TM=4B191761%P=i386-apple-darwin9.8.0)SEQ(SP=105%GCD=1%ISR=10E%TI=RD%CI=R
OS:I%II=RI%TS=21)SEQ(SP=103%GCD=1%ISR=10D%TI=RD%CI=RI%II=RI%TS=21)SEQ(SP=10
OS:8%GCD=3%ISR=10D%TI=RD%CI=RI%II=RI%TS=22)SEQ(SP=FF%GCD=1%ISR=109%TI=RD%CI
OS:=RI%II=RI%TS=21)SEQ(SP=108%GCD=1%ISR=108%TI=RD%CI=RI%II=RI%TS=21)ECN(R=Y
OS:%DF=Y%T=40%W=4000%O=M5B4NNSNW0%CC=N%Q=)T1(R=Y%DF=Y%T=40%S=O%A=S+%F=AS%RD
OS:=0%Q=)T2(R=N)T3(R=N)T4(R=Y%DF=Y%T=40%W=0%S=A%A=Z%F=R%O=%RD=0%Q=)T5(R=Y%D
OS:F=Y%T=40%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)T6(R=Y%DF=Y%T=40%W=0%S=A%A=Z%F=R%O
OS:=%RD=0%Q=)T7(R=N)U1(R=Y%DF=N%T=FF%IPL=38%UN=0%RIPL=G%RID=476C%RIPCK=G%RU
OS:CK=G%RUD=G)U1(R=Y%DF=N%T=FF%IPL=38%UN=0%RIPL=G%RID=338B%RIPCK=G%RUCK=G%R
OS:UD=G)U1(R=Y%DF=N%T=FF%IPL=38%UN=0%RIPL=G%RID=37D3%RIPCK=G%RUCK=G%RUD=G)U
OS:1(R=Y%DF=N%T=FF%IPL=38%UN=0%RIPL=G%RID=BC2B%RIPCK=G%RUCK=G%RUD=G)U1(R=Y%
OS:DF=N%T=FF%IPL=38%UN=0%RIPL=G%RID=67C7%RIPCK=G%RUCK=G%RUD=G)IE(R=Y%DFI=S%
OS:T=FF%CD=S)

Network Distance: 1 hop
Service Info: Host: localhost.kramse.org; OS: Linux

HOP RTT     ADDRESS
1   1.35 ms turbi (10.0.42.44)

OS and Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 29.38 seconds

Bemærk at dette stadig ikke finder OS med OS detection, men at bsd-ftpd og OpenSSH 5.3 tyder på en BSD maskine og mange ved at OpenBSD (uvist af hvilken grund) stadig har port 37 åben som standard. En tur til http://10.0.42.44 viser da også en default side for OpenBSD med logo og det hele :-)

Konklusion

Hvad er så konklusionen på ovenstående?
Jo den er, at der er en stor grad af valgfrihed og derfor er Operativsystemer forskellige på IP niveau. Dette kan bruges til at detektere operativsystemer relativt præcist, og indimellem helt ned til release, kerneniveau eller service pack.

Hvad man så vil bruge den viden til er op til en selv, men det er meget sandsynligt at en angriber over internet vil kunne skræddersy et angreb bedre med den viden :-)