Archive

Archive for the ‘Network’ Category

FIRST2011: Listening to the network: Leveraging Network Flow Telemetry for Security Applications

June 15th, 2011 No comments
Phone Bill a CC NC ND image from Nikita Kashner's Flickr stream

Phone Bill a CC NC ND image from Nikita Kashner's Flickr stream

By Darren Anstee of Arbor Networks

Why is it a good idea to us flow information?

  • You don’t need to invest in new equipment to get flow information
  • It can be used to detect malware infected hosts, DDoS, zero-day exploits, attack and abuse
  • Network flows information is generated regardless if there was symmetric or a-symmetic routing

Network flow information is like a phone bill, you cannot tell what has been said, but you can use it to prove who talked to who.

So what does a flow record contain?

  • Source IP address
  • Destination IP address
  • Source port
  • Destination port
  • Input IfIndex
  • Protocol
  • Type of Service
  • packet count
  • Byte count
  • First packet time
  • Last packet time
  • Output ifIndex
  • Etc…

Read more…

ESXi: issues with NFS datastore. Where do I put my tcpdump?

February 4th, 2011 1 comment

ESXi over NFS works just great!

But what if you have an issue with NFS and you need a network dump? 

In ESXi tipically you don’t have a local datastore where you can write files from the network dump and your datastore over NFS is not availabe!

Before running into the Data Centre and stick a USB disk or even better a SCSI disk you might want to try this. ;-)

One trick I used that worked out pretty well for me, with a little help of my a linux machine, is to send the tcpdump output to a FIFO and from a remote host (might be a VM in a different ESXi host) over SSH cat the FIFO to a local file.

How To:
On the ESXi host logon via SSH as root and create a named pipe:

root@yourESXihost# mkfifo /tmp/pipe.dmp

and from a remote linux machine launch the following:

you@yourlinuxhost > ssh root@youresxihost "cat /tmp/pipe.dmp" > capture-for-wireshark.cap

Now from a new ssh session to ESXi as root lauch

root@yourESXihost# tcpdump-uw -n -s 1524 -i vmk# -w /tmp/pipe.dmp

OR even better from the remote machine:

you@yourlinuxhost > ssh root@youresxihost "tcpdump-uw -n -s 1524 -i vmk# -w /tmp/pipe.dmp"
(replace the # with the proper vmk port number)

Reproduce your issue and when you finished just hit  “Cotrol+C” to stop the network dump and the cat.
Now you can open your file directly in wireshark (that’s what I use at least!)

This little trick of course can be used to troubleshoot network problems in a VM as well, dumping the traffic from a VMK# nic for the entire dvPortGroup. You just need to make sure that the the VM’s vNIC and the vmk# nic are connected to the same dvPortGroup and you must remember to allow promiscuous mode (not allowed by default)

Good Luck!

Please note: your network can be very chatty so the file can grow very fast and/or your ESXi host might not like the tcpdump so use it at your own risk and only if you really know what you are doing!

SigINT10: P2P Communism vs. The Client Server State

May 23rd, 2010 No comments

By Dmytri Kleiner’s (Slides)Dmytri Kleiner's Avatar

Dmytri’s talk compares peer to peer and client server with communism and captalism. It is important that these terms refer to their original meanings:

  • Communism is a theoretical society with no classes and no state.
  • Capitalism refers to a society in which the owners of Capital are able to abstain from direct-production by appropriating the products of workers who employ their property in production.

Mesh networks can be compared to communism:

  • Participants can interact directly
  • No Toll Gate, No Prices

Read more…

Categories: Conferences, Network, Security, SigInt10 Tags:

Confidence 2009.02 – Router Exploitation – Felix “FX” Lindner

November 19th, 2009 No comments

Unlike the last time I was actually on time for Felix’ talk. Due to last nights activity I was surprised that he was on time himself. Again his slides included the Blackhat-O-Meter.

The first part of his presentation explained why routers are interesting targets (they are in the core), but also why routers are not actually exploited that much. One of the reasons is that the attack surface of router is quite small because routers don’t expose that much services to a truly remote attacker and are rarely used as clients.

The exception to the rule is “cisco-sa-20070124-crafted-ip-option” which is a remotely exploitable bug that causes a stack overflow on the router. Since “nobody ever updates router software” this vulnerability is still very much alive.

But routers need to support more and more, like IPv6, VoIP, XML configuration interface, luckily most services off.

Writing exploits for Cisco IOS is hard because it is not a real OS, but a single ELF binary. It is not based on a real OS we know hoe to exploit. Its only option to recover from a critical fault is a full reboot.

Another thing that makes exploitation hard is the memory layout. It is different from each single IOS version that it out there, and there are quite a few, currently there are over 270,000 different IOS images known by Cisco and you cannot get the version number remotely.

Read more…