-
Notifications
You must be signed in to change notification settings - Fork 11
Notification if shadowd not reachable #5
Comments
I have thought about this many times. I did not add it yet, because I don't want to reveal the presence of the firewall to attackers. That's where the shadow part of the name comes from. But I guess it would be nice to optionally offer this functionality via a configuration parameter. I will add this once I find some time. |
I would rather place a log entry into phperror and present the normal response code (not a hardcoded 200 or any other, it may cause problems with redirections ) so the firewall is not revealed but functionality isnt interrupted, though issue is recorded into error.log |
Thanks for the input. The error is already written to the web server log file if enabled in the configuration file. Not interrupting functionality is a bit hard though, because without the shadowd backend the connector has no way to tell if a request is an attack or not. Letting every request pass could be a big security risk and I try to make it "secure by default". Even more so since you probably would not notice that the firewall is not active anymore, so you think you are protected when you really are not. Maybe I will add this as a setting too though, so if some people really want to let such requests pass they have the possibility to do so. |
An alternate notification method would be useful, also you could require a "management IP" which gets some error page about non working shadowd in case, but for others the app should simply go 403 for example. secure by default, and detailed issue info for the management IP, how about that? |
A "management IP" sounds like a stats-page like haproxy implemented it . That would require some more vhost-configuration (my first suggestion via http-code too...) What does an e-mail notification sounds like? You should be able to send mails, there is a reporting function implemented. |
I thought on management IP a bit other way round: if my management IP is A.B.C.D, when i visit my protected site from that IP i would presented a "sorry shadowd not reachabe i cannot protect you" instead of a 403 access denied |
I like both ideas. I think I will just implement both and let the users decide for themselves which one they want to use (or both at the same time). |
I'm currently testing shadowd and the php-connector.
After rebooting my test-VM I've got 500 because shadowd was not running. At first I was searching the logs until I noticed that shadowd was not running.
I know it's my fault for not enabling shadowd on boot but for this situation I have a feature to suggest:
Why not make is possible to define a custom http-status if the connector can not connect to its server?
Maybe something like an (yet) undefined HTTP-statuscode.
Based on the webserver it should be possible to provide a custom error-page if the application returns e.g a 555 http-status.
This would also allow a monitoring-system to alert its operator if its not possible to check for a running shadowd on server side. And its nicer for the visitor to see a custom error-page than a 500.
In short:
This is a feature-request for a setting inside the connector to set a custom http-status on a not working connection to shadowd.
The text was updated successfully, but these errors were encountered: