Switching

So I've read a number of white papers from Juniper containing some DOS prevention strategies. I'm not looking to prevent any one in particular, but rather just ensure the network is as best protected as possible.

But I'm not inclined to copy+paste configs I've found online without fully knowing the implications.

I've got a EX4200 sat on the internet with a number of public subnets, all in their own VLANs with RVIs each.

This is one example I've found ...

            term tcp-dos-protect-1 {
                from {
                    protocol tcp;
                    tcp-flags "syn&!ack";
                }
                then policer tcp-dos-policer;        
            }
            term tcp-dos-protect-2 {
                from {
                    protocol tcp;
                    tcp-flags "fin|rst";
                }
                then policer tcp-dos-policer;        
            }

...
policer tcp-dos-policer {
        filter-specific;
        if-exceeding {
            bandwidth-limit 500k;
            burst-size-limit 15k;
        }
        then discard;
    }

Now, would this particular rule affect genuine traffic? Under heavy network conditions - would it just start dropping genuine traffic, or does it really only block "bad" traffic ?

This link explains the expressions and more. Hope this helps.

http://www.juniper.net/techpubs/en_US/junos9.6/information-products/topic-collections/config-guide-policy/policy-configuring-match-conditions-in-firewall-filter-terms.html

I'm not looking for guidance on syntax or understanding filters.

I'm asking about best practice with regards to DOS filtering and the implications of the use of this specific filter.

Hi,

I invite you to read this book "Hardening JunOS Device" which details many process to protect routing engine and so more, including DOS (page 38-40 for invalid TCP requests) :

http://www.juniper.net/us/en/community/junos/training-certification/day-one/fundamentals-series/hardening-junos-devices-checklist/

I hope this can help you.

If you find this as a solution you may click "Accept Solution".

Thanks for the link (I've read through a few similar to that) - it covers the best practice bit which is helpful - but has little detail with regards to DOS protection - and doesn't really answer my question.

DoS protection (like your exemple, especially TCP flags) are covered on page 39 and 40 with these options :

set system internet-options tcp-drop-synfin-set (SYN/FIN Flag)

set system internet-options no-tcp-reset drop-all-tcp (FIN/RST, ACK/RST, ...)

Under heavy network conditions - would it just start dropping genuine traffic,- Yes
or does it really only block "bad" traffic ? No.

The reason why we tend to point to the links is they explain what the match conditions mean and allow you make the determination. But I do understand that you simply wanted someone to just answer the question plain and simple.
tcp-initial
First TCP packet of a connection. This is a synonym for "(syn & !ack)". As the explanation says, this is a logical AND
Packet with with the SYNchronize bit set but not the ACKnowledge bit set to show data was recieved, which is indicative of the first packet in the 3-Way handshake. The person may have conducted baseline testing and determined that normal TCP traffic with SYN bit does not use more than 500k for normal usage and 15k for burst. In his/her network environment that is sufficient. In other network environments it may drop legit traffic.
The second term tcp-flags "fin|rst" is a logical OR; looks for either a FINal bit set or reset RST flag set. Excessive traffic with RST or FIN packets could indicate a DoS/DDoS attack, especially if there is no way to determine if this packet is from an already established session. It would exhaust the reoursces of the server responding to a packet for which it has no established session. Say you are at your desk and some says STOP! to you. You stop what you are doing and ask, Stop doing what. But then you don't know who you are responding to. And you can deal with that every hour. But if it starts happening every 5 minutes, you have to respond and will never get to complete your work...watching youtube videos of course and playing angry birds and updating your facebook page.Right? Because you know your ae running all Juniper stable equipment with speeds and performance unmatched! Yes? Again, this is most likely what the Admin determines to be optimal for that environment and any high increases in packets with these bits set may indicate a DOS attack in his environment. Policers simply rate limits traffic based on volume of flow;it does not have the built in intelligence of Screens/AppDoS/IDP/;Syn-proxy, that can determine bad traffic and block those while stil allowing legit traffic. Unless, of course you configure class of service to tell it which traffic you consider top, medium, low priority. If I were doing this, I would use CoS and send the excess traffic to best effort instead of discarding it.
Here is another link for those who follow this thread and wants another take on what the compound combinations mean.

http://www.juniper.net/techpubs/software/junos/junos94/swconfig-policy/specifying-bit-field-filter-match-conditions.html

@lyndidon - thanks for taking the time to respond, that was exactly the answer I was looking for.

My fear was just copy+pasting the configuration without fully understanding the impact it could actually have on real traffic. 

Is there a means on JunOS to measure the current levels of said packet combinations (perhaps a counter?) - so that I can correctly implement a filter that matches my traffic patterns.

In each of the terms, when you configure "then", you say then log syn-no-ack and for the second term, then log fin-or-rst

And in the action that say then discard, aslo say then log discarded-packets

When you run the comman >show firewall, you will see the couters of those packets that are rate limited and accepted, and the ones that are discarded by the names of the counters defined.