Taming the beasts… aka suricata blueprint



  • @n3by:

    Be careful with chosen ports, not to be used by normal applications because you will cut access to this ports.

    You will put restriction rule from LAN only if you want to have specifics designated computers that can access the admin ports.

    Attached floating rule for WAN and rule for LAN.

    p.s.
    you can use as destination: "This firewall (self)" instead of any

    Appreciate it! Thanks a lot. Kudos.



  • So long and thanks for all the fish.



  • @jflsakfja:

    So long and thanks for all the fish.

    Oh, NO.  r you leaving us? whats happening?



  • @jflsakfja:

    So long and thanks for all the fish.

    Farewell. Thank you for everything.
    Hoping you will return.



  • Hi I am trying to create the golden custom rules and need help…

    alert tcp $EXTERNAL_NET any -> $HOME_NET ![ports,open,on:firewall] (msg:"Blocked close TCP"; classtype:attempted-recon; sid:9900000; rev:1;)
    alert udp $EXTERNAL_NET any -> $HOME_NET ![ports,open,on:firewall] (msg:"Blocked close UDP"; classtype:attempted-recon; sid:9900000; rev:1;)
    alert tcp $EXTERNAL_NET [0:1023] -> any [0:1023](msg:"Blocked close TCP"; classtype:attempted-recon; sid:9900000; rev:1;)
    alert udp $EXTERNAL_NET [0:1023] -> any [0:1023] (msg:"Blocked close UDP"; classtype:attempted-recon; sid:9900000; rev:1;)

    the first two are to block incoming to closed ports.
    the last two to block incoming from low ports to low ports.

    How should i adjust them in the msg bit or any other comments on them.

    Thanks.



  • Hi everyone. I'm thinking of following the guide here but jumping to the last page I noticed that jflsakfja indicated that he will no longer be on this forum.  Is it worth reading 30 pages to get this setup?  Is the snort page any better?

    LoboTiger



  • My advice is to install Suricata if possible.
    Yesterday I just had to uninstall Snort and installed Suricata from one remote site after I seen high CPU load and high CPU temp without traffic. Reason Snort >10-15% CPU - in the same conditions, now it is ok Suricata 1-2% CPU.
    The other site had Suricata installed and no problems; both sites are running pfSense 2.2.5 & vpn site to site.



  • @lobotiger:

    Hi everyone. I'm thinking of following the guide here but jumping to the last page I noticed that jflsakfja indicated that he will no longer be on this forum.  Is it worth reading 30 pages to get this setup?  Is the snort page any better?

    LoboTiger

    I am a absolute beginner and i found this thread very interesting to get some understanding of the principles of good security.
    So i wil re-read it and start to implement it.



  • @lobotiger:

    Hi everyone. I'm thinking of following the guide here but jumping to the last page I noticed that jflsakfja indicated that he will no longer be on this forum.  Is it worth reading 30 pages to get this setup?  Is the snort page any better?

    LoboTiger

    It's probably the best read you'll find on the net about IDS/IPS security. Most of what you need to know is in the first few pages anyway….



  • SO… all quiet on the western front?

    Did I miss a memo somewhere about what happened to this project, or the guide v2?


  • Banned

    Not an expert, but I guess… yes

    https://forum.pfsense.org/index.php?topic=88244.0



  • Thats not it….They eventually gave him permission to use a disclaimer and from that point on, the project was under way. But then  jflsakfja got into a serious car accident and he's just had to put all of this on pause til he gets better.



  • If that is indeed that case then he has my deepest and genuine sympathies and I wish him a hearty, fast and total recovery.


  • Banned

    First off, great topic! I am completely new to all of this and I've spent hours reading through this topic and looking out over the internet to try to understand it.

    The reason I made an account and posted is because I attempted to type up a How-To for the super-layman.
    I attached it here and would love to get your feedback on it. There are certainly fundamental errors in it simply because I do not understand this stuff and my interpretations of what's going on are bound to be incorrect (hopefully not all the time).
    If those of you who know what's going on would be so kind as to give me feedback and correct me, I'll revise and re-post the corrected copy. The intent is to have a document that I or someone like myself could pick up and use to setup pfSense in a secure way without any prior knowledge.

    So I got on eBay and for $130 purchased a SFF HP with an i5-2400, 8GB RAM and 640GB HDD and an Intel PRO/1000 PT dual NIC. I know it's overkill, but it was cheap.
    Going through MANY hours of youtube tutorials on pfSense and networking in general I learned that most of what I want to do on pfSense can be achieved by simply following instructions without very much understanding. However, it seemed to me that Firewall rules (what pfSense was actually made for) actually needed to be understood at least on a basic level since it is so specific to what you're using it for. Then I found this thread, I read through it, and didn't understand much. So I read through more, researched things online and started typing up a step-by-step document that I could use to accomplish each task and have some understanding of what I was doing. I didn't accomplish that completely, there are things that I know I don't fully understand, and I'm sure other things that I misunderstand.
    It's worth noting that I haven't actually been able to attempt any of this on pfSense yet.

    Anyways, thank you for what you've done and I'd appreciate any of your expertise and guidance!

    @jflsakfja:

    Here we go!

    Firewalling
    Always whitelist, NEVER blacklist…

    <<<<<everything i="" tried="" to="" understand="" and="" included="" in="" my="" writeup="" thus="" far="" is="" contained="" between="" these="" two="" quotes="" from="" the="" op.="">>>>>> </everything>

    …Back to where we left. Nobody likes his internet being down (I grew tired of having to explain that the Internet was designed to survive a nuclear holocaust without it being down, if you can't beat them, join them). So hurry up with the other interfaces as well.


  • Banned

    I reformatted the tables in the word document so that I could publish what I'm trying to do directly here and no one has to download the word document. There are a lot of hyperlinks that are included on the word doc but not on this post, so if you see something that looks like it should be hyperlinked, it is on the .doc.

    ANY help you guys can give me would be greatly appreciated!

    I'm reading through tons of BBCan117's posts on pfBlockerNG trying to learn how to use it to accomplish this setup. I'll post that as soon as I'm done, but remember my done does not equal a finished product. I'll need correction from you guys to get this right.

    –---------------------------------------

    EDIT: Removed due to potentially misleading info.


  • Moderator

    @pfBasic:

    I'm reading through tons of BBCan117's posts on pfBlockerNG trying to learn how to use it to accomplish this setup. I'll post that as soon as I'm done, but remember my done does not equal a finished product. I'll need correction from you guys to get this right.

    Thanks for all your efforts.. :)

    Just to note, that my posts in relation to the script should be ignored, as its now superceded by the package pfBlockerNG…

    https://forum.pfsense.org/index.php?topic=102470.0
    https://forum.pfsense.org/index.php?topic=86212.0


  • Banned

    @BBcan177:

    @pfBasic:

    I'm reading through tons of BBCan117's posts on pfBlockerNG trying to learn how to use it to accomplish this setup. I'll post that as soon as I'm done, but remember my done does not equal a finished product. I'll need correction from you guys to get this right.

    Thanks for all your efforts.. :)

    Just to note, that my posts in relation to the script should be ignored, as its now superceded by the package pfBlockerNG…

    https://forum.pfsense.org/index.php?topic=102470.0
    https://forum.pfsense.org/index.php?topic=86212.0

    Yes sir, I am reading through your threads on pfBNG and trying to figure out how to use that to accomplish this threads intent without messing it up!



  • pfBasic, did you just edit/reformat the content in the original post by “jflsakfja”?

    Or, did you adapt the content in the original post to a later version of pfSense? If so, which version did you use for your document?

    Thanks.



  • PFBasic, the word doc looks nice.  I've come back to this after a long time working on other stuff, so thanks for condensing this very long thread.  I look forward to implementing Suricata soon  (getting ready to set aside some time to get into it without interruption).

    I hope it's OP is well and doing great things (I'm sure that's a given).


  • Banned

    I'm glad the documents are helping out. I've finally started implementing all of this stuff on my own and there's a lot in the document that I need to change/add/update. So don't just use that document to set your system up, you'll have to do some of your own reading as well.

    I simply copy/pasted and added explanations as best I could and tried to update some stuff based on new releases.

    I too am nearing the point where I want to implement suricata as described here. Unfortunately I have absolutely NO idea what the "Golden Rules" are or how to add them to pfSense.

    If anyone can help me out with the "Golden Rules" that please PM me, I'm lost.

    EDIT: for anyone stumbling across this thread again, see quoted post, these are the "golden rules" as I understand them.
    @pfBasic:

    drop tcp !$MY_NET any -> any !$MY_PORT (msg:"The Golden Rule, TCP"; classtype:network-scan; sid:9000; rev:1;)
    drop udp !$MY_NET any -> any !$MY_PORT (msg:"The Golden Rule, UDP"; classtype:network-scan; sid:9001; rev:1;)
    

    $MY_NET and $MY_PORT are variables you'll need to specify as necessary for your own network in /usr/local/pkg/suricata/suricata_yaml_template.inc under the "vars:" section. The "!" in front of the variables means "not", so it would read:
    drop tcp/udp traffic from "anywhere not on my network" on any port going to anywhere on "any port not specifically allowed on my network"



  • PFFEEEEEEEEWWWW, made it!!!

    Let me start of by saying thank you jflsakfja, you're a real Frood & will be missed.
    To BBcan177, Cino, bmeeks/Bill, and yes, The Eternal Noob Mr. Jingles/Hollander thank you too. This thread would not be what it is without your contributions.
    PM me a way to send you $7 and you can have a "serious beer" ;) on me. (Provided I don't have to sign up for some overly shady or new startup run by 3 ppl…)

    I've copy/pasted "all" instructional posts from this topic into a text document. I've included some troubleshooting posts as well. Excluding the first entry of BBcan117 informing everyone to use pfBlockerNG instead of his script, all posts are in chronological order; all posts include attribution & a direct link to the original post. I thought I'd make it available to others: https://bpaste.net/raw/0352fd6f5706 as it saves a lot of reading. But let me be clear: this document is intended to serve as my own starting point for understanding this setup before attempting to implement it. It's not some well formatted nor updated guide. Same data, with non-critical discussion posts removed.

    @pfBasic: RE: Golden Rules
    See:
    @jflsakfja:

    …QUIZ: Who remembers why low (privileged ports) are useful?

    Using the low ports we can detect port scans looking like legitimate traffic reaching "official" server ports.
    ...
    In other words, packets from a source NOT our home network (or belonging to an external network) and a source port of any, reaching a port NOT in use on our home network, will alert us.
    Congratulations young grasshopper, you have just created the world's top snort/suricata rule. It is internally referred to in The Company as "The Golden Standard for writing IDS/IPS rules" or, depending on the day "The two rules to rule them all". Why is it the golden standard? Those of you that failed to see that it is impossible to cause a false positive by this rule so far are dangerously close to failing the class. Unless you ignored a port in use (which shouldn't happen all that often) a packet that triggers this rule is a packet that will not route across pfsense. Simply put: a legitimate alert.
    Be extremely careful with the knowledge. It can be used for good, or it can cause great harm. These two (a TCP and a UDP), the "The two rules to rule them all", rules accounts for 10K monthly banned hosts (hosts set up to be unbanned after 28 days, but trigger the rule before that).
    ...

    (I'm going to try and rephrase this such than "anyone" can understand it, because this is visible to the world, not because I have an opinion on your mental capabilities pfBasic;)
    IOW: The Golden Rules appear to be two custom Suricata rules you create that are tailored your your network. Tailored to look for traffic coming in from outside your network destined for unused privileged ports. Privileged ports are ports 1 though port 1024, they are ports reserved for services like http(s), ssh, ftp, etc. If there's something that should be reachable from outside your network on these ports it's because "you" are intentionally running a "server". So you know to expect traffic destined to a few specific ports in this range, right? Therefore traffic destined for those ports is expected and you exclude from these rules; because drum roll all unexpected traffic destined for privileged ports is basically guaranteed to be some form of malicious activity (probably a port scan). These rules allow you to detect that undesired traffic & begin dropping traffic to/from the offending source IPs. Dropping all further traffic to/from these IPs stops those IPs from being able to continue to attack your network.

    To put it (my understanding) more generically, intelligently, and far more succinctly: the Golden Rules detect traffic to ports explicitly blocked by the firewall. Detecting traffic to explicitly blocked ports provides a high quality method of identifying bad actors so that you can drop all further traffic to/from that IP. Typically you don't explicitly block ports higher than 1024 as they can (and are) used for legitimate traffic without you taking any special action (like installing a web server daemon). (Though 8080 might be a good exception to that rule.)

    Hope this all helps! :)



  • @perth:

    PFFEEEEEEEEWWWW, made it!!!

    -snip-

    I just hit the thank you button since your post is very friendly and informative, but I'm told I already thanked somebody in this thread in july 2014, and more thanks are forbidden, this appears the current state of things in the year of our evolution 2016 ( ;D ;D ;D ).

    So I'll simply say it here: thank you for your post  ;D

    I especially like it that you like to offer the package devs a beer, which is how I thank people too. Since I'm only the eternal noob, that offer can never be for me, but you indeed mentioned JFL, BB, Bill, Cino; great people on this board, true Open Source people.



  • ACTION: BLOCK
    DISABLED: DO NOT ✓
    QUICK: ✓
    INTERFACE: Gnet24 (CTRL+Click all interfaces that you don’t want to access LAN)
    DIRECTION: ANY
    TCP/IP VERSION: IPv4 & IPv6 (I will use only IPv4)
    PROTOCOL: TCP
    SOURCE: ANY
    DESTINATION: ANY
    DESTINATION PORT RANGE: OUTGOING_PORTS

    Hi,

    I am confused on the last bit of rules here by pfBasic (pasted above). Doesnt this rule means to stop all the traffic on the other interfaces (Gnet24) on outgoing_ports. Shouldnt the destination be the LAN here or am i missing something,
    thanks for your great tutorial in word. It helped me a lot,
    molykule


  • Banned

    Resurrecting this beast once again.

    This topic is certainly outdated with a lot of information spread throughout but it was probably the thread that ultimately got me to start using pfSense.

    I read through this thread before ever having installed pfSense and responded to it with attachments of my summaries and interpretations before I had ever even seen an actual pfSense GUI (because I was in a situation where I couldn't currently use pfSense, but was very interested). I've removed my attachments of summaries and interpretations because while some of the summaries may have been useful, I think they were ultimately misleading and counter productive and for that I apologize.

    Having actually used pfSense for awhile now, I think I might have a better grasp on this (but still don't take me for my word, I'm in no way an IT pro; if you follow me blindly it's the blind leading the blind). So all I'd like to do here is summarize what I interpret the three basics steps of this guide to be in 2017's terms and hopefully get some responses as to whether or not I'm correct, and if not then set me straight.
    My hope is that this huge and extremely informative but fragmented and dated thread might guide a few forum lurkers and google searchers towards pfSense or the better utilization of it.

    –-----------------------------------------------------------------------

    1.) Do not use "allow any any any" rules unless you know what you're doing and have a reason. Understand that pfSense by default blocks everything you do not explicitly allow and use that to your advantage, i.e. whitelist, don't blacklist. I personally don't use all of the originally stated firewall rules anymore but I did for a while and I still use and write firewall rules and aliases based on what I learned in this thread.
    If you are new to firewalling in general, simply following page 1 of this thread for your firewall rules will serve you well, you'll learn a lot and be starting from a great place.

    2.) Use pfBlockerNG. I'm pretty sure this thread started before pfBlocker existed (but maybe not?) But now everything in step 2 can be done better and easier using the package pfBlockerNG. pfBNG is a whole subject on its own, and has its own section on this forum with a wealth of info. Additionally its creator is extremely active and probably the most helpful and informative member I've encountered on this or any other forum, seriously. This forum holds everything you need to get pfBNG up and running with a great set of lists. With pfBNG and DNSBL (a feature of pfBNG) you can do a LOT more than what is described in step 2 of this thread, you can even implement auto updated shallalist into it with minimal effort. Take the time to learn this.

    3.) Suricata is by far the single most complex aspect of this guide. I tried it shortly after starting to use pfSense and quickly realized I wasn't yet capable of even attempting it. I recommend you stick with steps 1 & 2 until you are reasonably comfortable with pfsense in general. Once that happens though, definitely check suricata out. I'm just now coming back to try to learn suricata. From everything I've read, suricata is not a package you just install, configure and forget. How difficult it is to effectively implement is really dependent on the complexity of your use case and your competence (mine is low in this subject area).  When you are knowledgeable enough to check it out, try using it WITHOUT blocking (IDS), use it this way for a while (days, weeks, months, depends on you) until you figure out which rules are giving you false positives and disable them. Once you turn suricata on to block (IPS), if it isn't configured & tuned properly, it will probably just unnecessarily break a bunch of useful things because it isn't tailored to your network. This really is a drawn out process that involves a LOT of googling and reading if you are new like me.

    All that having been said, do circle back around to suricata. The Golden Rule(s) is what is highly emphasized in step 3 of this thread. In my mind at least, perth did an excellent job of breaking this rule down for total beginners like myself.
    @perth:

    To put it (my understanding) more generically, intelligently, and far more succinctly: the Golden Rules detect traffic to ports explicitly blocked (EDIT: not explicitly passed) by the firewall. Detecting traffic to explicitly blocked (not explicitly passed) ports provides a high quality method of identifying bad actors so that you can drop all further traffic to/from that IP. Typically you don't explicitly block ports higher than 1024 as they can (and are) used for legitimate traffic without you taking any special action (like installing a web server daemon). (Though 8080 might be a good exception to that rule.)
    Hope this all helps! :)

    That interpreted to the proper syntax to create a suricata rule(as I understand it at least) translates to these two rules:

    drop tcp !$MY_NET any -> any !$MY_PORT (msg:"The Golden Rule, TCP"; classtype:network-scan; sid:9000; rev:1;)
    drop udp !$MY_NET any -> any !$MY_PORT (msg:"The Golden Rule, UDP"; classtype:network-scan; sid:9001; rev:1;)
    

    $MY_NET and $MY_PORT are variables you'll need to specify as necessary for your own network in /usr/local/pkg/suricata/suricata_yaml_template.inc under the "vars:" section. The "!" in front of the variables means "not", so it would read:
    drop tcp/udp traffic from "anywhere not on my network" on any port going to anywhere on "any port not specifically allowed on my network"

    Those two custom rules alone without any other rules at all will provide what perth is summarizing and the OP intended, if my understanding is correct.

    Obviously those two rules alone are not even close to harnessing the full power of suricata but it should be an excellent starting point because as jflsakfja pointed out, there will be no false positives with these rules. Additionally if suricata's basic configuration is not correct then these won't do you any good. So basically my suggestion remains that if you are completely new to this as I was, circle back to suricata once you have a basic understanding of what's going on.

    Now hopefully someone smart doesn't come along only to tell me that I've still got it all wrong. At least if they do, I'll learn something!



  • @pfBasic:

    That interpreted to the proper syntax to create a suricata rule(as I understand it at least) translates to these two rules:

    drop tcp !$MY_NET any -> any !$MY_PORT (msg:"The Golden Rule, TCP"; classtype:network-scan; sid:9000; rev:1;)
    drop udp !$MY_NET any -> any !$MY_PORT (msg:"The Golden Rule, UDP"; classtype:network-scan; sid:9001; rev:1;)
    

    $MY_NET and $MY_PORT are variables you'll need to specify as necessary for your own network in /usr/local/pkg/suricata/suricata_yaml_template.inc under the "vars:" section. The "!" in front of the variables means "not", so it would read:
    drop tcp/udp traffic from "anywhere not on my network" on any port going to anywhere on "any port not specifically allowed on my network"

    I'm not sure these are right.  Looks as if they would not take into account established outbound connections and block incoming traffic regardless if its related to an established outbound connection.

    I am not sure exactly what the base set of "golden rules" should actually look like but I don't think these are quite right.


  • Banned

    I'm certainly no guru and they could be wrong.

    Whether the connection is already established or not won't matter (as I understand it). In fact, in Legacy mode (which almost everyone uses) some packets will make it through inspection even if they should be dropped because the filter is not inline. When the traffic matched, remaining packets are dropped and the state is closed. The same would apply to these rules.

    All they say is:

    drop: TCP/UDP traffic with an address not on my network on any port that is going to any address on any port that I don't use.



  • Me I suggest this approach that will save you to edit in Suricata variables:

    • first 2 lines will drop traffic that come to your external IP from/on low ports:
    • next line will drop all UDP traffic that come to your external IP on low ports ( use it if you don't have a server listening for that traffic )
    • next lines will drop all TCP traffic that come to your external IP on low ports except ports: 25, 443, 465, 993 ( adjust it as you need )
    drop tcp $EXTERNAL_NET [0:1023] -> $HOME_NET [0:1023](msg:"Golden Rule BAD TCP"; classtype:attempted-recon; sid:9900001; rev:1;)
    drop udp $EXTERNAL_NET [0:1023] -> $HOME_NET [0:1023] (msg:"Golden Rule BAD UDP"; classtype:attempted-recon; sid:9900002; rev:1;)
    drop udp $EXTERNAL_NET any -> $HOME_NET [0:1023] (msg:"Golden Rule NO SERVER UDP"; classtype:network-scan; sid:9900003; rev:1;)
    drop tcp $EXTERNAL_NET any -> $HOME_NET [0:1023,![25,443,465,993]] (msg:"Golden Rule NO SERVER TCP"; classtype:network-scan; sid:9900004; rev:2;)
    

    edit
    in case the last line rev:2 is not working for you replace with this:

    drop tcp $EXTERNAL_NET any -> $HOME_NET [0:24] (msg:"Golden Rule NO SERVER TCP"; classtype:network-scan; sid:9900004; rev:1;)
    drop tcp $EXTERNAL_NET any -> $HOME_NET [26:442] (msg:"Golden Rule NO SERVER TCP"; classtype:network-scan; sid:9900005; rev:1;)
    drop tcp $EXTERNAL_NET any -> $HOME_NET [444:464] (msg:"Golden Rule NO SERVER TCP"; classtype:network-scan; sid:9900006; rev:1;)
    drop tcp $EXTERNAL_NET any -> $HOME_NET [466:992] (msg:"Golden Rule NO SERVER TCP"; classtype:network-scan; sid:9900007; rev:1;)
    drop tcp $EXTERNAL_NET any -> $HOME_NET [994:1023] (msg:"Golden Rule NO SERVER TCP"; classtype:network-scan; sid:9900008; rev:1;)
    


  • I've been thru this thread in detail and I'm not sure I understand the purpose of these "golden rules". The default block rule on the WAN interface will catch them anyway. What am I not seeing?


  • Banned

    the point is to add potential attackers to the snort2c list so that they are blocked even if they do make a legitimate connection attempt.

    firewall rules alone won't stop that.

    It's interesting in theory, I'm not sure that it's actually very useful in practice.



  • Added that Golden rules on two hosts located in different country, and here are some numbers in ~12h, IPs that try to access inexistent servers on low ports :

    • first host blocked > 200 IPs
    • second host blocked >500 IPs

    When they try to access servers available on this hosts they are already blocked.

    If you think this rules are not required for you then it is best not to install Suricata/Snort, it will do almost nothing good to your network, will just overload the CPU and cause trouble when blocked legitimate hosts.

    ![2017-04-24 09.54.06.jpg](/public/imported_attachments/1/2017-04-24 09.54.06.jpg)
    ![2017-04-24 09.54.06.jpg_thumb](/public/imported_attachments/1/2017-04-24 09.54.06.jpg_thumb)


  • Banned

    These rules are by no stretch of the imagination the best rules for snort suricata. The proper implementation of the free snort and ET rules is easy more valuable.



  • the point is to add potential attackers to the snort2c list so that they are blocked even if they do make a legitimate connection attempt.

    That makes sense now. If you get port scans on non-used ports, say 23, then, when the same ip scans port 80, it will be auto blocked even if that port is forwarded to an internal server. I guess that assumes the auto generated block rules are placed after the web servers allow rule. I'm not sure how the auto-blocking works though.



  • In ~48h using rules to block non existent services on first 1000 ports (and few others) each Suricata from my 2 servers blocked ~1000 IPs without any false positive.

    I can say this is a good start for anybody.

    drop tcp $EXTERNAL_NET [1024:65535] -> $HOME_NET [3389] (msg:"Admin Rule NO SERVER RDP TCP"; classtype:network-scan; sid:990050; rev:1;)
    drop tcp $EXTERNAL_NET [1024:65535] -> $HOME_NET [5500] (msg:"Admin Rule NO SERVER VNC TCP"; classtype:network-scan; sid:990052; rev:1;)
    drop tcp $EXTERNAL_NET [1024:65535] -> $HOME_NET [5800] (msg:"Admin Rule NO SERVER VNC TCP"; classtype:network-scan; sid:990053; rev:1;)
    drop tcp $EXTERNAL_NET [1024:65535] -> $HOME_NET [5900] (msg:"Admin Rule NO SERVER VNC TCP"; classtype:network-scan; sid:990054; rev:1;)
    drop tcp $EXTERNAL_NET [1024:65535] -> $HOME_NET [4899] (msg:"Admin Rule NO SERVER RADMIN TCP"; classtype:network-scan; sid:990055; rev:1;)
    drop tcp $EXTERNAL_NET [1024:65535] -> $HOME_NET [1433] (msg:"Admin Rule NO SERVER MSSQL TCP"; classtype:network-scan; sid:990057; rev:1;)
    drop tcp $EXTERNAL_NET [1024:65535] -> $HOME_NET [5060] (msg:"Admin Rule NO SERVER SIP TCP"; classtype:network-scan; sid:990059; rev:1;)
    drop udp $EXTERNAL_NET [1024:65535] -> $HOME_NET [5060] (msg:"Admin Rule NO SERVER SIP UDP"; classtype:attempted-recon; sid:9900060; rev:1;)
    drop tcp $EXTERNAL_NET [1024:65535] -> $HOME_NET [8172] (msg:"Admin Rule NO SERVER IIS TCP"; classtype:network-scan; sid:990061; rev:1;)
    drop tcp $EXTERNAL_NET [1024:65535] -> $HOME_NET [31337] (msg:"Admin Rule NO SERVER Back Orifice TCP"; classtype:network-scan; sid:990063; rev:1;)
    drop tcp $EXTERNAL_NET [1024:65535] -> $HOME_NET [47001] (msg:"Admin Rule NO SERVER WinRM TCP"; classtype:network-scan; sid:990064; rev:1;)
    

  • Banned

    Those two rules keep ~20k+ IPs on my 28 day snort2c table.



  • I was running in-line which is why those rules seemed to have little purpose. Switched to legacy - I get it now.



  • Doublepulsar detection Snort/Suricata rules

    https://github.com/countercept/doublepulsar-detection-script/blob/master/doublepulsar_snort_rules.rules

    # Authors: Jayden Zheng (@fuseyjz) and Wei-Chea Ang (@77_6A)
    # Company: Countercept
    # Website: https://countercept.com
    # Twitter: @countercept
    
    alert tcp any any -> $HOME_NET 445 (msg:"DOUBLEPULSAR SMB implant - Unimplemented Trans2 Session Setup Subcommand Request"; flow:to_server, established; content:"|FF|SMB|32|"; depth:5; offset:4; content:"|0E 00|"; distance:56; within:2; reference:url,https://twitter.com/countercept/status/853282053323935749; sid:1618009; classtype:attempted-user; rev:1;)
    
    alert tcp $HOME_NET 445 -> any any (msg:"DOUBLEPULSAR SMB implant - Unimplemented Trans2 Session Setup Subcommand - 81 Response"; flow:to_client, established; content:"|FF|SMB|32|"; depth:5; offset:4; content:"|51 00|"; distance:25; within:2; reference:url,https://twitter.com/countercept/status/853282053323935749; sid:1618008; classtype:attempted-user; rev:1;)
    
    alert tcp $HOME_NET 445 -> any any (msg:"DOUBLEPULSAR SMB implant - Unimplemented Trans2 Session Setup Subcommand - 82 Response"; flow:to_client, established; content:"|FF|SMB|32|"; depth:5; offset:4; content:"|52 00|"; distance:25; within:2; reference:url,https://twitter.com/countercept/status/853282053323935749; sid:1618010; classtype:attempted-user; rev:1;)
    


  • @ecfx:

    Be careful with chosen ports, not to be used by normal applications because you will cut access to this ports.

    You will put restriction rule from LAN only if you want to have specifics designated computers that can access the admin ports.

    Attached floating rule for WAN and rule for LAN.

    p.s.
    you can use as destination: "This firewall (self)" instead of any

    Another newbie trying to get this sorted on a home net.  I followed the initial post and blocked all traffic.

    When I enabled the wan floating rule and lan rule I get locked out of the gui and have to revert to a previous config and reboot to get access to the box again.



  • Hi All,
    Very new to Pfsense, just started to research snort and suricata. Came to this post  and have read through it but still stuck. I am using Pfsense 2.3.4 and open VPN client with PIA, I have NAT setup to direct lan / wan to the PIA interface. I have a firewall rule for lan on LANnet to use the PIA DHCP gateway.

    As soon as I apply the below instructions, my internet access shuts down. Note only interfaces I have are LAN, WAN, PIA, OpenVPN (not used and does not exist, not sure why its on the list)

    "Next up Floating tab:
    Set up a rule but make these changes:
    Action Block
    Quick TICKED!!!
    Interface Hold CTRL and click on all interfaces EXCEPT LAN(admin) and SYNC
    Direction any
    Source any
    Destination any"

    I think I am misunderstanding this portion

    "Head over to an interface's tab and set up a an allow rule. Source should be the interface's subnet. The destination should be any, and for the ports use the outgoing_ports alias created above. Destination should be any. Otherwise identical to the webgui rule. Warning! This allows any host to access any other host on other interfaces using those ports. If this is not needed (and generally it shouldn't), finish the rule, and head over to the floating rules tab."

    What am I supposed to do here? The floating rule takes precedent over all other rules 1st, any rule after this would still be blocked no? I added another LAN firewall rule and set source to LANNet and destination ports to the outbound port alias and no luck.

    Any tips?
    Thanks!



  • Hello all,

    I signed up for this forum specifically to ask this question of this community / thread. Thanks in advance.

    I'm greatly interested in setting up a pfsense firewall in the manner described under this thread but I have basically one reservation about doing so and therefore I'd like an honest assessment from those that have gone before me.  I am NOT an IT professional but I am a reasonably intelligent and computer savvy novice with above average understanding of routed networks.  I don't mind doing my own research / problem solving and while I'm relatively new to Unix / Linux I'm a fairly quick learner.  I've read the entire thread, multiple times.

    Given those facts, if I correctly set up pfSense according to this guide, realistically what on-going time commitment am I making with respect to updating the rules, known threat list, etc.  Once I get the firewall up and running according to this guide, will it run without much tinkering, problem solving, and updating or will it turn into a time sucking black hole that takes away from my regular job, wife, children, and hobbies that I prefer to network administration?

    I have a simple home network with limited services and requirements.  I currently run dd-wrt using multiple lans / vlans for the various network segments that I have in house but am interested in upgrading my perimeter security as long as it can be done without becoming a full time network admin job on top of my other commitments.

    Thoughts and comments are appreciated.


  • Banned

    I started on pfSense in the same boat less the understanding of routed networks.

    I've spent a lot of time messing around on pfSense but 95% of that time he been out of curiosity, not to make it work.

    I wouldn't recommend following this guide exactly, it's old and there are better ways to do much of this.

    Suricata can be a time sucker. You probably don't need it on a home network. Even if you only use the "Golden Rules" on WAN it can cause some issues with certain types of setups.

    You can get a stable filtered and secure home network up and running pretty quickly with just firewall rules, pfBlockerNG and DNSBL.

    Later on if you want to play around with it and have some time to deal with false positives check out suricata.

    Id recommend avoiding squid and it's related packages entirely on a home network. It sounds cool in theory but in practice is more of a pain than a help on small home networks.


Log in to reply