Security DevCenter
oreilly.comSafari Books Online.Conferences.

advertisement




Network Tool Development with hping3
Pages: 1, 2, 3

What particular limit or feature does the language itself bring?

One of the best features that Tcl gives you is that you can specialize it so much to have a domain-specific language designed to play with packets. The limitation of all this flexibility is speed. For example, in theory you can use hping3 to write a firewalling engine, but in reality you can't go beyond a "prototype" because a firewall needs to be fast.

How does the TCL scripting engine communicate with the C core?

Related Reading

Network Security Assessment
Know Your Network
By Chris McNab

Tcl is designed to communicate with C, so it's pretty simple. The entire hping engine is exported to Tcl as a single Tcl command, so hping3 scripts are just Tcl scripts with a unique new command able to do a lot of new things related to packets and TCP/IP that are not possible with plain Tcl.

How does the C core work?

The C core is the sum of the hping2 code, used to provide command-line compatibility in this initial stage, and the new hping3 code. I'll focus on the latter. The core is comprised of different layers; the first layer is called ARS, which provides low-level packet construction and analysis. It works describing packets as different layers. For example, a packet can have two layers: IP and TCP. These layers are then "compiled"--the compilation will take care of computing checksums and dependencies between layers, so that, for example, the IP layer will get the total length field set according to the following layers, and so on. This way users of the library don't need to do too much and can just create a packet adding layers, and finally compiling the packet. The packet can be created as you like, but still the checksums, option paddings, and lengths will be OK. As I stated, ARS is also able to do the reverse--given a binary packet, it can be split into layers, modified, and then recompiled and possibly re-sent.

The higher level API is APD (ARS packet description). Basically this layer uses strings to represent ARS layers, so complex packets can be generated starting from human readable descriptions of layers like ip{saddr=1.2.3.4,daddr=5.6.7.8}+icmp{type=3,code=3} and so on, or binary packets can be translated into the string representation.

Given that APD packets are just strings, they are very natural to bind to Tcl, which is a language mainly based on strings.

Does hping3 take advantage of multi-CPU hardware?

No, for now at least, but there aren't plans to add support for threads because Tcl is mainly event driven in design. (Actually, Tcl is able to support threads pretty well; I just like more the event-driven way.)

I saw a lot of names in the credits page; could you tell us who did what?

Most of the contributions are limited to bug fixes or the addition of minor features, so I don't remember exactly who did what, with the exception of Nicolas Jombart, who provided significant help and code for the BSD port.

I tested hping3-alpha2 on FreeBSD and OpenBSD, and I found out that some scripts and docs are completely Linux oriented. Can we say that there's space in the development team for some BSD experts to improve the portability, especially on *BSD systems?

The goal of hping3 is to fully support at least Linux, *BSD, and Mac OS X. Currently most of the work is focused on Linux because that's the main development platform I use, but as happened for hping2, the BSD port will become more stable after some time. Actually hping3 is already working on BSD and Mac OS X, but there was far less testing on those platforms--what I mean is that most of the BSD port is already in the source code.

Do you plan to port hping3 to commercial systems like Solaris, Mac OS X, and Windows?

OS X for sure; it already works as well as the BSD port itself. I received some reports that hping3 is almost working on Solaris, which will eventually be semi-supported, but we will never claim to aim for Solaris support. Windows is a much more interesting target because of the big user base, and because there is already a working hping2 port (wiki.hping.org is where to go if you want to try it in your Win32 box), and most of hping3's OS-dependent code is either on the Tcl side, which is perfectly supported on Win32, or in functions for packet transmission and reception that can be easily extracted from hping2.

Are you looking for any developer? Which area would you like to add manpower to?

Now that hping3 is a programming environment, I'm looking for developers to provide interesting scripts written utilizing hping3 itself. Another interesting area is IPv6. hping3 is based on the ARS library, which is designed to be modular, so adding IPv6 shouldn't be hard.

Do you plan to create a repository for .htcl scripts created by the community like Nessus does?

Yes, it's one of my main goals once hping3 is widely used enough.

I've read some short docs on wiki.hping.org and some in the hping tarball. Are you looking for people to write more extensive documentation?

Yes! The goal of the Wiki is just that, to build a collaborative site in order to document hping directly online.

When do you think that hping3 will be stable enough to be released? I'm a little suspect that the release process could require a mythological time like Doom 3 did.

[Laughing] Actually it has already taken a lot of time, but now it's in the classic 98 percent done stage. The last 2 percent is very hard to do, but I think that the next time I don't have a big workload it will take another little jump. I hope that in 6 to 12 months at most I'll find the time to push hping to 3.0 stable.

Pages: 1, 2, 3

Next Pagearrow






Sponsored by: