rejetto forum

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - LeoNeeson

Pages: 1 2 3 ... 47
Beta / Ideas to enhance the anti-DoS mechanism
« on: June 28, 2020, 07:05:27 AM »
the anti-dos mechanism.
@Rejetto: After doing some research on how a typical 'Denial-of-Service' (DoS) is done, which basically consists on overloading a server, I want to contribute with my overall opinion about the Anti-DoS feature.

IMHO, the current implementation is an overkill (I mean, is nice you have implemented some anti-DoS, but for me it's way too-much over-protective). My ideas are:

A) Have different limits for upload, than for download.
B) Give downloads a more relaxed limit than the current one.
C) Count how many requests were done every 5 sec (read below)
D) Limit uploads to only one per 1/second or one per 5/secs.
E) Limit the repetition of downloading the same file, 1 file per 10/secs.
F) Limit/slowdown the request of serving pages (not the internal elements)
G) Have a 'maintenance mode' for extreme cases, limiting everyone but the admin

Some points are self-explained.

About point "C" (counting how many request were done every 5 sec, for the same SessionID), if you give the server admin an option, the admin could configure his server according how many pages are typically needed to be requested (when doing normal usage). For example, seeing Danny's example, if he has a photo gallery, and his page needs to serve 20 thumbnails at once (20 is an invented number for this example). Then, it would be normal to have 20 requests in a 5 seconds time-frame.

About point "F", if a page needs to serve only 10 elements (1 html + 1 css + 2 js + 6 images), then it's normal to have 10 requests in 1 or 2 seconds. So, an even smarter (automatic way), would be HFS automatically counting how many elements the page have (when parsing the template), and applying on-the-fly the limits (if the requests exceed the elements found for the requested page). This would be a behavior limit, since HFS knows how many elements needs the page, and it would let HFS distinguish a legitimate user from an attacker. This, along with limiting how many pages could be served per second, could let us have a more relaxed download rate for elements (like images, css, js), but a more strict limit to request new pages, for example, when exploring folders, we could only serve 1 every 2 seconds, avoiding (or delaying) when the user opens several tabs at the same time.

About point "G", finally, if HFS detects is being attacked (in an very extreme/hard way), then the server could automatically go in 'maintenance mode' for 1 hour (applying a more strict request rate for everyone during that hour), and in that time-frame, it will only allows to login the admin (so he can take care of his server and review the configuration).

This is a good read I recommend about DoS. Also, please read THIS (it explains why 'Rate limitation is not the way to go').

Well, I leave you these ideas.
Do what you think is best... :)

Yes, your server could be overloaded. Go to:

Menu > Limits > Max simultaneous downloads:

And write there: 2

(If your users complain, increase the value to 3)

About night/dark skins, you can search here. There, you will find all the skins (templates) for the client side (or better wait for the next HFS version 2.4, which will have by default a dark skin option). The server side, can not be skinned.

Just a friendly reminder: HFS is not FTP! :) (HFS is a HTTP server). FTP is a completely different protocol.

I don't have other ideas to help you (perhaps other users could help you more). Please write back if this has solved your problem.


Bug reports / Re: unimportant leaks through to error section
« on: June 16, 2020, 07:38:44 AM »
Oh!... :o then forget it (since it would be useless).
[Those hackers! >:( ;D make us our life complicated]

Beta / Re: 2.4 template-making guide
« on: June 16, 2020, 07:26:55 AM »
i don't think mars suggested that, so i will consider it your suggestion ;D
I must have misunderstood his message then (or he inspired me that idea). :P ;D

My white-list idea is having on the template a place where we declare all the public sections at once. For example, something like this (see the line marked in red color):


This way, it's much easier to visualize all the public sections at once (and it's less work when adapting the old templates, since it's just adding one line of text). This is only an idea (it's currently not implemented). What the rest of you think about it?...

Sometimes we would link to items which are located inside of the .exe. I can't edit to add public to those.
I guess if Rejetto implements this, it would not be required to declare 'public' a link like "/?mode=jquery".


Ваша конфигурация HFS это нормально.

Включение DMZ не рекомендуется. Гораздо лучше открыть нужные порты на вашем маршрутизаторе (это также называется: переадресация портов или 'Port Forwarding'). Для этого следуйте инструкциям, которые вы найдете здесь или здесь.

Вопрос: как вы обновляете свой IP-адрес на:
(мне гораздо проще помочь вам, используя английский язык)


Bug reports / Re: unimportant leaks through to error section
« on: June 15, 2020, 02:05:45 AM »
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:,, or, or point it to an external domain for that purpose (not the best idea), like is said here, like:
Code: [Select]

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

Beta / Re: 2.4 template-making guide
« on: June 15, 2020, 12:32:43 AM »
This mean all the sections that needs it should set a 'public' flag (as opposite to the 'private'), and the 'private' would just be ignored. [...] Comments?
Since v2.4 won't be compatible with 2.3 templates, I think the idea is good.

wouldn't it be simpler to name the accessible sections by url by preceding their name with ~( except for [] ) as [~login]. this would no longer pose a problem of interpretation and unnecessary option writing
I also like Mars's comment, of doing a "white-list" of allowed sections (with the name of the 'most common' and 'most used' sections). Sections on the white-list doesn't need to have a 'public' flag (the could have it, but it would not be mandatory). And all the sections that are NOT in the white-list would be automatically 'private'. So, the logic would be: if a section doesn't have a 'public' flag, and is neither on the 'white-list', then that section is private.

Since we talk about changes, how about changing the way to call a section (and file sections) "~" to "?" (since that's the most common way of doing it). For example: "/?login" (instead of "/~login"), or "/?lib.js" instead of "/~lib.js". This would bring consistency with the current: "/?mode=jquery". If I'm not mistaken, this idea was on the to-do list. To keep compatibility, you could make both ("~" and "?") as valid options.


Приве́т. Добро пожаловать на форум! :)

Пожалуйста, сделайте скриншот этого окна:
> Menu > IP address


Beta / Re: version 2.4
« on: June 11, 2020, 03:58:33 AM »
I think that with the help of silentpliz we could manage to offer you a module that would be easily integrated into hfs
I vote to have this by default (even if we don't have HTTPS yet). It's better to have some security, than no security at all. I like the work Mars has done. :)

Beta / Re: 2.4 template-making guide
« on: June 11, 2020, 03:54:05 AM »
I thought declaring an empty [error-page] would make the section empty, but it's still inheriting the default template.
Probably this was always the behavior with diff tpl but nobody noticed.
I noticed it some months ago (when I was doing the form-based login), but I thought it was 'too much' to report it (I didn't wanted to bother you with such a small detail). I even thought it was not a mistake, but that it was done it on purpose to avoid having to write part of the 'head' section every time (so, I didn't report it). I can't remember other details now, but those were my 'breaking balls' small details that I was referring here. :D ;D (Now I do understand that I have to report if I've found something, because it could be an important detail).

Bug reports / Re: unimportant leaks through to error section
« on: June 11, 2020, 02:45:25 AM »
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).


Bug reports / Re: unimportant leaks through to error section
« on: June 10, 2020, 08:08:29 PM »
Sometimes I write posts offline and then I forget to publish them. :P
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" (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?... :)


Beta / Re: version 2.4
« on: June 10, 2020, 06:15:24 AM »
as i just said, if we find that's necessary to have an option we'll have an option.
OK, I already knew you will not like my suggestion... :-[ ::) But hey, you did a great job with Nginx! :) (you can be happy about it). Rejetto: from now on, you can breathe relieved when you see a message from me, since I will not be reporting new more things about v2.4.x, because I don't want to be the guy who always 'break the balls' with small details (non voglio essere il che 'rompe le palle' sempre con piccoli dettagli :D). I officially leave the "reporting things" task for the rest of you (beside that, my free time is much more limited now).

@MarkV: thanks for the command line explanation of generating a cert with OpenSSL. It's always nice not having to rely on some external service. I will try it as soon I have some free time. (It's nice to have you on-board :))


Bug reports / Re: unimportant leaks through to error section
« on: June 10, 2020, 06:08:44 AM »
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... :-X ::)

Anyway, I hope Rejetto could review your comment.

I like the 'search files & folders' window, and all the template looks very modern. Good job!. :)

Pages: 1 2 3 ... 47