How to make omv-gui log forwarded for IP because of fail2ban

  • Hi :)

    I run my omv gui behind an nginx proxy.
    This is done with these settings (nginxproxy as docker container on omv directly) :


    Which should be pretty standard settings.

    But my issue is that in /var/log/auth.log it logs the IP of the nginx container instead of the actual source IP for fail2ban.
    (yes I am exposing publicly with basic auth ontop)


    How do I make omv log the real IP and not the proxy IP so basically make it respect the headers?


    Didn't find a thread detailing that unfortunately :(

    Thanks a lot!

  • ryecoaaron

    Hat das Thema freigeschaltet.
    • Offizieller Beitrag

    You probably haven't found a thread that details how to do it because exposing the OMV interface to the internet is a bad idea. I would use a VPN to access OMV remotely.

  • Aurelio

    Hat das Label OMV 6.x hinzugefügt.
    • Offizieller Beitrag

    I am aware of the implications.

    Okay. Doing this is making it easier for you to get hacked, but it is your server.

    I would still like to have the WebGUI become aware of the proxied for IP.

    You would have to find a way to generate a volume in the container that writes the logs to the host. And after that have fail2ban read those logs. I don't know what the practical way to do all that would be.

    As that rather seems like a non-working default standard to me.

    I don't think that's the case. I doubt the plugin is designed to do this.

  • I don't think that's the case. I doubt the plugin is designed to do this.

    I mean that the webgui implementation does not log the IP in the x-forwarded-for header as the source IP. but just the IP where the request came from. Thats what i would like to change/fix to make it adhere to the standard fo respecting the x-forwarded-for header.

  • Same here, exactly what Aurelio says.


    Running currently a complete dockerized Caddy Reverse Proxy/Authelia/Crowdsec/GeoIP config and have set trusted IP ranges in Crowdsec. Since OMV does not read the x-forwarded-for header, auth.log just shows the Caddy container IP which is inside the trusted range, so Crowdsec parses the logs without detecting attacking scenarios for the OMV Webservice itself.


    Authelia is working incl. the corresponding Crowdsec plugin, but giving Crowdsec more logs means also more security.

    We are in 2024, and the possibilites to design public exposed private sites in a damn secure way was never easier as now.

    I know that OMV is not a money driven project and it's damn nice. But "uSe a vPN iNsTEaD" seems to be the solution for everything here and that doesn't feel right regarding the possibilities today.

    • Neu
    • Offizieller Beitrag

    We are in 2024, and the possibilites to design public exposed private sites in a damn secure way was never easier as now.

    I know that OMV is not a money driven project and it's damn nice. But "uSe a vPN iNsTEaD" seems to be the solution for everything here and that doesn't feel right regarding the possibilities today.

    In that case you can contribute with the appropriate procedure. Possibly there is no such procedure because no one has bothered to implement it, in general there is not much interest in publishing the OMV GUI on the internet for obvious reasons.

  • We are in 2024, and the possibilites to design public exposed private sites in a damn secure way was never easier as now.

    I know that OMV is not a money driven project and it's damn nice. But "uSe a vPN iNsTEaD" seems to be the solution for everything here and that doesn't feel right regarding the possibilities today.

    Then share the solution for us common mortals, please.

    This is a open source community and contributions are always welcome.


    I can throw out some snippets that I gathered but never managed to make them work.

    Maybe you can make something out of it.


    Long time ago, I made a reverse-proxy sample to use via SWAG for OMV access via WAN.

    It still works but the IP seen on F2B is, indeed, the one from the docker NET (172.x.x.x).


    Taking the example from Nextcloud, the snippet that I found that might be used on OMV is this:

    Code
    # display real ip in nginx logs when connected through reverse proxy via docker network
    set_real_ip_from 172.16.0.0/12;
    real_ip_header X-Forwarded-For;


    It is mentioned inside Nextcloud container on the file:


    Will it be able to be applied on the openmediavaultgui site?

    Who knows...


    I will try to add it only on my reverse-proxy and see if it won't break anything.

  • Will it be able to be applied on the openmediavaultgui site?

    Who knows...


    I will try to add it only on my reverse-proxy and see if it won't break anything.


    Thanks for the suggestion, seems indeed to be as simple as that. Add

    set_real_ip_from YOUR_REVERSE_PROXY_IP;

    real_ip_header X-Forwarded-For;


    at the end of /etc/nginx/openmediavault-webgui.d/security.conf


    sudo service nginx reload. Bam...correct IPs in access and auth log. Will it survive an update, I don't know. But it works.

  • Since OMV does not read the x-forwarded-for header,

    So you think that OMV is running a customized TCP/IP stack?


    I will try to add

    Maybe also add real_ip_recursive on;


    IMO, it seems like if you expect fail2ban, authelia, wtf ever to trigger enough to warrant logging, then you really should log everything all the time. There's sooooooooo many logging modules/code for nginx, I've even seen commerical "solutions".

  • So you think that OMV is running a customized TCP/IP stack?

    Correction: OMV nginx config does not use the header by default since it's not meant to run behind a proxy setup I guess.

    Maybe also add real_ip_recursive on;


    IMO, it seems like if you expect fail2ban, authelia, wtf ever to trigger enough to warrant logging, then you really should log everything all the time. There's sooooooooo many logging modules/code for nginx, I've even seen commerical "solutions".

    na, thanks, but my currently running solution is enough for me, including parsed omv logs now.



    Had no intention to open a fundamental discussion.

  • Had no intention to open a fundamental discussion.

    It's not a discussion, per se.

    By sharing different perspectives, you can see things in a better way.


    The snippet I posted made my "troubleshooting mind" see that it might work.

    To you, it made sense.

    To olduser made him consider other points.


    Since OMV isn't designed (yet) to be accessed via WAN, all we can do, is try to make it work with what we have.

    If it can be improved, perfect.


    You edited a file that is controlled by OMV and it will (probably) be reverted at any giving time:

    Code
    USER@HOST:~ $ cat /etc/nginx/openmediavault-webgui.d/security.conf
    # This file is auto-generated by openmediavault (https://www.openmediavault.org)
    # WARNING: Do not edit this file, your changes will get lost.

    Since the OMV uses a include function:

    Code
    USER@HOST:~ $ cat /etc/nginx/sites-available/openmediavault-webgui
    # This file is auto-generated by openmediavault (https://www.openmediavault.org)
    # WARNING: Do not edit this file, your changes will get lost.
    ---------------
        include /etc/nginx/openmediavault-webgui.d/*.conf;

    Maybe it's better to add the snippet to a NEW file (reverse.conf for eg)

    sudo nano /etc/nginx/openmediavault-webgui.d/reverse.conf

    add the snippet

    restart


    Perhaps votdev can add a ENV to be used OR you v1rusnl can make a pull request on github.


    Me, I prefer to make the changes on the reverse-proxy (if they work) and keep OMV as vanilla as possible.

  • After thinking about your post, I guess I was to blind to see that openmediavault-webgui nginx conf includes everything in openmediavault-webgui.d :P


    So I created an own conf file inside webgui.d instead of putting the real IP snippet in security.conf.


    So bottom line for is that I don't think add an ENV or a pull request is needed, since perhaps main OMV parts should remain clean, as you said.

    The possibility for people who'd like to tinker around with the config have the possibility to throw in their snippets via openmediavault-webgui.d.

    Most people will probably never need this.


    Thanks for the support!

  • Most people will probably never need this.

    There's a few of users that have/want WAN access.

    I'm one of them and had always a bit of trouble making F2B working.


    So, bottom line now is:

    Is it working properly?

    Did you tested it and did it blocked/banned the external IP?


    Asking since this has been an "Aquilles heel" on my installation after OMV7.

    Debian12 now uses systemd to control the logs and the JAILs on F2B are a bit strange on how they are controlled.

    Since OMV can still use auth.log, it works "normal" but SSH is still awkward.

    To give some context, if you want, see this:
    fail2ban doesn't work SSH in OMW 7 - Plugins - openmediavault

  • I'm still on OMV6, but using Crowdsec in meantime instead of f2b. The problem for me was always that every service (OMV, kuma, portainer, ombi, code-server etc.) throws out another http error code for wrong logins or even no one at all since the services had their own error log , so a lot of this was not visible in caddy as reverse proxy. Only solution for me was to regex error codes that have also a high false positive rate. So I switched to crowdsec which goes a bit further.


    But to answer your question: Yes, remote IPs are forwarded correctly to OMV, at least on my system. To go further I would switch to Crowdsec in Docker or Podman (with collections of your used services; there a are a tons in cs hub) to also offensively block commonly known malicious IP adresses. I could not believe that it's also less ressource hungry than f2b. Last but not least, a geoblock restricted to Germany stopped 99% of suspicios guests on my public domains.


    If you need a Docker Compose with AIO Caddy/Crowdsec/GeIPUpdater, CS firewall bouncer config file etc. let me know.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!