Is this doable? Automatically block if outgoing connection not allowed
-
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?
-
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? -
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:
- Block all traffic to the WAN from 192.168.1.15
- 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.
-
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/