Nmap Development mailing list archives
Re: symmetry in nping echo protocol
From: "Luis MartinGarcia." <luis.mgarc () gmail com>
Date: Wed, 16 Feb 2011 17:38:38 +0100
Hi Toni, Sorry for taking so long to respond to your email. Here are some of my thoughts:
Would it make sense for the echo server to include information about the message it is sending to the encrypted response packet, so one could do some reasoning both ways by just looking at the client.
This is something I considered last year, when I designed the protocol. However, as you noted in your second email, there are some challenges associated with it. The first problem is that the server has no easy access to the responses, as they are generated by the server's TCP/IP stack, and not by the echo server itself. However, responses could be sniffed and then sent to the client through the side channel, just like we do with client packets. This is possible, but not as easy as it sounds, since the echo server would need to infer what kind of packet the server is going to generate as a reply. TCP-SYNs may generate TCP-SYN|ACK but also ICMP time exceeded, ICMP parameter problem, no response at all due to local filtering, etc. If the echo server was isolated and did not receive any other traffic than the one generated by an Nping echo client, then we could just fire up the sniffer and send a copy of any received packets to the client. Unfortunately, our scenario is not that ideal. Echo clients can serve multiple clients at the same time and can be installed on servers that offer other network services as well. Also, clients cannot be easily identified by their source IP address since one user may run multiple instances of the echo client simultaneously, or many users may connect to the server with the same source IP because they are behind a NAT device. We could, however, take another approach. We could use the client and server as we now do and then, just reverse the roles but keeping the same side channel. It would be something like this. Let C be an Nping echo client and S be an Nping echo server: C connects to S. C sends packets to S. S echoes packets to C. C compares sent packets with the packets that the server captured and echoed through the side channel. Now, C tells S that it finished sending packets. S starts sending the same kind of packets to C. S echoes the packet that is sending to C. C captures S's packets and compares them with the packets obtained through the side channel. This would let the clients determine if the packets are being treated the same way in both directions of the communications. One could find that packets are being dropped in one direction but not on the other, that packets are taking different routes, etc. This is something I'll probably be working on in the next few months, so stay tuned. I haven't studied this approach with enough detail so I'm still not sure if it's possible to implement it or even if it's worthy, but I'm open for discussion if you are interested on the topic. Best regards, Luis MartinGarcia. _______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://seclists.org/nmap-dev/
Current thread:
- symmetry in nping echo protocol Toni Ruottu (Feb 13)
- Re: symmetry in nping echo protocol Toni Ruottu (Feb 13)
- Re: symmetry in nping echo protocol Luis MartinGarcia. (Feb 16)
- Re: symmetry in nping echo protocol Toni Ruottu (Feb 16)
- Re: symmetry in nping echo protocol Luis MartinGarcia. (Feb 16)
- Re: symmetry in nping echo protocol Toni Ruottu (Feb 13)