2. Limitations

By looking at the tests nmap performs, one can notice that they are all based on abnormal or at least weird packets, hence easy to detect, so as to send counter-measures.

This way, it seems possible to change replies from a local machine when we receive such packets. However, these changes have some drawbacks:

• some characteristics of OS are related to the host architecture (for instance page sizes on various CPU) which could lead to performance issues;
• some of these changes are more "political" choices of the IP stack (initial sequence numbers, window sizes, TCP options available...). Tweaking those allow to fool a scanner but might break regular connectivity by changing network parameters. It could also make the system weaker if the emulated IP stack is not as strong as the initial one.

However, such modifications are possible in most cases for the local host. But it is not so easy when it comes to routed hosts:

• since the local host doesn't know the exact state of a remote IP stack, not all tests can be done there, making it hard to guess a valid response for a remote host;
• the behavior of routed hosts can hardly be changed "live" because there's no way for the gateway to tell routed hosts how it changed their packets;
• any piece of information discarded on the remote hosts cannot be "restored" on the gateway (except by keeping the whole traffic...);
• the gateway shouldn't "create" information. That is, if we consider a test to which the remote hosts would not reply, if the gateway was replying to it, then it would also reply for hosts that are down.