Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    bad nginx errors in system logs

    Scheduled Pinned Locked Moved General pfSense Questions
    9 Posts 2 Posters 886 Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • N
      nononono
      last edited by

      I believe the firewall has some concerning entries of inbound connection requests:

      Mar 6 07:00:35	nginx		2023/03/06 07:00:35 [error] 55818#100189: *18269 open() "/usr/local/www/.env" failed (2: No such file or directory), client: 109.237.97.180, server: , request: "GET /.env HTTP/1.1", host: "XXXXX (local ip)"
      Mar 6 07:39:51	nginx		2023/03/06 07:39:51 [error] 55818#100189: *18295 open() "/usr/local/www/robots.txt" failed (2: No such file or directory), client: 185.142.236.43, server: , request: "GET /robots.txt HTTP/1.1", host: "XXXXX (local ip)"
      Mar 6 07:39:53	nginx		2023/03/06 07:39:53 [error] 55604#100190: *18296 open() "/usr/local/www/sitemap.xml" failed (2: No such file or directory), client: 185.142.236.43, server: , request: "GET /sitemap.xml HTTP/1.1", host: "XXXXX (local ip)"
      Mar 6 07:39:56	nginx		2023/03/06 07:39:56 [error] 55818#100189: *18297 open() "/usr/local/www/.well-known/security.txt" failed (2: No such file or directory), client: 185.142.236.43, server: , request: "GET /.well-known/security.txt HTTP/1.1", host: "XXXXX (local ip)"
      Mar 6 10:32:12	nginx		2023/03/06 10:32:12 [error] 55818#100189: *18335 open() "/usr/local/www/robots.txt" failed (2: No such file or directory), client: 154.209.125.77, server: , request: "GET /robots.txt HTTP/1.1", host: "XXXXX (local ip)"
      Mar 6 16:35:54	nginx		2023/03/06 16:35:54 [error] 55818#100189: *20060 open() "/usr/local/www/remote/fgt_lang" failed (2: No such file or directory), client: 170.130.165.78, server: , request: "GET /remote/fgt_lang?lang=/../../../..//////////dev/cmdb/sslvpn_websession HTTP/1.1", host: "XXXXX (local ip)"
      Mar 6 16:35:54	nginx		2023/03/06 16:35:54 [error] 55604#100190: *20061 open() "/usr/local/www/owa/auth.owa" failed (2: No such file or directory), client: 170.130.165.78, server: , request: "POST /owa/auth.owa HTTP/1.1", host: "XXXXX (local ip)"
      Mar 6 16:35:55	nginx		2023/03/06 16:35:55 [error] 55818#100189: *20064 open() "/usr/local/www/remote/fgt_lang" failed (2: No such file or directory), client: 170.130.165.78, server: , request: "GET /remote/fgt_lang?lang=/../../../..//////////dev/cmdb/sslvpn_websession HTTP/1.1", host: "XXXXX (local ip)"
      

      What would be appropriate firewall rules to prohibit this access? I already have inbound WAN TCP/UDP requests to the firewall blocked but it appears I am looking at it from the wrong angle - any suggestions?

      S 1 Reply Last reply Reply Quote 0
      • S
        SteveITS Galactic Empire @nononono
        last edited by

        @nononono Those are not your IPs I take it? Do your block rules on WAN have a number by them indicating matching traffic? (I.e. not 0/0)

        Pre-2.7.2/23.09: Only install packages for your version, or risk breaking it. Select your branch in System/Update/Update Settings.
        When upgrading, allow 10-15 minutes to restart, or more depending on packages and device speed.
        Upvote ๐Ÿ‘ helpful posts!

        N 1 Reply Last reply Reply Quote 0
        • N
          nononono @SteveITS
          last edited by nononono

          @steveits yes those are external IPs, and yes the rule I have should only block TCP/UDP requests to the firewall itself on WAN, since the last firewall reboot it is showing 0/0

          See attached:
          Firewall Rule

          S 1 Reply Last reply Reply Quote 0
          • S
            SteveITS Galactic Empire @nononono
            last edited by

            @nononono The 0/0 shows it isnโ€™t matching. There must be a rule above it allowing access.

            Pre-2.7.2/23.09: Only install packages for your version, or risk breaking it. Select your branch in System/Update/Update Settings.
            When upgrading, allow 10-15 minutes to restart, or more depending on packages and device speed.
            Upvote ๐Ÿ‘ helpful posts!

            N 1 Reply Last reply Reply Quote 0
            • N
              nononono @SteveITS
              last edited by

              @steveits see the full ruleset here, probably missing something obvious: pfsense_localhost_-_Firewall__Rules__WAN.png

              S 1 Reply Last reply Reply Quote 0
              • S
                SteveITS Galactic Empire @nononono
                last edited by SteveITS

                @nononono This is for WAN? The last rule allows all inbound traffic. Or is this LAN and the block is on the wrong interface?

                Edit:
                Nvm, the block rule has WAN address as the source so it would only trigger if the packet arrived from itself. A source of */any would be packets arriving from the Internet.

                rules are processed as the packet arrives on a given interface.

                Pre-2.7.2/23.09: Only install packages for your version, or risk breaking it. Select your branch in System/Update/Update Settings.
                When upgrading, allow 10-15 minutes to restart, or more depending on packages and device speed.
                Upvote ๐Ÿ‘ helpful posts!

                N 1 Reply Last reply Reply Quote 0
                • N
                  nononono @SteveITS
                  last edited by

                  @steveits it is WAN, what would be a good way to filter our NGINX requests, but allow WAN to stay open for: OpenVPN, Wireguard, and zone usage for gaming/etc

                  For both VPNs could put in those ports manually, anything else that could be broke by getting stricter and blocking all else?

                  S 1 Reply Last reply Reply Quote 0
                  • S
                    SteveITS Galactic Empire @nononono
                    last edited by

                    @nononono Yeah only allow the desired ports or โ€œtheyโ€ will just hammer them. Better is to allow by source IP, perhaps using a dynamic DNS hostname.

                    Your block rule needs to have any as the source of the packet. If desired you can block only ports 22/80/53/443/etc. but way better is to only allow what you want to allow.

                    Pre-2.7.2/23.09: Only install packages for your version, or risk breaking it. Select your branch in System/Update/Update Settings.
                    When upgrading, allow 10-15 minutes to restart, or more depending on packages and device speed.
                    Upvote ๐Ÿ‘ helpful posts!

                    N 1 Reply Last reply Reply Quote 0
                    • N
                      nononono @SteveITS
                      last edited by

                      @steveits fair enough, will just pivot to blocking all and only allowing ports that are confirmed in use, thank you for the confirmation

                      1 Reply Last reply Reply Quote 0
                      • First post
                        Last post
                      Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.