Mathematicians have known since Euclid that axioms are important.
Security, though, is math embedded in the real world, and that
matters. Put another way, Euclidean geometry is completely valid as a
pure mathematical system. But that doesn’t mean it applies in a
relativistic universe. Sure, we live far from any space-warping
masses, so we can pretend that the angles in our triangles add up to
180 degrees. In the security world, though, the attacker will toss a
black hole at us to warp the space around our provably-secure
triangular encryptor. Was that proof of security flawed? Ask Riemann
or Lobachevsky.

Halberd has been tested in real world scenarios for quite some time and it seems to be solid. I hope the wider audience it is gaining now will uncover some bugs and after fixing those I’ll think of it as stable software. Future work could happen in the following areas:

• Clustering algorithm
• The module Halberd.clues.analysis currently implements an ad-hoc hierarchical clustering algorithm to isolate possible real servers. I would like halberd to report to the user the degree of trust he should place in its conclusions.
• I think the way to go would be to test some algorithms in R (fuzzy clustering comes to mind) using real world data and see what works best before implementing anything.
• SSL session reuse
• When an SSL/TLS session begins, the server issues an SSL session ID to the client. This ID will be used to resume transactions between client and server (remember the stateless nature of HTTP).
• Some load balancers can keep track of which real server dealt with which SSL session and direct the client to the right server (the one having the client’s session ID in its cache). This could be used by halberd as an extra technique to enumerate real servers.
• Test suite improvements
• The test harness is tied to my own development environment. This should change.
• More tests never hurt.

You can be use halberd as a stand-alone command or as a Python module to be imported by other software.

Here it is for your enjoyment.

Accurate models of how the Internet works give insight into where its weakest links are located and how to simulate the network’s behavior under certain circumstances.

Part of the lecture’s data was acquired using traceroute and thorny technical details like detecting aliased IPs and load balancers were skipped.

Some highlights of the talk are:

1. Usage of economic models and current technological constraints to model the network (the resulting topology should be efficient).
2. Pitfalls of paying too much attention to power laws.
3. Differences between the real Internet and scale-free networks.

I believe some of the points the author makes could be applied as well to overlay (P2P) networks.

Further links:

• A First-Principles Approach to Understanding the Internet’s Router-Level Topology
• Towards a Theory of Scale-Free Graphs: Definition, Properties, and Implications (Extended Version)

In what ways do you use the Nmap XML output? Do you parse it from within a higher level program, transform it to HTML with XSLT, use it to populate a database, use XPath to parse the results from the command-line in a way that is as easy as awk/sec/cut/etc. on the normal output, or something else entirely?

I’ll share here my approach to nmap output parsing.

For my automated scans I use a combination of Python, Bash and AWK scripts. I always keep nmap scans in XML even if these will be used by some Bash/Awk scripts.

With Python I just parse the XML with libxml’s Python bindings.

With Bash and/or AWK I transform the XML output into PYX format with a custom made utility called xmltopyx.

For those not familiar with PYX, it is a way of converting XML documents into a more grep/AWK friendly format. More information about it can be found here and here.

An example of xmltopyx + AWK usage:

$ xmltopyx nmap-sample-tcpudp-portscan.xml | awk -f getports.awk
tcp 21 open ftp
tcp 22 open ssh
tcp 53 open domain
udp 53 open|filtered domain
tcp 111 open rpcbind
udp 111 open|filtered rpcbind
udp 608 open|filtered sift-uft
tcp 611 open npmp-gui
udp 636 open|filtered
tcp 639 open
udp 664 open|filtered
udp 667 open|filtered
tcp 670 open
tcp 953 open rndc
tcp 2049 open nfs
udp 2049 open|filtered nfs
tcp 3128 open squid-http
udp 3130 open|filtered squid-ipc
udp 3401 open|filtered squid-snmp
udp 4827 open|filtered squid-htcp
udp 32768 open|filtered omad
udp 32771 open|filtered sometimes-rpc6

Then, using getports.awk together with a while read proto port state service; do … ; done loop in Bash is very simple.

Each key on computer keyboards, telephones and even ATM machines makes a unique sound as each key is depressed and released, according to a paper entitled “Keyboard Acoustic Emanations” presented Monday by IBM research scientist Dmitri Asonov. All that is needed is about $200 worth of microphones and sound processing and PC neural networking software. Today’s keyboard, telephone keypads, ATM machines and even door locks have a rubber membrane underneath the keys. “This membrane acts like a drum, and each key hits the drum in a different location and produces a unique frequency or sound that the neural networking software can decipher,” said Asonov.

They said that although the name of a country had been blacked out in that memorandum, their software showed that it was highly likely the document named South Korea as having helped the Iraqis.