1. I'll send a sequence of small ip packets (udp|tcp) to certain ports in a certain order to a server destination.
Since TCP creates a connection, a port scanner would list that as ports, even if the "server" would not send any answer.
UDP could be an option.
Not necessarily, you can use e.g. libpcap that sniff the packets.
2. The servers has got a daemon that sniffs all incoming packets, filtered too, on certain interface and waits for udp 213. If such a packet arrives, the daemon checks whether the other packets arrives in a certain time in that order or not.
You would have to accept a broad range of ports then (at least the ones you use as code.
libpcap sees every packet and we can fork a new daemon when a good signature packet arrives
Why not make a server listen to a specific UDP port, waiting for a special (containing some code) packet, that will trigger the suggested behaviour? There is another problem with UDP (or TCP to different ports), please correct me if im wrong ;): It is not guranteed that the packets will arrive in a certain order, its possible that packets could arrive later even if you send them off before some other packets.
Thats true, packets need not to come in, in the order they were send. Simple delay should solve this.
or any other suggestions for that. And YES, somebody might name this security through obscurity.
Yes it is :). But the concept to have a certain connection trigger a specific system state can be nice (e.g. give the firewall your dynamic ip, so that it will let your ssh to it). But then again, having my firewall rules dynamically changed by outside influences is not something i would want in my firewalls.
Peace, Tom
Anyway, will seeking on Michael