unimportant leaks through to error section

[LeoNeeson]

hfs and iptables work with different levels, and thus different protocol.
HFS could also not give reply, but at its level. The level below, the tcp, already answered, so the peer knows you have an open port.

Thanks for the explanation of TCP/IP layers. (HFS can only control the " Application Layer" at the top highest level), but one of the other 3 lower layers are answering first (spoiling the purpose of hiding our server). That's easy to understand (and to solve this, we would need to involve the system firewall, and it would get too-complicated). But, keep reading....

» Workaround: I've investigated about this, and I've found here a very smart idea to artificially create a connection timeout error: HFS could make a redirect to a no-nexisting IP or a no-nexisting port. For example, you could forward to a non-used random port, or a non-routable IP address (which is the best option), such to any IP on those ranges: 10.0.0.0-10.255.255.255, 172.16.0.0-172.31.255.255, or 192.168.0.0-192.168.255.255, or point it to an external domain for that purpose (not the best idea), like is said here, like:

Code: [Select]

http://example.com:81/
http://httpstat.us/504?sleep=60000

The best is using some random IP on this range: 172.16.0.0-172.31.255.255. You could name this macro as {.fakedrop.} or any other name you want. What do you think?...

[rejetto]

nice try but your attempt makes sense only if you work with a browser: that's not exactly the way an attacker work. If you scan the ports you will just see an answer from that port, and even a redirection is still an http response.

And deven with the browser the redirection would be displayed with a change in the address bar.

[LeoNeeson]

Oh!... then forget it (since it would be useless).
[Those hackers! make us our life complicated]