> Yes, you can use anything as a transport, probably even pidgeon > carriers, but you need a receiving end to effect anything.
Indeed, see RFCs 1149 and 2549... two excellent april fools on avian carriers! > So, unless > you fear that someone is able to install a trojan on your OpenBSD > server by sending it ICMP packets encapsulating something in their > payload that results in a program (so far already requiring a big > remote-root hole in the kernel) and also have it run with root > privileges, probably by expoiting some other unknown hole in OpenBSD, > then switching off ICMP is a good precaution. In all other cases, I > think that it's quite stupid. Agreed, there are some services (like these ones offered by ICMP messages) that MUST remain enabled. Worst of all, when someone blocks application layer tools like ping(1) and traceroute(1) by means of these filters he is not only restricting his ability to trace network problems but sometimes the ability to trace problems from other networks too. People should understand what services are required and what services are superfluous. Not all people needs an SMTP listening on public addresses (sendmail listens by default to the loopback interface in OpenBSD and it is required for a lot of internal services that sometimes send email), telnet or RPC enabled by default, but time synchronization services (time, daytime), SMTP on non-public interfaces (for these services sending email to system users), the auth service (for fast SMTP responses), and submission (RFC 2476) are required. No one wins stopping these services, though. Just take a look at other operating systems (I am thinking on most Linux flavours and operating systems) to see what I want to say with "superfluous services enabled by default". There is a difference between a machine running countless services by default and other strictly following recommended practices. In my humble opinion, NIST is wrong if they recommend blocking ping and traceroute. They should update that recommendation, as I feel that most problems we have here tracing network issues are a consequence of people blindly following these advices. Cheers, Igor.
