> Since you've reduced the problem set a great deal, yes, something like > that is reasonable. Forcing the client to behave in a deterministic > fashion is a big help as is a single request/reply per socket > connection. Limiting yourself further to only a single use case is > huge. Of course, the more limits you place the less useful this is to > a wide audience.
Well, you'd be surprised at how applicable this still is. Off the top of my head, I can think of two areas: 1) Client-side Application (e.g., Browser) Testing 2) Capture and Replay of Client Side Attacks Again, the initial solution would not completely satisfy these two problems, but it would make a *significant* dent in dealing with them. For example, being able to replay an exact 0-day malware exploit from a one-shot PCAP file is a huge win, from an information security perspective. Frankly, I'm really surprised there are no open source efforts to address this -- I'm guessing most existing work is probably closed source. > The other issue, is pretending to be multiple network devices (the DNS > server, default gateway, yahoo & google servers in your example). > > So there are two ways to solve this problem: > > 1) your pcap to server application, opens up TCP/UDP sockets in order > to answer responses. Since you're using DNS, in your example, you > could make sure yahoo & google resolve to yourself. > > 2) your pcap to server application uses raw frame injection and > promiscuous mode on the network interface to read & write packets onto > the network. This allows you to pretend to be hosts on other > networks. > > #1 is simpler in that now you don't have to write your own TCP/IP > stack or worry about ARP's as much (your OS will handle that for you). > > #2 is simpler because you don't have to worry about protocols which > embed IP address information in the packets which later cause problems > (DNS, FTP, SIP all have this problem as can others) since you'll be > able to spoof the original IP address of the server(s) in the pcap. > You'll probably have to write a simple ARP responder too. Good points. I think #2 is probably a more robust approach as faking the lowest layer obviates the need to rewrite any of the higher layers. >> 2) Could any of the tcpreplay code be used to accomplish a fraction of >> this goal? (Such as identifying and extracting the application layer >> content for each request to build the corresponding array entries?) > > There are probably other tools I'd look at as the starting point- > tcpreplay isn't really designed to work at the flow/session level. I > probably would look at libnids and tcpflow. Both have issues though, > libnids has a horrible API IMHO and tcpflow only works with live > networks (not pcaps). But both are flow/session aware. Hrm, okay, thanks for the pointers. > Honestly, if you only wanted to do that single test case, the simplest > thing would be to install Bind & Apache and configure bind to resolve > yahoo & google to your local box and have Apache serve up the > appropriate pages via vhosts. That would take an experienced sysadmin > an hour or less. If I were simply dealing with static pages, sure; however, I'm trying to do a little application layer re-writing / munging as possible. By focusing on resolving the issues at the lowest layers possible, the overall solution can eventually impact protocols other than HTTP. ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects _______________________________________________ Tcpreplay-users mailing list Tcpreplay-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tcpreplay-users Support Information: http://tcpreplay.synfin.net/trac/wiki/Support
