Hiding Passive Fingerprint

[Fred K. Abell Jr._1]

P0F looks at IP packets to determine what operating system a machine is using. It looks at TTL, MTU, whether or not the DF flag is set, and other parameters to identify what operating system is sending the packets. I wish to use NDD to modify these parameters to make my HP-UX box look like another operating system, but I do not want to impact performance significantly. Dropping the TTL to 128 or 64 will not make an impact, but I do not know how the other parameters will affect performance. I would like my box to look like another variation of UNIX, a windows machine, or even Commodore 64. Any suggestions?

[Armin Kunaschik]

I don't think you will succeed here, unless you have the source code of HP-UX and enough knowledge to modify internal TCP/IP code.
I guess this is not possible (at user or admin level) with any operating system, even if you have the source code like Linux.
But you can hide your applications behind firewalls and application level gateways.

My 2 cents,
Armin

[Matti_Kurkela]

To look like a plain Commodore 64 is easy: just disconnect all network cables. :-)

If your system is intended to be used only e.g. inside the company's internal network, use a firewall or the IPFilter software (available from software.hp.com) to ensure your machine only communicates with known, trusted IP addresses.

If the service your server is providing is intended to be available for everyone in the world (i.e. a publicly-accessible Web server), there are some things you simply cannot hide and still keep providing the service. P0F is constructed to specifically look for these things.

You simply must be able to withstand anything thrown at you... so the first thing would be to limit the number of publicly-accessible ports and services to those ports required by the intended application and nothing more. Disable any services that are not required: less code to run = less chance for new security vulnerabilities to be applicable to you.

Then you should keep your server up to date and become aware of any known vulnerabilities in your server software.

"Don't put all your eggs in the same basket": assume that your publicly-available servers will be hit by a some sort of attack at some point in the future. Make sure that the applications you use internally are not dependent on the server(s) that provide public services.

Remember: security by enforcement ("the attacker can try, but is guaranteed to fail") always beats security by obscurity ("the attacker doesn't know how to do it").

MK

[Fred K. Abell Jr._1]

Glad to see someone got the Commodore 64 joke. But it does show our age.

I am behind a firewall and a my systems are hardened very well, including IPFilter (I just love the return-rst for tcp). NDD can be used for everything I want to do. I just want to change to signature of the packets. My problem is will I hit the performance?

[Matti_Kurkela · Accepted solution]

You'd need a real TCP/IP guru to get good answers, but I'll try...

Dropping the TTL:
As long as the number of network hops between you and the other connection endpoint is less than or equal to the value of TTL, you don't lose any performance. But when the number of network hops exceeds the TTL, you get a total loss of performance: your packets will no longer reach the other endpoint before the TTL expires.

This is fairly insidious, because you're likely to think all is well. Meanwhile, someone on another continent and/or within a large and complex corporate network sees your server as no longer responding at all.

The MTU and the DF flag:
These two things belong together. When the DF flag is set, it usually means the sender of the packet is doing "Path MTU discovery" to avoid the need to fragment packets at any step between the connection endpoints. If some network hop requires lower-than-standard MTU value, packets with the DF flag set cause an ICMP error message "Fragmentation Needed" to be sent back to the originator of those packets. This is a clue for the sender to use a smaller MTU value for that particular connection only. Sending as big packets as possible is good, because it minimizes the protocol overhead: you'll need to transfer a minimum amount of header information per unit of data.

If the DF flag is not set, any router can split your packets into fragments if necessary to make them fit through a lower-than-usual-MTU network hop. Fragmenting requires the router to spend more processing power to deliver your packets, and may increase latency. Nearer the receiving end, a firewall may require that all fragments of a packet be received before the packet may be passed through: in this case, the firewall will usually de-fragment the packet for the recipient. This may cause another increase in latency.

Unfortunately, there may be some badly-configured or overloaded firewalls that may block any fragmented packets instead of de-fragmenting them. In this case, switching off the DF flag might cause loss of connectivity.

In short, the effect of switching off the DF flag will be highly dependent on who you're communicating with and what's between you and him.

Simply dropping the MTU value will decrease the efficiency of any outgoing transfers that are larger than the MTU value.

MK