IDP TROUBLESHOOTING QA290 How to debug IDP process

Juniper Networks Intrusion Detection & Prevention © 2019 Juniper Networks Juniper Business Use Only

Verifying and Troubleshooting Steps for IPS © 2019 Juniper Networks Juniper Business Use Only

IDP Policy © 2019 Juniper Networks Juniper Business Use Only

IDP Policy Overview • Configured under “security idp” stanza • Configured via the CLI or JWeb • Policy is comprised of match criteria, attacks and actions for both ips and exempt rulebases • Configure an IDP policy or select a policy template • After policy is configured and activated, the policy is pushed to the data plane (PFE) © 2019 Juniper Networks Juniper Business Use Only

Building an IDP Policy – IPS Rulebase Match • First download and install security database and policy templates • Consists of at least one IPS rule with and optional exempt rules • Select more or less match criteria to open or filter inspected traffic [edit security idp policy HTTP Audit] root# show rulebase ips { Selecting IDP rulebase (not rule 1 { exempt) match { Selecting match criteria from zone any; source address any; to zone any; destination address any; application default; Select individual attack or attack attacks { predefined attacks HTTP: AUDIT: URL; groups } © 2019 Juniper Networks Juniper Business Use Only

Building an IDP Policy – IPS Rulebase Actions • Minimum “then” statement is for an action • Log attacks notification writes attack to logs • Packet logging available, use with caution due to resource consumption • Unlogged attacks still show in the attack table then { action { no action; } notification { log attacks; } } } © 2019 Juniper Networks Selecting action for when match criteria is met Select notification options Juniper Business Use Only

Building an IDP Policy – CLI Command Example • Use Junos CLI filtering to see “set” configuration commands root> show configuration | display set | match HTTP Audit security idp policy HTTP Audit rulebase ips rule 1 match from zone any set security idp policy HTTP Audit rulebase ips rule 1 match source address any set security idp policy HTTP Audit rulebase ips rule 1 match to zone any set security idp policy HTTP Audit rulebase ips rule 1 match destination address any set security idp policy HTTP Audit rulebase ips rule 1 match application default security idp policy HTTP Audit rulebase ips rule 1 match attacks predefined attacks HTTP: AUDIT: URL set security idp policy HTTP Audit rulebase ips rule 1 then action no action set security idp policy HTTP Audit rulebase ips rule 1 then notification log attacks © 2019 Juniper Networks Juniper Business Use Only

Selecting and Monitoring an IDP Policy • Use the “>show security idp policy commit status” command to view the committ status • Remember, you can use operational commands in junos in edit mode with the “run” option root# run show security idp policy commit status Compiling policy. . . root# run show security idp policy commit status IDP policy[/var/db/idpd/bins/HTTP Audit. bin. gz. v] and detector[/var/db/idpd/sec repository/ installed detector/libidp detector. so. tgz. v] loaded successfully. The loaded policy size is: 1341 Bytes © 2019 Juniper Networks Juniper Business Use Only

PERFORMANCE ISSUES WITH IDP • High CPU due to IDP can be due to heavy processing of IDP Signature – In general, signatures with the flag Recommended = False can be very costly, and drive up the CPU – Usually start with Recommended signatures, then expand to critical signatures only – Signatures starting with SHELLCODE, TROJAN, APP typically can have high cpu impact – PPS rate through IDP can be determined via “show security idp status” – Check recommended flag on a signature by looking at details of a signature. root@srx 1500> show security idp attack detail APP: CA: ALERT-SRV-OF Display Name: APP: Computer Associates Alert Notification Server Buffer Overflow Severity: Critical Category: APP Recommended: false © 2019 Juniper Networks Juniper Business Use Only

ENABLING SRX SECURITY POLICIES FOR IDP PROCESSING • After IDP policies have been created, committed, activated, the last step is to add them to security policies • Select security policies that need IDP inspection and permit application services idp root# show security policies from zone trust to zone untrust policy secure to unsecure match { source address any; destination address any; application any; } then { permit { application services { idp; } } } © 2019 Juniper Networks Juniper Business Use Only

MONITORING IDP – REQUEST SECURITY IDP STATUS • Shows the status of IDPD • This shows the current and historic traffic seen by IDPD for IDP processing root@v. SRX 1> show security idp status node 0: State of IDP: Default, Up since: 2019 09 16 12: 24: 54 AEST (4 w 1 d 08: 18 ago) Packets/second: 0 Peak: 0 @ 2019 09 16 12: 24: 54 AEST KBits/second : 0 Peak: 0 @ 2019 09 16 12: 24: 54 AEST Latency (microseconds): [min: 0] [max: 0] [avg: 0] Packet Statistics: [ICMP: 0] [TCP: 0] [UDP: 0] [Other: 0] © 2019 Juniper Networks Juniper Business Use Only

MONITORING IDP – REQUEST SECURITY IDP STATUS • Also shows per flow breakdown and detector and policy information Flow Statistics: ICMP: [Current: 0] [Max: 0 @ 2019 09 16 12: 24: 54 AEST] TCP: [Current: 0] [Max: 0 @ 2019 09 16 12: 24: 54 AEST] UDP: [Current: 0] [Max: 0 @ 2019 09 16 12: 24: 54 AEST] Other: [Current: 0] [Max: 0 @ 2019 09 16 12: 24: 54 AEST] Session Statistics: [ICMP: 0] [TCP: 0] [UDP: 0] [Other: 0] Policy Name : Test Zone_trust_90000 Running Detector Version : 12. 6. 180180521 {primary: node 0} © 2019 Juniper Networks Juniper Business Use Only

MONITORING IDP – SHOW SECURITY FLOW SESSION IDP • Useful to see if traffic is being sent to the IDP process for inspecting root> show security flow session idp Flow Sessions on FPC 4 PIC 0: Total sessions: 1212 Flow Sessions on FPC 7 PIC 0: Total sessions: 1208 © 2019 Juniper Networks Juniper Business Use Only

MONITORING IDP – SHOW SECURITY IDP ATTACK TABLE • Verify that IDP is seeing attacks • To verify base IDP function, it’s useful to add HTTP: AUDIT: URL to rule 1 with no action root> show security idp attack table no forwarding IDP attack statistics: Attack name #Hits P 2 P: BITTORRENT: TRACKER UDP 3 P 2 P: BITTORRENT: DHT 1 © 2019 Juniper Networks Juniper Business Use Only

MONITORING IDP – CHECKING IDPD In troubleshooting, TAC may want to check the status and memory of the IDPD process “show system processes extensive” will show memory and CPU usage root> show system processes extensive | match idpd 1266 root 1 96 0 26928 K 14932 K select 0: 46 0. 00% idpd © 2019 Juniper Networks Juniper Business Use Only

IDP Troubleshooting © 2019 Juniper Networks Juniper Business Use Only 17

TROUBLESHOOTING IDP POLICY PUSH ISSUES Possible Causes: • Policy rulebase issues eg. , current policy not suitable for updated sigpack • Compilation issues • Unable to communicate with data plane Troubleshooting Approach: • Check “show security idp policy commit status” output for error message pointer • Check /var/log/messages for compilation failure message details • Check to see if any of the possible above causes are the triggers • Enable IDP traceoptions for more detailed logs and then push the policy again • For SRX cluster, check the IDP traceoptions file and /var/log/messages on both nodes Expected result of successful IDP policy push: >show security idp policy commit status IDP policy[/var/db/idpd/bins/test policy. bin. gz. v] and detector[/var/db/idpd/sec repository/installed detector/libidp detector. so. tgz. v] loaded successfully. The loaded policy size is: 26099497 Bytes © 2019 Juniper Networks Juniper Business Use Only

IDP POLICY PUSH ISSUES CONTD. Example non-working logs: May 12 03: 10: 00 SRX 1 [Policy /var/db/idpd/bins/Space IPS Policy. bin. gz. v. 1 load Failed] [Reason: Parsing issue in IDS rulebase] May 12 03: 10: 00 SRX 1 usp_ipc_idp_ioctl_handler: 424: sc_process_ioctl failed May 12 03: 10: 00 SRX 1 idpd[85853]: IDP_POLICY_LOAD_FAILED: IDP policy loading failed ; policy[/var/db/idpd/bins/Space IPS Policy. bin. gz. v], detector[/var/db/idpd/sec repository/installed detector/libidp detector. so. tgz. v] , failure detail[idp policy parser compile failed] May 12 03: 10: 00 SRX 1 idpd[85853]: IDP_SECURITY_INSTALL_RESULT: security package install result(Done; Attack DB update : successful [Update. Number=2482, Export. Date=Wed Apr 8 20: 23: 40 2015 UTC, Detector=12. 6. 140140822] Updating control plane with new detector : successful Updating data plane with new attack or detector : failed) Useful commands for IDP policy push troubleshooting: >show security idp policy commit status detail >file list /var/db/idpd/sets/<active policy name>. set >show security idp policies >show security idp status >show security idp security package version >show security idp counters policy ‐manager >show security idp memory >request support information | save /var/log/rsi<current date>. log >file archive compress source /var/log/* destination /var/tmp/logscurrent date. tgz >show log <idp traceoptions file> © 2019 Juniper Networks Juniper Business Use Only

UNABLE TO MAKE CHANGES TO IDP POLICY Possible Causes: • New IDP policy templates cannot be modified directly, we need to make a copy first and then make changes • Commit check failure – misconfiguration or some SRX specific issue • Coredump or memory issue Troubleshooting Approach: • Check /var/log/messages for any pointers towards the issue • Check to see if there any coredumps • Check memory statistics if there any memory allocation failures • Test in lab with customer config to see if we can replicate it Data Collection: >request support information | save /var/log/rsi<current date>. log >file archive compress source /var/log/* destination /var/tmp/logscurrent date. tgz >show security idp memory >coredumps (if any generated) © 2019 Juniper Networks Juniper Business Use Only

TROUBLESHOOTING FALSE POSITIVES False Positive: IDP incorrectly flags legitimate traffic as attack False Negative: IDP fails to detect a real attack and considers it to be legitimate traffic Troubleshooting Approach for False Positives: • Check the config for sanity check eg. , the attack is not expected based on IDP policy • Get a packet capture from customer for the relevant session and replay in lab –PCAP needs to include data during the attack –Logs with pre and post attack may help, but can • Work with signatures team to figure out if it’s a working behavior or if the signature is broken • Configure an exempt rule in IDP policy for False Positive as a temporary workaround © 2019 Juniper Networks Juniper Business Use Only

TRAFFIC NOT GETTING INSPECTED BY IDP Troubleshooting Approach: • Check the security policy config to see if the session is supposed to hit IDP • Initiate the relevant session and check “show security flow session idp source prefix a. b. c. d/x” or “show security flow session idp destination prefix a. b. c. d/x” or “show security flow session identifier <session id>” for App. Secure • If the session is not hitting IDP, check NAT config and rectify the security policy or IDP policy accordingly • If the session is hitting IDP but not getting detected then check the IDP policy specifically for attack, application, IP address match, action configured etc • Verify that attack logging is enabled for that particular IDP rule • Check for memory allocation failures in “show security idp counters flow” Data Collection: 1. Enable session logging on the SRX terminal session like putty etc 2. Enable security flow traceoptions: • set security flow traceoptions file flow trace • set security flow traceoptions flag all • set security flow traceoptions packet filter p 1 source prefix <source ip> • set security flow traceoptions packet filter p 1 destination prefix <dst ip> 3. Make sure IDP attack logging is enabled © 2019 Juniper Networks Juniper Business Use Only

TRAFFIC NOT GETTING INSPECTED BY IDP CONTD. 4. Enable IDP vty debugging: § debug usp flow disable § set usp flow local debug buf size 10240 § set usp flow local debug buf state 1 § set usp idp filter src ip <src ip> § debug usp idp level debug § debug usp idp features subs enable § debug usp idp features flow enable § debug usp idp qmodules ids enable § clear usp flow trace Use with caution as this can impact CPU, JTAC engineer to run these commands is preferred 5. check existing attacks: § show usp idp attack table § show usp idp debug counter action 6. Clear the flow trace and replicate the issue § clear usp flow trace (vty command) § <Trigger the attack now> 7. Get the flow trace: § show usp flow trace 0 (vty command) 8. Run the commands again: § show usp idp attack table § show usp idp debug counter action © 2019 Juniper Networks Juniper Business Use Only

TRAFFIC NOT GETTING INSPECTED BY IDP CONTD. 9. Get RSI, logs, security flow trace file, putty session log, src and dest IPs, timestamp of the testing, attack expected 10. Disable vty debugging: § set usp flow local debug buf state 0 § clear usp idp filter § debug usp idp level none § debug usp idp features subs disable § debug usp idp features flow disable § debug usp idp qmodules ids disable § § § § [5175] T 27 ai_tcp_stream_reass: first packet not SYN or SYN+ACK, cannot continue [5176] T 14 L 0000 Debug: sc_smintf_process_packet[cpu 14]: IDP PACKET RECEIVE EVENT [5177] T 27 ai_module_match_packet: ai_tcp_stream_reass() failed [5178] T 20 L 0000 Debug: sc_msvcs_process_packet: sp 0 x 36416 ec 8, pkt len 72, session id 236223968160, objcache allocated: 29578320 byte(s) [5179] T 27 ai_module_match_packet: disabling decoder [5180] T 20 L 0000 Debug: sc_msvcs_process_packet: ha cookie 0 x 0 [5181] T 14 L 0000 Debug: sc_smintf_process_packet: lsysid 0, sid 236223921438, sp 0 x 37 cd 3068, ha_cookie 0 x 0, base_packet 0 x 958 ba 8 b 0, ip_buf 0 x 0, packet_len 46, 'c 2 s' § [5182] T 27 Error: sc_appid_process_packet: ai_module_match_packet() failed § [1014] T 08 Debug: sc_ids_check_attack_match: attack 'WORM: MINIFLAME CNC_5' § [1015] T 06 L 0000 Debug: sc_ids_run: no. of bytes seen = 157408520 © 2019 Juniper Networks Juniper Business Use Only

IPS COUNTERS root@SRX> show security idp counters flow IDP counter type … Fast-path packets Slow-path packets Policy cache misses Sessions deleted TCP flows marked dead on RST/FIN Sessions constructed SM Sessions ignored SM Sessions interested SM Sessions not interested Sessions destructed SM Session Create SM Packet Process SM Session close SM Client-to-server packets SM Server-to-client packets SM Client-to-server L 7 bytes SM Server-to-client L 7 bytes Client-to-server flows ignored Server-to-client flows ignored … © 2019 Juniper Networks Value 1474 28 56 28 12 28 13 28 2846 28 28 1475 28 761 714 1456 2049 14 27 Juniper Business Use Only

IP ACTION TABLE When a violation occurs the administrator has the option to perform an action not only on that connection, but also on future connections depending on the configuration. This is known as an IP Action and you can view the contents of this table. root@SRX> show security flow ip-action Src-Addr 16. 0. 80. 0 16. 0. 66. 15 16. 0. 74. 17 © 2019 Juniper Networks Src-Port 0 0 0 Dst-Addr 0. 0 Proto/Dst-Port 0/0 0/0 Timeout(sec) 598/600 596/600 595/600 Juniper Business Use Only

TROUBLESHOOTING THE COMMIT/COMPILATION [edit] root@SRX# set security idp traceoptions flag all root@SRX# set security idp traceoptions level all root@SRX# set security idp traceoptions file IDP-Debug root@SRX> show log IDP-Debug Feb 11 13: 51: 49 idpd_need_policy_compile: 467 Active policy path /var/db/idpd/sets/FRE. set Feb 11 13: 51: 50 Active Policy (FRE) rule base configuration is changed so need to recompile active policy Feb 11 13: 51 Compiling policy Brad-IDP. . Feb 11 13: 51 Apply policy configuration, policy ops bitmask = 41 Feb 11 13: 51: 52 Starting policy (Brad-IDP) compile with compress dfa. . . . © 2019 Juniper Networks Juniper Business Use Only

IPS Logging and Reporting © 2019 Juniper Networks Juniper Business Use Only

IDP LOGGING – Configuring the notification as logging in rule will generate a Attack log when attack is triggered. – Attack logs are sent to configured syslog server in the syslog format. – There are two modes of notification • Event Mode • Stream Mode – There are two different log formats are supported • Structured syslog format • Syslog (Traditional) Format © 2019 Juniper Networks Juniper Business Use Only

SYSLOG MODES § Event Mode § Attack logs are sent to eventd running in the control plane. § Eventd takes care of forwarding logs are configured syslog server(s) § Recommended for low log rates scenarios; Default mode in branch platforms. § Configuration § • # set security log mode event • # set system syslog user * any emergency • # set system syslog host 4. 0. 0. 1 any • # set system syslog file messages any Stream Mode § Attack logs are sent to data plane directly and routes through RE § Recommended for the high log rates scenarios; Default mode in highend platforms. § Multiple destinations are supported § Configuration # set security log mode stream # set security log source address 5. 0. 0. 254 # set security log stream log. Stream host 5. 0. 0. 1 © 2019 Juniper Networks Juniper Business Use Only

SYSLOG FORMATS § Structured syslog format § This format is supported only in stream mode § Each filed will have name and respective values § # set security log format sd syslog Feb 26 17: 14: 37 4. 0. 0. 254 1 2010 02 26 T 17: 32: 49. 197 idpqa nomad 3 RT_IDP IDP_ATTACK_LOG_EVENT [junos@2636. 1. 1. 1. 2. 42 timestamp="1267185768" message type="SIG" source address="2001: 0030: 0000: 0001" source port="37129" destination address="2001: 0050: 0000: 0001" destination port="21" protocol name="TCP" service name="SERVICE_IDP" application name="NONE" rule name="1" rulebase name="IPS" policy name="idpengine" repeat count="0" action="DROP" severity="MEDIUM" attack name="FTP: USER: ROOT" nat source address="0. 0" nat source port="0" nat destination address="0. 0" nat destination port="0" elapsed time="0" inbound bytes="0" outbound bytes="0" inbound packets="0" outbound packets="0" source zone name="untrust" source interface name="ge 0/0/1. 0" destination zone name="trust" destination interface name="ge 0/0/2. 0" message=" "] § Syslog (Traditional) Format § Supported in both Event and Stream mode § Default configuration is syslog format § # set security log format syslog Mar 12 12: 55: 24 4. 0. 0. 254 RT_IDP: IDP_ATTACK_LOG_EVENT: IDP: at 1268378724, SIG Attack log <2001: 30: 0: 0: 1/37510 >2001: 50: 0: 0: 1/21> for TCP protocol and service SERVICE_IDP application NONE by rule 1 of rulebase IPS in policy idpengine. attack: repeat=0, action=DROP, severity=MEDIUM, name=FTP: USER: ROOT, NAT <0. 0: 0 >0. 0: 0>, time elapsed=0, inbytes=0, outbytes=0, inpackets=0, outpackets=0, intf: untrust: ge 0/0/1. 0 >trust: ge 0/0/2. 0, and misc message © 2019 Juniper Networks Juniper Business Use Only

LOG SUPPRESSION – Log suppression consolidates the logs to reduce the number of logs generated for same incident in the configured time interval. – Source address, rule id, attack name has to be same to consolidate the log. – Including destination address in log suppression parameters is optional. – First log sent immediately after attack detection – The consolidated log sent after 60 secs (default) with repeat count – Configuration # set security idp sensor configuration log suppression ? disable Disable log suppression include-destination-address Include destination address while performing a log suppression max-logs-operate Maximum logs can be operate on (256. . 65536) max-time-report Time after suppressed logs will be reported (1. . 60) no-include-destination-address Don't include destination address while performing a log suppression start-log Suppression start log (1. . 128) © 2019 Juniper Networks Juniper Business Use Only

SENSOR ACTIONS – Actions are taken to protect the resources, when an attack is identified by device. – Action is taken in such a way that the attack traffic does not reach the server/client machine. – Sensor action is taken on the session when an attack is identified. – Only the session has identified with attack will have impact, other session will not be impacted – Supported Sensor Actions • None • Recommended Action • Ignore • Diff. Serv • Drop Packet • Drop Connection • Close Client • Close Server • Close Client and Server © 2019 Juniper Networks Juniper Business Use Only

SENSOR ACTIONS (CONT’D) § None – No action taken on the session. – Session and IDP inspection will continue on the session though attack is identified. § Ignore – The session is not inspected for attack detection after action taken. – Session will continue to go through the device. § Diff. Serv – The action modifies the DSCP value of the IP Packets on both side, which passes through the device. – Diffserv Marking supports the value 0 to 63 – DSCP value is used for Qo. S on the routers/firewalls. – The DSCP value is modified as configured from the packet, which triggers the attack. – Session will continue to go through the device. © 2019 Juniper Networks Juniper Business Use Only

SENSOR ACTIONS (CONT’D) § Drop Packet – When action triggers, the attack packet is dropped – This action used for packet based signatures – Session will continue to go through the device for UDP & ICMP for packet based signatures. – The action is upgraded as Drop Connection if the signature is context based signature. § Drop Connection – When the action triggers, the packets on both direction in the connection dropped including attack packet. – This action used for context based signatures and where session needs to be dropped – Till the session times out, the action will be active. § Close Client – Reset packet will be send to client to terminate the tcp connection. – Action will work as Drop Connection for UDP/ICMP sessions – Packets will be dropped on both sides till the session times out. – This action should be used to protect the clients from STC attacks © 2019 Juniper Networks Juniper Business Use Only

SENSOR ACTIONS (CONT’D) § Close Server – Reset packet will be send to server to terminate the connection for tcp connection. – Action will work as Drop Connection for UDP/ICMP sessions – Packets will be dropped on both sides till the session times out. – This action should be used to protect the servers from CTS attacks and free up resource at server. § Close Client and Server – Reset packet will be send to client and server to terminate the connection for tcp connection. – Action will work as Drop Connection for UDP/ICMP sessions – Packets will be dropped on both sides till the session times out. § Recommended Action – Security team recommends action for each signature and anomaly. – If Recommended action is configured, the action specified in each signature will be taken. – If specific action is configured in rule, recommended action is ignored. § Configuration Example : – # set security idp policy test rulebase ips rule 1 then action drop connection © 2019 Juniper Networks Juniper Business Use Only

IP ACTIONS – IP Action is taken on the new session coming to the device. – IP Action will not have any impact on the already established sessions – IP Action is taken based on defined action, scope and time out. – Supported Actions • Notify – Sent a log when a new session hits the IP Action rule • Drop the packet when a new session hits the IP Action rule • Close – Sent Reset packet for TCP new connection & Drop packet for UDP new connection matching the IP Action rule – Supported Scopes • destination address Match destination • service Match source, destination, dst port and protocol • source address Match source • source zone Match source zone • zone service Match source zone, destination, dst port, protocol © 2019 Juniper Networks Juniper Business Use Only

IP ACTIONS CONFIGURATION – IP action timeout specified how long the ip action has to be active. – IP action 0 means infinite timeout – Configuration : # set security idp policy test rulebase ips rule 1 then ip action ip close # set security idp policy test rulebase ips rule 1 then ip action target source address # set security idp policy test rulebase ips rule 1 then ip action timeout 180 – IP Action Table : >show security flow ip action Src Addr Src Port Dst Addr Dst Port/Proto Timeout(sec) Zone Action 4. 0. 0. 1 0 0. 0 /0 178 /180 0 close © 2019 Juniper Networks Juniper Business Use Only

ACTION AND IP ACTION – Use IDP action to take action on a packet for the current session – Use IP Action to take action on future sessions from the same source, destination and/or service In the example below if an attack is detected in the current session the connection will be dropped. Any future sessions from same source will be blocked Set security idp policy test policy rulebase ips rule 1 match attacks predefined attack groups Critical Set security idp policy test policy rulebase ips rule 1 then action drop connection Set security idp policy test policy rulebase ips rule 1 then ip action target source Set security idp policy test policy rulebase ips rule 1 then ip action ip block © 2019 Juniper Networks Juniper Business Use Only

ATTACK GROUPS § Attack groups are used to filter and group the attacks based on defined criteria. § Three types of attack groups are supported § Predefined Attack Group § Predefined attack group is defined by security team. § The predefined attack group is updated during signature package update § Dynamic Attack Group § Dynamic attack group is user defined attack group § Dynamic attack group has different filters such as service, direction and etc… § Based on the defined filters, the attacks are filtered and grouped. § Updates the members of the group during policy compilation. § Custom Attack Group is static attack group. § The members has to be defined statically at the configuration § Custom attacks, predefined attacks, dynamic groups and custom attack groups can be member of Custom Attack Group © 2019 Juniper Networks Juniper Business Use Only

ATTACK GROUPS – CONFIGURATION – Dynamic Attack Group • Sample dynamic group based on severity, type and direction # set security idp dynamic attack group Dyn. Grp filters direction values client to server # set security idp dynamic attack group Dyn. Grp filters severity values critical # set security idp dynamic attack group Dyn. Grp filters type values signature – Custom Attack Group • Sample configuration of custom attack group to include predefined attack and dynamic group # set security idp custom attack group Static. Group group members HTTP: AUDIT: URL # set security idp custom attack group Static. Group group members Dyn. Grp © 2019 Juniper Networks Juniper Business Use Only

IPS SYSLOG CONFIGURATION • Syslog configuration steps: – Enable notification in the IPS rule [edit security idp policy Recommended rulebase ips] user@srx# set rule • 1 then notification log-attacks – Configure syslog with IPS matching [edit] user@srx# show system syslog file IPS_LOG { any; match RT_IDP; } Matching string for IPS notifications – View configured syslog file user@srx> show log IPS_LOG Dec 8 16: 38: 42 srx. A-1 RT_IDP: IDP_ATTACK_LOG_EVENT: IDP: at 1291826321, SIG Attack log <192. 168. 1. 10/44412 ->. . . © 2019 Juniper Networks Juniper Business Use Only

SYSLOG MESSAGE ANATOMY 6 1 8 7 2 4 3 5 9 15 13 16 10 11 1 Date and Time 9 Security Policy 2 IPS Engine IP Address 10 Action Taken 3 Attack Log Entry Data 11 Attack Level 12 Attack Name 13 NAT Addresses (if used) 14 Packet Count Information 15 16 Inbound Zone: Interface Outbound Zone: Interface 4 Attack Type 5 Source IP Address: Source Port 6 Destination IP Address: Dest. Port 7 Protocol and Service 8 Policy Rule Number © 2019 Juniper Networks Juniper Business Use Only 12 14

IP ACTION SYSLOG MESSAGE • IP Action messages are actually logged in RT_FLOW, and not in RT_IDP. This is actually part of the flow module Example: Nov 19 15: 46 srx 1500 RT_FLOW: FLOW_IP_ACTION: Flow IP action detected attack attempt: 1. 1/16197 ] 10. 10. 10/8443 from interface reth 0. 0, from zone untrust, action notify. • Log notifies for packets matching an existing session, but does not inform the actual attack. • RT_IDP message will give details about attack, source of attack, etc … © 2019 Juniper Networks Juniper Business Use Only

IPS OPERATIONAL MODE COMMANDS (1 OF 2) • Display the status of the current IPS policy user@srx> show security idp status State of IDP: Default, Up since: 2010 -10 -25 19: 42: 01 UTC (6 w 2 d 00: 13 ago) Packets/second: 372 Peak: 1496 @ 2010 -11 -23 23: 29: 08 UTC KBits/second : 297 Peak: 1102 @ 2010 -11 -23 23: 29: 37 UTC Latency (microseconds): [min: 0] [max: 0] [avg: 0] Packet Statistics: [ICMP: 6] [TCP: 62429] [UDP: 584] [Other: 0] Flow Statistics: ICMP: [Current: 0] [Max: 70 @ 2010 -11 -23 20: 54: 22 UTC] TCP: [Current: 0] [Max: 1818 @ 2010 -12 -08 17: 25: 10 UTC] UDP: [Current: 0] [Max: 174 @ 2010 -11 -23 20: 58: 48 UTC] Other: [Current: 0] [Max: 0 @ 2010 -11 -15 15: 55: 49 UTC] . . . © 2019 Juniper Networks Juniper Business Use Only

IPS OPERATIONAL MODE COMMANDS (2 OF 2) • Displays details of the attack table user@srx> show security idp attack table IDP attack statistics: Attack name #Hits HTTP: CISCO: IOS-ADMIN-ACCESS 178 HTTP: IIS: SAMPLE-ACCESS 56 HTTP: IIS: COMMAND-EXEC-ALL 28 FTP: USER: ROOT 4 HTTP: NCSA: PHF-EXEC 4 HTTP: CISCO: SCANNER-PROBE 2 HTTP: IIS: ISAPI-PRINTER-OVERFLOW 2 HTTP: INFO-LEAK: DS-STORE 2 HTTP: IIS: ENCODING: SINGLE-DIG-1 1 © 2019 Juniper Networks Juniper Business Use Only

IDP TRACEOPTIONS • IDP traceoptions are enabled to get more information on IDP processing that goes in the background. • IDP traceoptions can provide information on: – – – • • Policy parsing, compilation, packing Application Signature parsing, compilation and packing Policy memory estimate Sensor configuration Policy load operation status # set security idp traceoptions file <filename> files <number of files> size <size of the file> # set security idp traceoptions flag all # set security idp traceoptions level all # commit • > show log idp trace (assuming idp trace is the filename of idp traceoptions) © 2019 Juniper Networks Juniper Business Use Only

EXAMPLE: IDP TRACEOPTIONS • • May 8 02: 36: 24 idpd_policy_load: IDP_LOADER_POLICY_PRE_COMPILE returned EAGAIN, retrying. . . after (5) secs May 8 02: 36: 29 idp_policy_loader_command: sc_klibs_subs_policy_pre_compile() returned 35 (EAGAIN) May 8 02: 36: 29 idpd_policy_load: IDP_LOADER_POLICY_PRE_COMPILE returned EAGAIN, retrying. . . after (5) secs May 8 02: 36: 34 idp_policy_loader_command: sc_klibs_subs_policy_pre_compile() returned 35 (EAGAIN) May 8 02: 36: 34 idpd_policy_load: IDP_LOADER_POLICY_PRE_COMPILE returned EAGAIN, retrying. . . after (5) secs May 8 02: 36: 39 idp_policy_loader_command: sc_klibs_subs_policy_pre_compile() returned 0 (EOK) May 8 02: 36: 39 idpd_policy_load: idp policy parser pre compile succeeded, after (3) retries • May 8 02: 36: 42 idpd_policy_load: idp policy parser compile succeeded • May 8 02: 36: 42 idpd_policy_load: idp policy pre install succeeded • May 8 02: 36: 42 idpd_policy_load: idp policy post install succeeded • May 8 02: 36: 42 IDP policy[/var/db/idpd/bins/Recommended. bin. gz. v] and detector[/var/db/idpd/sec repository/installed detector/libidp detector. so. tgz. v] loaded successfully. © 2019 Juniper Networks Juniper Business Use Only

WHERE ARE IPS LOG STORED? • Stream Mode: • In stream mode the security logs are directly forwarded from data plane to an external syslog server. Stream logging does not send its logs to the RE and directly sends them out the interfaces in the data plane. This provides higher logging performance. This is the recommended method. • Event Mode: • In event mode, the data plane will send all the logs to the RE to write to a file. We would additionally configure the standard syslog (system syslog) to send all the content of that file to the syslog server. Event mode logging supports limited logging rate. This is not recommended in high traffic environment as the logs can consume the link between the data plane and the control plane. This could cause interruptions of routing protocols (such as OSPF hello messages). © 2019 Juniper Networks Juniper Business Use Only

SRX IPS LOGGING • Configuring log mode [edit security] user@srx# show security { log { Two options: event or mode stream; stream format sd-syslog; source-address 10. 10. 254; stream securitylog { category all; host { 2. 2; port 514; } } } © 2019 Juniper Networks Juniper Business Use Only Formats logs as security logs

IPS PACKET LOGGING SRX IDP example of packet logging config: • set security idp policy test facebook rulebase ips rule 1 then notification packet log pre attack 10 post attack 3 post attack timeout 60 • set security idp sensor configuration packet log total memory 5 max sessions 15 source address 20. 20. 1 host 20. 20. 10 port 5 > show security idp counters packet log • IDP counters: Value • Total packets captured since packet capture was activated 2 • Total sessions enabled since packet capture was activated 1 • Sessions currently enabled for packet capture 0 • Packets currently captured for enabled sessions 0 How to forward syslogs with Packet Logging (PCAP) from SRX to STRM • http: //kb. juniper. net/Info. Center/index? page=content&id=KB 28786 How to forward traffic logs from an SRX device to STRM • http: //kb. juniper. net/Info. Center/index? page=content&id=KB 16224 How to setup NSM to log packets for IDP attacks • http: //kb. juniper. net/Info. Center/index? page=content&id=KB 15842 © 2019 Juniper Networks Juniper Business Use Only

PACKET LOGGING © 2019 Juniper Networks Juniper Business Use Only

PACKET LOGGING OVERVIEW • Viewing packets that precede and follow an attack helps you determine the purpose and extent of an attempted attack, whether an attack was successful, and if any network damage was caused by an attack. Packet analysis also aids in defining attack signatures to minimize false positives. • If packet capture is enabled when an attack is logged, a specified number of packets before and after the attack can be captured for the session. When all packets have been collected, they are transmitted in Device Management Interface (DMI) to a host device for offline analysis ATTACK © 2019 Juniper Networks DMI Juniper Business Use Only STRM

CLI CONFIGURATION [edit]user@host# show security idpidp-policy pol 0 { rulebase-ips { rule 1 { then { notification { packet-log { pre-attack 10; post-attack 3; post-attack-timeout 60; }}}}}} sensor-configuration { packet-log { total-memory 5; max-sessions 15; source-address 10. 56. 97. 3; host { 10. 24. 45. 7; port 5; }}} © 2019 Juniper Networks Juniper Business Use Only pre/post (0. . . 255) timeout Memory limits (%) STRM

PACKET CAPTURE When packet capture is enabled, the entire packet including the Layer 2 header is captured and stored in a file. You can specify the maximum size of the packet to be captured, up to 1500 bytes. Packet capture creates one file for each physical interface. You can specify the target filename, the maximum size of the file, and the maximum number of files. Packet capture files are stored in libpcap format in the /var/tmp directory Packet capture files can be opened analyzed offline with tcpdump or any packet analyzer that recognizes the libpcap format. FTP © 2019 Juniper Networks Juniper Business Use Only WIRESHARK TCPDUMP

PACKET CAPTURE CLI local logging [edit forwarding-options] user@host# set packet-capture filename pcap-file remote logging (STRM) [edit forwarding-options] user@host# set packet-log user@host# set packet-log total-memory 5 max-sessions 10 source-address 10. 20. 0. 3 host 10. 10. 50 host port 7804 Packet capture options on an interface [edit interfaces fe-0/0/1] user@host# set unit 0 family inet sampling input output © 2019 Juniper Networks Juniper Business Use Only