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

    Is this doable? Automatically block if outgoing connection not allowed

    Scheduled Pinned Locked Moved Firewalling
    4 Posts 3 Posters 2.6k 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.
    • J
      jasonl99
      last edited by

      I had an idea for security that I'd like to implement, but I don't know if it's possible.

      First, a brief mention of my current setup:  rather than allowing outgoing connections from the LAN to any port, I've changed the action of the Default LAN->Any rule to "block" and created specific rules for ports where connections are allowed (HTTP, HTTPS, IMAP, SMTP/S, POP3/S, DNS etcetera).

      Since no other connections should happen, I am thinking that if a connection is attempted to a port that is not explicitly allowed (say, for example, a machine from within the LAN attempts a connection to 59.100.21.5:8080), it would signal pfsense to automatically block any incoming attempts from 59.100.21.5 as well.  The idea is that if malware does manage to get on a machine, it is highly likely that it will attempt to use a non-standard port to talk to the mother ship.

      I also use snort, and I think this is where it might fit in best:  snort would automatically add 59.100.21.5 to the blacklist ip's for an hour.

      Is this something that's doable currently within pfsense?  Or maybe this is a question to ask in the packages section of the forum?

      1 Reply Last reply Reply Quote 0
      • GruensFroeschliG
        GruensFroeschli
        last edited by

        @jasonl99:

        First, a brief mention of my current setup:  rather than allowing outgoing connections from the LAN to any port, I've changed the action of the Default LAN->Any rule to "block" and created specific rules for ports where connections are allowed (HTTP, HTTPS, IMAP, SMTP/S, POP3/S, DNS etcetera).

        http://forum.pfsense.org/index.php/topic,7001.0.html
        –>

        Rules are processed from top to down.
        If a rule catches the rest of the rules is no longer considered.
        Per default a "block all" rule is always in place (invisible below your own rules).

        Traffic is filtered on the Interface on which traffic comes in.
        So traffic comming in on the LAN-Interface will only be processed from the rules you define on the LAN tab.

        Somehow i think your idea will not work.
        Connections attempts from outside (incomming connections) are always blocked per default if you dont add a rule that allows it in.
        And even then you would need to add a NAT-rule and specify an IP on your LAN to which the connections are forwarded to.
        If you want to deny a connection to this IP you would have to block the destination IP, in your case 59.100.21.5, on the LAN (or OPTx on which your client is).

        Why not just allow outgoing only the ports you thrust?
        ie. 21, 25, 53, 80, 110, 115, 143, 443, 995, 1194, etc.
        or is that what you are doing right now?

        We do what we must, because we can.

        Asking questions the smart way: http://www.catb.org/esr/faqs/smart-questions.html

        1 Reply Last reply Reply Quote 0
        • J
          jasonl99
          last edited by

          Hi GruensFroeschli, thanks for your answer.

          I don't know what I was thinking when I said "it would signal pfsense to automatically block any incoming attempts" - I meant to say all traffic.

          The idea is this:  if an piece of malware running within the LAN is trying to communicate to the outside on a non-standard port, we want to block it from communicating on any port.  This would protect the machine with the malware as well as other machines that may or may not be infected yet.

          It's the same concept as snort itself:  if snort detects a particular alert, it blocks all traffic (in or out) for that IP, only in reverse.  In fact, in thinking it over, it should do two things:  block all outbound traffic from the source, block all traffic to and from the destination.

          Let me illustrate with a more concrete example.

          My pc, which has an ip of 192.168.1.15 has a piece of malware that attempts to connect to 59.59.1.1 on port 8080.

          Port 8080 is blocked by the default deny rule, so the following happens:

          1. Block all traffic to the WAN from 192.168.1.15
          2. Block all traffic to 59.59.1.1 (even otherwise-allowed ports) from any host on the LAN

          I don't know, maybe I'm being to overly cautious, but I just think it would be an interesting idea to really lock things down.

          1 Reply Last reply Reply Quote 0
          • jahonixJ
            jahonix
            last edited by

            Nice idea.

            Since modern malware does way more than just connect to a single server by its IP it is kind of useless.
            There are server farms out there (bot nets) that get addressed by round robin methods from DNS. They just don't care if you block an IP, they are pretty failsafe. Unfortunately!

            Include this in your reading about bot nets: http://www.heise-security.co.uk/

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