unimportant leaks through to error section

[danny]

If [error-page] is present, that content will be a response, to ban/disconnect/scanner
Next,
No matter if [error-page] section is present or not, contents of [overload] will be a response to banned/disconnect/scanner

This is unintentionally verbose/pingable. 

Also, if you do the hide-root thing, throwback14 is rigged not to leak at / but, if you ask for url/File, the overload section is the response even if you don't have a folder named file.   Apparently, /file has a special meaning and exists always. 

Here is a patch: 
Delete the [error-page] section (if any).  Throwback14 doesn't have it.
And also,
The [overload] section should start off with 3 filter macros: 
{.if|!%user%|{:{.if|{.%url% = /.}|{:{.disconnect.}:}.}:}.}{.if|!%user%|{:{.if|{.%url% = /file.}|{:{.disconnect.}:}.}:}.}{.if|!%user%|{:{.if|{.%url% = /File.}|{:{.disconnect.}:}.}:}.}
Does:  Don't send extra messages to strangers seeking /, /file, /File. 
Pseudocode:  If  stranger caused overload at / then disconnect; and, if  stranger caused overload at /file then disconnect; and, if stranger caused overload at /File then disconnect.

If there are more built-ins, then the filter which starts the [overload] section should be revised to:
{.if|!%user%|{:{.disconnect.}:}.}
Pseudocode:  Don't send overload message to strangers. 
I updated my home server to that, because I don't know how many built-ins there are (such as /file which exists always). 

The question is:
Should the security update be done at the template or at hfs.exe? 
If it was a good idea to put the security update into a template, then I'd need to ask a moderator to unlock the Throwback template thread. 

Severity:
Least Impact.  Almost none.  Hideroot style security effort is not expected to succeed on port80; and common scanners don't check every uncommon port to see if web servers respond to /file, because it is unfeasible to use a scanner in that way. 


In my opinion:
A template could not be fully effective at hideroot security efforts (not a total means of security, but it lasts until a change).  A template could do either least or more verbose response.  Only hfs.exe could do zero response.  Perhaps an option could be added for make no response to / nor to any folders which don't exist?  I'm glad that Throwback and Takeback have better inbuilt security than any other templates; however, I think it would be a bit more effective if the .exe did the job.  Again, the security-gap reported is least-impact (of least concern).  But, it could be improved.

[LeoNeeson]

Thanks for the report. I think Throwback14 doesn't need to be updated, since it was a template meant for v2.3x. Most users are still using the last stable v2.3m, so, I think those who doesn't like the new changes will stay on that version. The new v2.4 has changed a lot of things, so, we like it or not, those changes are here to stay...

Anyway, I hope Rejetto could review your comment.
Cheers,
Leo.-

[danny]

Thanks for the report. I think Throwback14 doesn't need to be updated, since it was a template meant for v2.3x. Most users are still using the last stable v2.3m, so, I think those who doesn't like the new changes will stay on that version. The new v2.4 has changed a lot of things, so, we like it or not, those changes are here to stay...

Anyway, I hope Rejetto could review your comment.

Thanks! 
I would like to see the update in the .exe because macros are not completely effective for silence.

[rejetto]

hi, HFS 2.4 sadly won't be compatible with 2.3 templates.
The error-page behavior can be a consequence for an old template. If you didn't have [error-page] before you just need to put a line at the end of the tpl with just [error-page]
At the moment you cannot make a template that works on both, must make 2 versions.
I think i can easily introduce a way to have the same template specify that a section is for a specific version, so to have a single file.
We are collecting some rules about new templates at http://rejetto.com/forum/index.php?topic=13326.0

No matter if [error-page] section is present or not, contents of [overload] will be a response to banned/disconnect/scanner

not to banned. For those there is [ban].
Now that I think of it, this [error-page] is a leftover of when we had no {.scripting.}.
Maybe we should dismiss it. I don't know if this is a good time.

Should the security update be done at the template or at hfs.exe?

i guess you are talking about your script that disconnects if you are not logged in.
That behavior doesn't seem so universally desirable. There are many users with publicly accessible servers.
This other behavior can be packed in a *.diff.tpl file (new feature) and installed by those who want it.
And we should make a sort of repository/directory for these "plugins".

I would like to see the update in the .exe because macros are not completely effective for silence.

can you tell me in what way they are less effective

[Mars]

sugestion...

{.if|!%user%|{:{.if|{.%url% = /.}|{:{.disconnect.}:}.}:}.}{.if|!%user%|{:{.if|{.%url% = /file.}|{:{.disconnect.}:}.}:}.}{.if|!%user%|{:{.if|{.%url% = /File.}|{:{.disconnect.}:}.}:}.}

replaced by :

{.if|!%user%|{:{.if|{.match|^\/([Ff]ile(\/)?)?$|%url%.}|{:{.disconnect.}:}.}:}.}

can be tested at  https://regexr.com/ or https://regex101.com/tests

mask = ^\/([Ff]ile(\/)?)?$

working text
/
/file
/file/
/File
/File/

[rejetto]

mars, i didn't know you like regexp. Good job
guys, remember to translate the ! into a not, because you don't have that syntax available in hfs

{.if not|%user%|{:{.if|{.match|^\/([Ff]ile(\/)?)?$|%url%.}|{:{.disconnect.}:}.}:}.}

or

{.if|{.and|{.not|%user%.}|{.match|^\/([Ff]ile(\/)?)?$|%url%.}.}|{:{.disconnect.}:}.}

and for fun i discovered that in this case you can even do like this

{.{.if|{.and|{.not|%user%.}|{.match|^\/([Ff]ile(\/)?)?$|%url%.}.}|disconnect.} .}

[danny]

...can you tell me in what way they are less effective

Macros could disconnect after connect; but, Only the .exe could do silence.  That's the difference.
It would be better if hide-root functionality were a clickable option in the .exe's gui. 
Perhaps it is a feature request? 
Use case:  When you don't want to reveal the presence of a web server.   

...Now that I think of it, this [error-page] is a leftover of when we had no {.scripting.}...

Throwback and Takeback don't have a generic [error-page] section.
 However,
The other, specific sections are very useful to prevent or fix errors.

hi, HFS 2.4 sadly won't be compatible with 2.3 templates.

That's okay.  Except that auto-ban functionality needs to be added to hfs.exe as a clickable option in the gui. 
I think temporary auto-ban, such as, fail login 5 times, then your ip won't connect for an hour.  Because of recent changes, that option is now needed in the .exe. 


Edit:  HFS 2.4 is more verbose at [error-page] with both a symbol and a footer that shows on the web browser--see attachment

[LeoNeeson]

Sometimes I write posts offline and then I forget to publish them.
The following is a message related to THIS post:

HideRoot.tpl (19.52 kB)

Although this is a nice way of making the server 'invisible', it will not fool an experienced network user. Your template is working, but it currently 'closes' the connection right away (almost instantly), and the browser displays: "Connection Interrupted - The document contains no data." (and this is an almost instant response, giving the impression that there is a server behind this IP). Correct me if I'm wrong, but a true realistic dead IP (without an existent server behind), will make the browser display a 'timed out' page, since the browser was waiting for a server response that will never had come, and finally, after waiting 15 or 20 seconds, the browser will be displaying something like: "Network Timeout - The operation timed out when attempting to contact xxx.xxx.xxx.xxx." (this normally happens when you try to open an IP that has no server behind).

Macros could disconnect after connect; but, Only the .exe could do silence.  That's the difference.
It would be better if hide-root functionality were a clickable option in the .exe's gui. 
Perhaps it is a feature request?

I like your idea, but how about instead of using a 'disconnect' macro command (to close the connection), implementing (if HFS doesn't already have it) a macro to 'drop out' the connection (without giving a 'close' answer, to force the browser displaying a 'timed out' page). What do you think?...

Cheers,
Leo.-

[danny]

Sometimes I write posts offline and then I forget to publish them.
The following is a message related to THIS post:Although this is a nice way of making the server 'invisible', it will not fool an experienced network user.

It is only slightly better if that macro is in the events file in [+request] section.
Unfortunately, it will still make a response.

Your template is working, but it currently 'closes' the connection right away (almost instantly), and the browser displays: "Connection Interrupted - The document contains no data." (and this is an almost instant response, giving the impression that there is a server behind this IP). Correct me if I'm wrong, but a true realistic dead IP (without an existent server behind), will make the browser display a 'timed out' page, since the browser was waiting for a server response that will never had come, and finally, after waiting 15 or 20 seconds, the browser will be displaying something like: "Network Timeout - The operation timed out when attempting to contact xxx.xxx.xxx.xxx." (this normally happens when you try to open an IP that has no server behind).
I like your idea, but how about instead of using a 'disconnect' macro command (to close the connection), implementing (if HFS doesn't already have it) a macro to 'drop out' the connection (without giving a 'close' answer, to force the browser displaying a 'timed out' page). What do you think?...
Cheers, Leo.-

I think that security functions of hide-root and temp-auto-ban should go in hfs.exe gui menu to make them more available.   

However, if there was also a {.drop.} macro on offer, same function as iptables drop, I'd like that.

[rejetto]

Macros could disconnect after connect; but, Only the .exe could do silence.  That's the difference.

the exe disconnects only after connection. On this they are the same.
I also expect both methods to disconnect without sending bytes, if that's what you mean by silence.
The only difference i expect is that the script may take 1ms longer to do it, maybe less.
Therefore, I'd say there's no difference on the quality of their "silence", but let me know if I'm mistaken and how.

By the way, recently i've made some research to understand if it is possible for a server to see the address before accepting a connection, and possibly ignore the connection itself, but found nothing. Only software working at lower level than server seems to be able to do it. I still have some hope to find something but it's not a priority.


I also want to point that the script blocking the "/file" is not useful.
I was focusing on helping with the scripting, but I want to stress that there is no special meaning with /file, so there's no reason to treat it.
As I said in my first reply, the problem danny experienced was caused by the template being not compatible with 2.4 .

if reply/bytes are not sent then you cannot tell what protocol is the server for.
Alas, as i just said, there's no way to selectively ignore connections, but I accept suggestions.

That's okay.  Except that auto-ban functionality needs to be added to hfs.exe as a clickable option in the gui. 
I think temporary auto-ban, such as, fail login 5 times, then your ip won't connect for an hour.  Because of recent changes, that option is now needed in the .exe. 

I don't understand why you say that the changes made important for that feature to be in the GUI. The things seem unrelated to me.
By the way, did someone achieved this feature by scripting?

Edit:  HFS 2.4 is more verbose at [error-page] with both a symbol and a footer that shows on the web browser--see attachment

this is the effect of the incompatibility that i mentioned. If you want to use the tpl with 2.4 you will have to make some changes.
sadly 2.4  being not final i cannot exclude further changes.

like your idea, but how about instead of using a 'disconnect' macro command (to close the connection), implementing (if HFS doesn't already have it) a macro to 'drop out' the connection (without giving a 'close' answer, to force the browser displaying a 'timed out' page). What do you think?...

this is the "impossible" thing i was talking above. The browser says 'timed out' if the connection is not established (in time).

[Mars]

mars, i didn't know you like regexp. Good job

{.if not|%user%|{:{.if|{.match|^\/([Ff]ile(\/)?)?$|%url%.}|{:{.disconnect.}:}.}:}.}

or

{.if|{.and|{.not|%user%.}|{.match|^\/([Ff]ile(\/)?)?$|%url%.}.}|{:{.disconnect.}:}.}

and for fun i discovered that in this case you can even do like this

{.{.if|{.and|{.not|%user%.}|{.match|^\/([Ff]ile(\/)?)?$|%url%.}.}|disconnect.} .}

thanks for the compliment but the regexp are hard to digest for my mind

your last example can't work, it's a false positive, this example proves it

[test]
start
{.{.if|%user%|stop server.} .}
{.add to log|all is good.}
end


in your second line the expression {.match|^\/([Ff]ile(\/)?)?$|%url%.}  is always evaluated, which can have an influence on the rest of the script (duration or content)

the first one seems the best choice in terms of evaluations

{.if not|%user%   |{:
   {.if|{.match|^\/([Ff]ile(\/)?)?$|%url%.}|{:{.disconnect.}:}.}
:}.}

similar to

if not (%user%) then
   if match('^\/([Ff]ile(\/)?)?$', %url%) then
      disconnect();
 

[LeoNeeson]

this is the "impossible" thing i was talking above. The browser says 'timed out' if the connection is not established (in time).

Your explanation seems reasonable. Although, I thought it could be done (about HFS not giving an answer, to let drop some connection request). But you said "I also expect both methods to disconnect without sending bytes", so, that's why the client's browser says: "Connection Interrupted - The document contains no data.". But if the client says the connection was 'interrupted', it was because the client has received some kind of response before (like, when negotiating a connection request).

It is only slightly better if that macro is in the events file in [+request] section.
Unfortunately, it will still make a response.

Exactly, if a {.drop.} macro is implemented, it should go on [+request] section.

I think that security functions of hide-root and temp-auto-ban should go in hfs.exe gui menu to make them more available. However, if there was also a {.drop.} macro on offer, same function as iptables drop, I'd like that.

Yes, what I've said is similar to an iptables drop. To explain this better, I've found a related question HERE: What is the difference between reject and drop in iptables?:

When using REJECT rules an ICMP packet is sent indicating the port is unavailable. The difference is that the REJECT target sends a reject response to the source, while the DROP target sends nothing. This can be useful e.g. for the ident service. If you use REJECT then the clients doesn't need to wait for timeout.

From my understanding (correct me if I'm wrong), HFS's macro {.disconnect.} sends to the client a "close" command (to the client). My idea was NOT giving that reply and ignore the client request (to let the connection drop). But if not possible, then don't worry. It was only to help danny (I personally don't need that feature), although it could be cool feature to avoid being attacked by bots (if the server admin has a private server that doesn't want to be found).

Cheers,
Leo.-

[rejetto]

your last example can't work, it's a false positive, this example proves it
[test]
start
{.{.if|%user%|stop server.} .}
{.add to log|all is good.}
end

i tried your test and works well here, i don't know why you say it's a false positive

[rejetto]

But if the client says the connection was 'interrupted', it was because the client has received some kind of response before (like, when negotiating a connection request).

yes, the tcp connection was already established, you are perfectly right.
You guys didn't study how tcp/ip works, the layers, that's why the confusion. I'm in a rush but i'll try to explain quickly.
The webserver is a layer on top of the tcp.  Like you asked the vicepresident (tcp) to talk to the president (the webserver), the vice says 'ok wait' but then the president just hangs up.
It would be interesting to find a way to instruct the vicepresident.
One chance is to instruct the system firewall through {.exec.}. If someone has the time can try to build script doing it
https://docs.microsoft.com/en-us/powershell/module/netsecurity/?view=win10-ps&redirectedfrom=MSDN&viewFallbackFrom=winserverr2-ps

From my understanding (correct me if I'm wrong), HFS's macro {.disconnect.} sends to the client a "close" command (to the client). My idea was NOT giving that reply and ignore the client request (to let the connection drop).

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. That's why HFS not sending the 'close' is useless. I didn't make an {.ignore.} command because  you wouldn't get more privacy, and you would keep the port open just consuming a system resouce.

[danny]

Thanks for the explanations, examples and help. 
Especially for the note that some of this should go in the events file.