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

    Taming the beasts… aka suricata blueprint

    Scheduled Pinned Locked Moved
    IDS/IPS
    64
    504
    265.0k
    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.
    • S
      squatch04
      last edited by

      @BBcan177:

      @squatch04:

      Getting a lot of these errors from lists in my syslog:

      php: rc.filter_configure_sync: The command '/usr/bin/fetch -T 5 -q -o '/var/db/aliastables/AbusePalevo.txt.tmp' 'https://127.0.0.1:43/badips/AbusePalevo.txt'' returned exit code '1', the output was 'fetch: https://127.0.0.1:43/badips/AbusePalevo.txt: Operation timed out'

      How did you configure the Alias Table? It Should be a "URL Table".

      I would also recommend just using the existing IR_ Tables that the Script already created. This saves you the effort of making dozens of Alias Tables.

      /usr/local/www/aliastables/IR_MAIL
      /usr/local/www/aliastables/IR_PRI1
      /usr/local/www/aliastables/IR_IB
      /usr/local/www/aliastables/IR_SEC1
      /usr/local/www/aliastables/IR_PRI2
      /usr/local/www/aliastables/IR_SEC3
      /usr/local/www/aliastables/IR_TOR
      /usr/local/www/aliastables/IR_SEC2
      /usr/local/www/aliastables/IR_PRI3

      Followed your suggestion and changed the URL Tables and it seems to be working (the IPs show up when i mouse over the Aliases) but i still get syslog errors.

      
Aug 30 09:40:26 	php: rc.filter_configure_sync: The command '/usr/bin/fetch -T 5 -q -o '/var/db/aliastables/IR_SEC2.txt.tmp' 'https://127.0.0.1:443/usr/local/www/aliastables/IR_SEC2'' returned exit code '1', the output was 'fetch: https://127.0.0.1:443/usr/local/www/aliastables/IR_SEC2: Operation timed out'

      Is this something to be concerned about?

      pfIP Rep widget shows last update was Aug 30 09:43 with status arrow green (up) though…

      1 Reply Last reply Reply Quote 0
      • BBcan177B
        BBcan177 Moderator
        last edited by

        @squatch04:

        Getting a lot of these errors from lists in my syslog:

        php: rc.filter_configure_sync: The command '/usr/bin/fetch -T 5 -q -o '/var/db/aliastables/AbusePalevo.txt.tmp' 'https://127.0.0.1:43/badips/AbusePalevo.txt'' returned exit code '1', the output was 'fetch: https://127.0.0.1:43/badips/AbusePalevo.txt: Operation timed out'

        I don't understand where the .tmp extensions comes from? It should end with .txt?

        If you are using the IR_ Alias URL Tables, I would remove URL Tables that are referencing the individual files as shown above. I would also delete these individual aliases in /var/db/aliastables

        Hope that Helps.

        "Experience is something you don't get until just after you need it."

        Website: http://pfBlockerNG.com
        Twitter: @BBcan177  #pfBlockerNG
        Reddit: https://www.reddit.com/r/pfBlockerNG/new/

        1 Reply Last reply Reply Quote 0
        • S
          squatch04
          last edited by

          @BBcan177:

          @squatch04:

          Getting a lot of these errors from lists in my syslog:

          php: rc.filter_configure_sync: The command '/usr/bin/fetch -T 5 -q -o '/var/db/aliastables/AbusePalevo.txt.tmp' 'https://127.0.0.1:43/badips/AbusePalevo.txt'' returned exit code '1', the output was 'fetch: https://127.0.0.1:43/badips/AbusePalevo.txt: Operation timed out'

          I don't understand where the .tmp extensions comes from? It should end with .txt?

          If you are using the IR_ Alias URL Tables, I would remove URL Tables that are referencing the individual files as shown above. I would also delete these individual aliases in /var/db/aliastables

          Hope that Helps.

          Hey BBCan177!

          i figured it out.

          1. "Operation timed out" was caused by the port being blocked. i had previously created a custom port and disabled anti-lockout so entering my port number 66 allowed the fetch command to access the list directory.
          2. Even though it passed using the custom port i still had the fetch error "not found".
            i confirmed my directory was correct which was "/usr/local/www/aliastables"
          
$ ls /usr/local/www/aliastables
IR_CC
IR_IB
IR_Match
IR_PRI1
IR_PRI2
IR_SEC1
IR_SEC2
IR_TOR

          It seems like the directory was already defaulted to "/usr/local/www/" when adding the URL tables so the shortened directory address of "https://127.0.0.1:66/aliastables/IR_SEC2" for example worked for all the IR Lists.

          1 Reply Last reply Reply Quote 0
          • F
            foetus
            last edited by

            Yah, to get back to my issue for future reference.
            I'll give the example with Google again. The particular problem was for a client that cannot afford to miss certain mails from some senders, including several other connections both in & out. (long story)

            I present this magnificent snip-it story.
            Either a manual alias is created, or a cron job to whois a company into a list. Lets take Google.

            cron job creating the list :

            List used in floating rules (disabled here, but you get the idea):

            Detailled :

            If i enable that rule => Because every Gmail server is matched in that rule, the package is matched, rule is applied (pass it) and thats it.
            My SMTP NAT rule does .. absolutely nothing. Its very easy to test in this case (enable & send mail = nothing, disable = instant mail received).

            Disabeling the quick option works offcourse. But if an IP i want to whitelist is ever blacklisted (i'm not saying it is, or will be any time soon, does not matter as its a direct request from the direction there) i'm screwed :).
            Since the blocklist beneath it will match, and will block.

            I comfirmed the issue with 2 setups, both are completely ignoring NAT after a floating rule match.

            OR
            I'm completely wrong, and being the fact it is whitelisted first (like normal interfaces rules - priority ruling) is enough? No quick option.

            For websites, DNS requests and the bunch its not an issue. Just where a forwarding rule has to be applied after seems to be impossible with floating rules.

            @BBcan17
            Haven't checked your updates yet, but since 2.1.5 altered DNS whois the DNS patch to include the lists doesn't show them anymore. Only updated 1 system thus far, so no idea if its a bug or not.

            edit
            woud be awesome if you could make a rule with "all ports except xyz". Just like its possible with hosts / networks.

            1 Reply Last reply Reply Quote 0
            • ?
              A Former User
              last edited by

              Don't see anything wrong with those, but then again not much is given.

              1. show the popup for the alias to see the IPs
              2. show the complete rules (just change public IPs to something obviously public, eg 1.1.1.1 and leave private IPs as private).
              3. show your floating rules tab
              4. Run a packet capture on the ingress + egress interfaces and post the redacted (just replace IPs to understand if it's going public or private) text. No need for a full transcript, "Normal" detail will do, just to see how the packets are flowing.

              I have traffic shaping rules limiting speeds to public IPs, which are in turn NATed to private ones and everything works perfectly, so as far as I can tell nothing gets ignored. And yes, that does apply to both inbound and outbound traffic.

              1 Reply Last reply Reply Quote 0
              • F
                foetus
                last edited by

                1.  
                list goes one quite a bit ;). Its not a problem its not loading or empty.

                2.  
                forwarding to alias (IP : 10.0.0.2 == internal exchange server)
                  The rule is applied on both WAN interfaces. Only MX record active on the VDSL interface in question (failover not yet active).
                3.
                Nothing but whitelist rule, rest is blocklist blocking.
                The 2 blocking rules beneath whitelist are to isolate a seperate physical network to acces the main network. (basically a block all from interface x to y). Then a rule to lock down internet acces during the night for the second network.
                4.
                capturing WAN when rule is applied gives me :

                00:47:40.700800 IP 209.85.220.177.38924 > <wanip>.25: tcp 0
00:47:41.699405 IP 209.85.220.177.38924 > <wanip>.25: tcp 0
00:47:43.699672 IP 209.85.220.177.38924 > <wanip>.25: tcp 0
00:47:47.699690 IP 209.85.220.177.38924 > <wanip>.25: tcp 0</wanip></wanip></wanip></wanip>

                etc

                disabling floating whitelist Google rule : (recaptured, the previous IP was another sender)

                00:42:47.405562 IP 209.85.220.181.42122 > <wanip>.25: tcp 0
00:42:47.405847 IP <wanip>.25 > 209.85.220.181.42122: tcp 0
00:42:47.522800 IP 209.85.220.181.42122 > <wanip>.25: tcp 0
00:42:47.523516 IP <wanip>.25 > 209.85.220.181.42122: tcp 100
00:42:47.641067 IP 209.85.220.181.42122 > <wanip>.25: tcp 0
00:42:47.641599 IP 209.85.220.181.42122 > <wanip>.25: tcp 31
00:42:47.641865 IP <wanip>.25 > 209.85.220.181.42122: tcp 191
00:42:47.759789 IP 209.85.220.181.42122 > <wanip>.25: tcp 10
00:42:47.760055 IP <wanip>.25 > 209.85.220.181.42122: tcp 29
00:42:47.878097 IP 209.85.220.181.42122 > <wanip>.25: tcp 186
00:42:47.878731 IP <wanip>.25 > 209.85.220.181.42122: tcp 1418
00:42:47.878768 IP <wanip>.25 > 209.85.220.181.42122: tcp 54
00:42:47.998797 IP 209.85.220.181.42122 > <wanip>.25: tcp 0</wanip></wanip></wanip></wanip></wanip></wanip></wanip></wanip></wanip></wanip></wanip></wanip></wanip>

                And the 3 test mails I send during the floating rule active get received 5 mins later (re-attempt by gmail server).

                Internal :
                rule on :

                22:51:47.917275 IP 209.85.220.174.48733 > 10.0.0.2.25: tcp 0
22:51:47.917442 IP 10.0.0.2.25 > 209.85.220.174.48733: tcp 0
22:51:48.917181 IP 209.85.220.174.48733 > 10.0.0.2.25: tcp 0
22:51:50.917183 IP 209.85.220.174.48733 > 10.0.0.2.25: tcp 0
22:51:50.937085 IP 10.0.0.2.25 > 209.85.220.174.48733: tcp 0
22:51:54.917219 IP 209.85.220.174.48733 > 10.0.0.2.25: tcp 0
22:51:56.943003 IP 10.0.0.2.25 > 209.85.220.174.48733: tcp 0
22:52:02.917255 IP 209.85.220.174.48733 > 10.0.0.2.25: tcp 0
22:52:08.939232 IP 10.0.0.2.25 > 209.85.220.174.48733: tcp 0

                209.85.220.174 is a Gmail server IP, and is present in the Google alias.

                rule of : (capture running before turning it back off)

                22:53:43.113162 IP 209.85.220.181.33212 > 10.0.0.2.25: tcp 0
22:53:43.113340 IP 10.0.0.2.25 > 209.85.220.181.33212: tcp 0
22:53:43.230793 IP 209.85.220.181.33212 > 10.0.0.2.25: tcp 0
22:53:43.231483 IP 10.0.0.2.25 > 209.85.220.181.33212: tcp 100
22:53:43.349044 IP 209.85.220.181.33212 > 10.0.0.2.25: tcp 0
22:53:43.349547 IP 209.85.220.181.33212 > 10.0.0.2.25: tcp 31
22:53:43.349829 IP 10.0.0.2.25 > 209.85.220.181.33212: tcp 191
22:53:43.467508 IP 209.85.220.181.33212 > 10.0.0.2.25: tcp 10
22:53:43.467741 IP 10.0.0.2.25 > 209.85.220.181.33212: tcp 29
22:53:43.589822 IP 209.85.220.181.33212 > 10.0.0.2.25: tcp 186
22:53:43.590172 IP 10.0.0.2.25 > 209.85.220.181.33212: tcp 1418
22:53:43.590213 IP 10.0.0.2.25 > 209.85.220.181.33212: tcp 54
22:53:43.710304 IP 209.85.220.181.33212 > 10.0.0.2.25: tcp 0
22:53:43.710853 IP 209.85.220.181.33212 > 10.0.0.2.25: tcp 326
22:53:43.723228 IP 10.0.0.2.25 > 209.85.220.181.33212: tcp 59
22:53:43.840808 IP 209.85.220.181.33212 > 10.0.0.2.25: tcp 69
22:53:43.841143 IP 10.0.0.2.25 > 209.85.220.181.33212: tcp 213
22:53:43.959329 IP 209.85.220.181.33212 > 10.0.0.2.25: tcp 85
22:53:43.959789 IP 10.0.0.2.25 > 209.85.220.181.33212: tcp 53
22:53:44.077556 IP 209.85.220.181.33212 > 10.0.0.2.25: tcp 69
22:53:44.080321 IP 10.0.0.2.25 > 209.85.220.181.33212: tcp 53
22:53:44.199096 IP 209.85.220.181.33212 > 10.0.0.2.25: tcp 1418
22:53:44.199126 IP 209.85.220.181.33212 > 10.0.0.2.25: tcp 11
22:53:44.199158 IP 209.85.220.181.33212 > 10.0.0.2.25: tcp 165
22:53:44.199278 IP 10.0.0.2.25 > 209.85.220.181.33212: tcp 0
22:53:44.632042 IP 10.0.0.2.25 > 209.85.220.181.33212: tcp 149
22:53:44.750021 IP 209.85.220.181.33212 > 10.0.0.2.25: tcp 37
22:53:44.750129 IP 209.85.220.181.33212 > 10.0.0.2.25: tcp 0
22:53:44.750235 IP 10.0.0.2.25 > 209.85.220.181.33212: tcp 0
22:53:44.750300 IP 10.0.0.2.25 > 209.85.220.181.33212: tcp 85
22:53:44.750437 IP 10.0.0.2.25 > 209.85.220.181.33212: tcp 0
22:53:44.867823 IP 209.85.220.181.33212 > 10.0.0.2.25: tcp 0
22:53:44.867919 IP 209.85.220.181.33212 > 10.0.0.2.25: tcp 0

                test mail instant received, previous test mail 5 mins later.
                So yea..

                • its not that it is such a disaster (I can find ways around it tbh). But I cannot stand not knowing why this is happening.

                "edit" - wrong IP in first capture.

                google.txt

                1 Reply Last reply Reply Quote 0
                • ?
                  A Former User
                  last edited by

                  @foetus:

                  list goes one quite a bit ;). Its not a problem its not loading or empty.

                  Yeap, verified a couple of IPs, and they do indeed belong to google. So the alias does not appear to be the problem.
                  @foetus:

                  forwarding to alias (IP : 10.0.0.2 == internal exchange server)
                    The rule is applied on both WAN interfaces. Only MX record active on the VDSL interface in question (failover not yet active).

                  Port forwarding rule verified and is correct.
                  @foetus:

                  Nothing but whitelist rule, rest is blocklist blocking.
                  The 2 blocking rules beneath whitelist are to isolate a seperate physical network to acces the main network. (basically a block all from interface x to y). Then a rule to lock down internet acces during the night for the second network.

                  General list rules look correct. Love the "GTFO during nighttime" rule. Are you sure the pass rule is applied to the correct interfaces? Careful with those rules. Putting yourself in pfsense's place: What does this rule tell me to do? Pass any traffic destined or sourced from Google, without any further processing. See where I'm going with it? Applying it to the wrong interfaces could open up your network to a spoofed (or originating from Google, who knows?) attacker.
                  @foetus:

                  capturing WAN when rule is applied gives me :

                  00:47:40.700800 IP 209.85.220.177.38924 > <wanip>.25: tcp 0
00:47:41.699405 IP 209.85.220.177.38924 > <wanip>.25: tcp 0
00:47:43.699672 IP 209.85.220.177.38924 > <wanip>.25: tcp 0
00:47:47.699690 IP 209.85.220.177.38924 > <wanip>.25: tcp 0</wanip></wanip></wanip></wanip>

                  Only incoming traffic. No return traffic which is interesting.
                  @foetus:

                  disabling floating whitelist Google rule : (recaptured, the previous IP was another sender)

                  00:42:47.405562 IP 209.85.220.181.42122 > <wanip>.25: tcp 0
00:42:47.405847 IP <wanip>.25 > 209.85.220.181.42122: tcp 0
00:42:47.522800 IP 209.85.220.181.42122 > <wanip>.25: tcp 0
00:42:47.523516 IP <wanip>.25 > 209.85.220.181.42122: tcp 100
00:42:47.641067 IP 209.85.220.181.42122 > <wanip>.25: tcp 0
00:42:47.641599 IP 209.85.220.181.42122 > <wanip>.25: tcp 31
00:42:47.641865 IP <wanip>.25 > 209.85.220.181.42122: tcp 191
00:42:47.759789 IP 209.85.220.181.42122 > <wanip>.25: tcp 10
00:42:47.760055 IP <wanip>.25 > 209.85.220.181.42122: tcp 29
00:42:47.878097 IP 209.85.220.181.42122 > <wanip>.25: tcp 186
00:42:47.878731 IP <wanip>.25 > 209.85.220.181.42122: tcp 1418
00:42:47.878768 IP <wanip>.25 > 209.85.220.181.42122: tcp 54
00:42:47.998797 IP 209.85.220.181.42122 > <wanip>.25: tcp 0</wanip></wanip></wanip></wanip></wanip></wanip></wanip></wanip></wanip></wanip></wanip></wanip></wanip>

                  Traffic both ways as expected.
                  @foetus:

                  Internal :
                  rule on :

                  22:51:47.917275 IP 209.85.220.174.48733 > 10.0.0.2.25: tcp 0
22:51:47.917442 IP 10.0.0.2.25 > 209.85.220.174.48733: tcp 0
22:51:48.917181 IP 209.85.220.174.48733 > 10.0.0.2.25: tcp 0
22:51:50.917183 IP 209.85.220.174.48733 > 10.0.0.2.25: tcp 0
22:51:50.937085 IP 10.0.0.2.25 > 209.85.220.174.48733: tcp 0
22:51:54.917219 IP 209.85.220.174.48733 > 10.0.0.2.25: tcp 0
22:51:56.943003 IP 10.0.0.2.25 > 209.85.220.174.48733: tcp 0
22:52:02.917255 IP 209.85.220.174.48733 > 10.0.0.2.25: tcp 0
22:52:08.939232 IP 10.0.0.2.25 > 209.85.220.174.48733: tcp 0

                  Traffic both ways. Replies are leaving the internal server but get choked somewhere on pfsense.
                  @foetus:

                  rule off : (capture running before turning it back off)

                  22:53:43.113162 IP 209.85.220.181.33212 > 10.0.0.2.25: tcp 0
22:53:43.113340 IP 10.0.0.2.25 > 209.85.220.181.33212: tcp 0
22:53:43.230793 IP 209.85.220.181.33212 > 10.0.0.2.25: tcp 0
22:53:43.231483 IP 10.0.0.2.25 > 209.85.220.181.33212: tcp 100
22:53:43.349044 IP 209.85.220.181.33212 > 10.0.0.2.25: tcp 0
22:53:43.349547 IP 209.85.220.181.33212 > 10.0.0.2.25: tcp 31
22:53:43.349829 IP 10.0.0.2.25 > 209.85.220.181.33212: tcp 191
22:53:43.467508 IP 209.85.220.181.33212 > 10.0.0.2.25: tcp 10
22:53:43.467741 IP 10.0.0.2.25 > 209.85.220.181.33212: tcp 29
22:53:43.589822 IP 209.85.220.181.33212 > 10.0.0.2.25: tcp 186
22:53:43.590172 IP 10.0.0.2.25 > 209.85.220.181.33212: tcp 1418
22:53:43.590213 IP 10.0.0.2.25 > 209.85.220.181.33212: tcp 54
22:53:43.710304 IP 209.85.220.181.33212 > 10.0.0.2.25: tcp 0
22:53:43.710853 IP 209.85.220.181.33212 > 10.0.0.2.25: tcp 326
22:53:43.723228 IP 10.0.0.2.25 > 209.85.220.181.33212: tcp 59
22:53:43.840808 IP 209.85.220.181.33212 > 10.0.0.2.25: tcp 69
22:53:43.841143 IP 10.0.0.2.25 > 209.85.220.181.33212: tcp 213
22:53:43.959329 IP 209.85.220.181.33212 > 10.0.0.2.25: tcp 85
22:53:43.959789 IP 10.0.0.2.25 > 209.85.220.181.33212: tcp 53
22:53:44.077556 IP 209.85.220.181.33212 > 10.0.0.2.25: tcp 69
22:53:44.080321 IP 10.0.0.2.25 > 209.85.220.181.33212: tcp 53
22:53:44.199096 IP 209.85.220.181.33212 > 10.0.0.2.25: tcp 1418
22:53:44.199126 IP 209.85.220.181.33212 > 10.0.0.2.25: tcp 11
22:53:44.199158 IP 209.85.220.181.33212 > 10.0.0.2.25: tcp 165
22:53:44.199278 IP 10.0.0.2.25 > 209.85.220.181.33212: tcp 0
22:53:44.632042 IP 10.0.0.2.25 > 209.85.220.181.33212: tcp 149
22:53:44.750021 IP 209.85.220.181.33212 > 10.0.0.2.25: tcp 37
22:53:44.750129 IP 209.85.220.181.33212 > 10.0.0.2.25: tcp 0
22:53:44.750235 IP 10.0.0.2.25 > 209.85.220.181.33212: tcp 0
22:53:44.750300 IP 10.0.0.2.25 > 209.85.220.181.33212: tcp 85
22:53:44.750437 IP 10.0.0.2.25 > 209.85.220.181.33212: tcp 0
22:53:44.867823 IP 209.85.220.181.33212 > 10.0.0.2.25: tcp 0
22:53:44.867919 IP 209.85.220.181.33212 > 10.0.0.2.25: tcp 0

                  Traffic both ways as expected.

                  @foetus:

                  • its not that it is such a disaster (I can find ways around it tbh). But I cannot stand not knowing why this is happening.

                  Dunno why it's not working tbh. Forgive my notes above, they were needed to follow the "flow"  ;D
                  It should work as is, but can you try changing the gateway in the floating rules to the default gateway? (manually select it instead of it being any)
                  Other than that I don't see anything being wrong. It could be that it's too early, but at least I tried  :P

                  1 Reply Last reply Reply Quote 0
                  • ?
                    A Former User
                    last edited by

                    Sidenote: Last night suricata banned an entire /24 with an incoming unwanted SSH connection alert. Yes, 254 alerts. SSH servers show increased pre-auth terminated sessions from all over the world. Either the Chinese are ramping up their script kiddie attacks, or a 0-day SSH exploit (possibly OpenSSH) has been found. Just letting everyone know, lock down your SSH servers.

                    1 Reply Last reply Reply Quote 0
                    • S
                      squatch04
                      last edited by

                      Hey jflsakfja, or anyone else for that matter….

                      First off please forgive my ignorance as i am still very much trying to learn all this.

                      As stated by jflsakfja and on the pfSense Firewall:Rules section, "Everything that isn't explicitly passed is blocked by default. "

                      Well i followed the guidelines for creating rules and added only rules for ports that my home network uses.

                      I intentionally did not create rules for Samba shares and ICMP but i could still access my windows network shares and i could still ping internally (but not externally).
                      I realised that there was a couple of auto created rules in my firewall:NAT:Outbound, most likely created using the pfSense startup wizard and the OpenVPN server wizard.

                      | WAN  10.0.1.0/24 * * 500 WAN address * YES Auto created rule for ISAKMP - LAN to WAN 
                      WAN  10.0.1.0/24 * * * WAN address * NO Auto created rule for LAN to WAN 
                      WAN  127.0.0.0/8 * * * WAN address 1024:65535 NO Auto created rule for localhost to WAN 
                      WAN  10.0.8.0/24 * * * WAN address * NO Auto created rule for OpenVPN server  |

                      What's your advice on these rules? should i disable them? can the rules be fine-tuned to be "less vague"? My assumption is that these rules could circumvent the more fine-tuned floating and interface rules created using this thread guidelines?

                      1 Reply Last reply Reply Quote 0
                      • ?
                        A Former User
                        last edited by

                        NAT rules shouldn't have an impact on the effect of other rules, as long as the NAT rules didn't automatically create other allow rules (the case for port forwarding for example).

                        If you didn't create any rules for samba+ICMP, but you can still use those internally, then a rule exists somewhere that allows it. I've seen a couple of posts lately that pfsense allows things it shouldn't allow. That always comes down to misconfiguration issues.

                        When trying to troubleshoot pfsense, please put yourself into pfsense's place. What would you do with a packet if you followed the rules below:

                        1. floating rules first
                        2. per interface rules next
                        3. NAT rules
                        4. general block everything rule

                        Follow the rules through that order, and I'm sure you can find out what the problem is.

                        1 Reply Last reply Reply Quote 0
                        • S
                          squatch04
                          last edited by

                          @jflsakfja:

                          NAT rules shouldn't have an impact on the effect of other rules, as long as the NAT rules didn't automatically create other allow rules (the case for port forwarding for example).

                          If you didn't create any rules for samba+ICMP, but you can still use those internally, then a rule exists somewhere that allows it. I've seen a couple of posts lately that pfsense allows things it shouldn't allow. That always comes down to misconfiguration issues.

                          When trying to troubleshoot pfsense, please put yourself into pfsense's place. What would you do with a packet if you followed the rules below:

                          1. floating rules first
                          2. per interface rules next
                          3. NAT rules
                          4. general block everything rule

                          Follow the rules through that order, and I'm sure you can find out what the problem is.

                          I will do that, thanks jflsakfja!

                          1 Reply Last reply Reply Quote 0
                          • R
                            raab
                            last edited by

                            So I've setup the pfIPRep rules per Cino's method here https://forum.pfsense.org/index.php?topic=78062.msg427132#msg427132

                            Testing an outbound rule, for example 141.101.116.122 is in IR_SEC1 and I can still ping it even though my LAN and DMZ are selected

                            If I select WAN then it gets dropped accordingly, why is this?

                            Ticking Quick also drops it, do I need to have quick ticked for all the rules?

                            1 Reply Last reply Reply Quote 0
                            • C
                              Cino
                              last edited by

                              Check Quick. I forgot to update the screenshots with that..  Without it check, it will compare the rest of your rules and the last one will win.. Which is probably the default allow all lan rule.  When Quick is checked, and there is a match; it will apply that rule and stop processing the rest for that packet.

                              1 Reply Last reply Reply Quote 0
                              • R
                                raab
                                last edited by

                                @Cino:

                                Check Quick. I forgot to update the screenshots with that..  Without it check, it will compare the rest of your rules and the last one will win.. Which is probably the default allow all lan rule.  When Quick is checked, and there is a match; it will apply that rule and stop processing the rest for that packet.

                                Cool, thanks for that. You're right, I just have the default LAN to ANY rule so that makes sense.

                                Should I have quick checked for inbound rules or just the outgoing ones?

                                1 Reply Last reply Reply Quote 0
                                • C
                                  Cino
                                  last edited by

                                  Quick for all. This way, once there is a match (inbound or outbound) the rule will block/reject the packet right a way.

                                  1 Reply Last reply Reply Quote 0
                                  • R
                                    raab
                                    last edited by

                                    @Cino:

                                    Quick for all. This way, once there is a match (inbound or outbound) the rule will block/reject the packet right a way.

                                    Sweet, that's what I've done, thanks for that.

                                    Now to tackle Suricata.

                                    Just of note, I initially tried this with 2.2-BETA but every time you modify firewall rules or aliases the tables seem to clear. At the time I didn't have quick checked so I'm unsure if it was just a gui problem (as I could still ping that same IP so assumed it was broken) but the only way to get the tables back was to run pfiprep killdb

                                    I also had problems with downloading lists from some https sites with fetch, similar to another user a few pages back yet unsure what a self signed pfsense cert had to do with it. I had ca_root_nss installed and /etc/ssl/certs.pm was symlinked to ca_root_nss.crt from memory

                                    1 Reply Last reply Reply Quote 0
                                    • R
                                      raab
                                      last edited by

                                      Been having fun with Suricata (sarcasm)

                                      Whenever I'm using Astrill VPN to stream Netflix I get these alerts:
                                      SURICATA IPv4 invalid checksum - 09/29/2014-22:44:21
                                      GPL SHELLCODE x86 setuid 0 - 10/02/2014-20:39:23

                                      Ended up adding the VPN IP to a pass list

                                      Trying to download the Windows 10 Tech Preview ISO's from Microsoft today and I got these alerts:
                                      ET INFO EXE - Served Attached HTTP - 10/01/2014-01:10:39
                                      ET POLICY PE EXE or DLL Windows file download HTTP - 10/02/2014-01:10:38
                                      ET POLICY Download Windows Help File CHM 2 - 10/02/2014-11:42:05

                                      They were .iso files downloading via http so I don't understand those alerts

                                      Then once I'd upgraded my Windows 8.1 -> 10 it failed to connect to my microsoft account because of this alert:
                                      ET POLICY Internet Explorer 6 in use - Significant Security Risk

                                      Fun and games, haha.

                                      1 Reply Last reply Reply Quote 0
                                      • ?
                                        A Former User
                                        last edited by

                                        You didn't ask suricata nicely, that's why it's behaving badly. Most of those alerts are known FPs, as per the list linked to in this thread. Never add something that gives up an alert to a passlist. A passlist should only contain systems under your home net and DNS servers. Not a single host more than that. In other words, it should contain the bare minimum of systems that should NOT be banned, under any circumstance. Can you imagine what would happen if suricata decided to ban the DNS servers?

                                        If a rule repeatedly gives a bad alert on known good traffic, suricata isn't the one that must be blamed. It's the rule writer that must be blamed and held accountable. Bug him until he changes the rule. Judging by ET's past record, it's not going to happen any time soon, but one can only hope.

                                        Please remove the host from the passlist and disable the rules following instructions in this thread.

                                        1 Reply Last reply Reply Quote 0
                                        • R
                                          raab
                                          last edited by

                                          Appears I missed one alert that was in your list, however these aren't in your list:

                                          SURICATA IPv4 invalid checksum
                                          GPL SHELLCODE x86 setuid 0
                                          ET POLICY Download Windows Help File CHM 2
                                          ET INFO EXE - Served Attached HTTP
                                          ET POLICY Internet Explorer 6 in use

                                          Also this is another alert I was getting downloading those iso's
                                          ET EXPLOIT Windows Media Player parsing BMP file with 0 size offset to start of image

                                          I'm certainly not blaming suricata, I completely agree with you that some of these rules are absolutely ludicrous..

                                          I've removed the passlist and disabled the rules instead

                                          1 Reply Last reply Reply Quote 0
                                          • ?
                                            A Former User
                                            last edited by

                                            Too long night, too short day  ;D

                                            Those not on my list doesn't necessarily mean they are not false positives. Don't remember if it was in this thread, or the other (snort blueprint) that someone mentioned the ipv4 checksum one.

                                            My list is the starting point, I can't possibly cover all the use cases out there. Adding to the list rules that come from external sources (other than me) means adding yet another layer of management to the list, something I currently do not have time for.  For example I promised a new thread using the new auto management files, and guess what, haven't had time to even begin typing it yet.

                                            This thread described the process of identifying FP rules, and how to deal with them. I'm not attacking you in any way, I'm just saying that a passlist is not the solution for this specific problem. Disabling the rules if you know the alerts are coming from a trusted source, is. If a rule is repeatedly found to be an FP rule, then the rule maintainer has the obligation to correct it, if everyone bugged them about it. He can't correct something that he doesn't even know is wrong. He must correct it though, if others tell him that it's wrong. As was mentioned, don't hold your breath on it when dealing with the ET rules. There are 10 year old rules in there that I have been personally screaming at the writers to remove, for years.

                                            Then there are the "write once, never maintain rules", eg: NT 6.1. As mentioned, directed at ET, "FFS windows 7 IS 6.1, get it into your thick skulls and delete the rule already". Windows 7 was RTM'd on August 6 2009. That's 5 years of a rule FPing, and still counting, since as far as I can tell, they don't plan to correct it. 5 years of people telling you "you are doing it wrong", yet you still don't correct it.  :o

                                            1 Reply Last reply Reply Quote 0
                                            • First post
                                              Last post