Dump

__NOINDEX__

Windows Script Backup ScreenOS
@echo off REM ================================================================ REM ===This Script may give following error: REM ===FATAL ERROR: Network error: Connection timed out ==> Check IP addresses REM ===FATAL ERROR: Network error: Connection refused ==> Check SSH Parameters on Firewall REM ===WARNING - POTENTIAL SECURITY BREACH! ==> SSH Public Keys changed/recalculated REM ===Access denied ==> Password wrong REM ================================================================ REM ===No of times "Access denied" message appears ==> no of wrong firewalls with wrong pwds REM ================================================================ REM ===Configurable Parameters REM ================================================================ set username=aman set CFGFILE=BackupList.txt set DESTDIR=Backups\ REM ================================================================ REM ===Script code starts here REM ================================================================ SET TIMESTAMP=%date:~-4,4%.%date:~-7,2%.%date:~-10,2% for /F "tokens=1,2,3 delims=," %%A in (%CFGFILE%) do (   IF NOT EXIST "%DESTDIR%%TIMESTAMP%" mkdir "%DESTDIR%%TIMESTAMP%"    plink -ssh -C -batch -pw %%C %username%@%%B get config > "%DESTDIR%%TIMESTAMP%\%%A.cfg" ) echo Backup completed

"BackupList.txt" file: R1,192.168.1.3,cisco R2,192.168.1.4,cisco2

Need to download Plink from this Link

HA Best Practices
Basic:

1.	Two Firewalls should have same Hardware(Model, Modules, Ram, Ports, etc) 2.	Firmware should be exactly same i.e. Major, Minor as well as Patch version 3.	Licenses & features on both firewalls should be same (Basic, Advanced, AV, DI, AS, Web filtering, etc) 4.	One firewall with expired license should be not put in cluster with a firewall with no license as it may cause them to become out of sync & different free memory. 5.	It is recommended to configure cluster with 2 dedicated HA links. 6.	VSD Group should be 0. If it is not 0, need to assign interfaces to that VSD Group on both firewalls. 7.	Console access is always recommended before Configuring/ Implementing/ Troubleshooting NSRP issues. 8.	Hostnames of the firewalls should be different to differentiate between devices.

Preempt:

1.	Preempt should be enabled. 2.	Hold-down timer should have a higher value (~120-180 seconds) to prevent NSRP failover flapping. 3.	Preempt need not be configured on the backup device. 4.	It should not be configured in environments with dynamic routing protocols due to protocol re-convergence. 5.	The priority of the preferred backup should be a higher value, as the lower priority takes precedence.

Interface Monitoring:

1.	Only add critical interfaces to Monitoring to avoid unnecessary failovers/preempts.

Track-IP:

1.	Track-IP is necessary to achieving a successful failover event, when the primary Juniper firewall stops passing traffic; but the monitored interfaces remain up while using interface monitoring only. 2.	Need to determine one or more hosts that can reliably respond to ICMP/ARP traffic.

Master-Always-Exist:

1.	With NSRP monitoring enabled, both NSRP peers can become 'Inoperable'. Enabling the master-always-exist option will ensure that the cluster remains available. 2.	Run the command “set nsrp vsd-group master-always-exist” only on Master & it will sync to Backup automatically. Secondary-path:

1.	To avoid Split Brain, Configure NSRP with 2 dedicated HA links. 2.	The secondary-path option allows NSRP to poll the peer via an alternate, non-dedicated interface. The purpose is only to prevent a split-brain scenario, so NSRP sync data is not carried across this link, only heart-beat messages.

RTO Sync:

1.	Backup Session Timeout Acknowledge should be enabled 2.	Route Synchronization should not be used unless Dynamic Routing Protocol is running.

HA probe:

1.	HA probe must be enabled if the HA links are connected through a layer 2 switch. 2.	It should NOT be used if they are directly connected. 3.	Duplex settings on the switch and firewall interfaces should match. Authentication & Encryption password:

1.	Use NSRP Authentication & Encryption if the HA Cables connect through a layer 2 switch. 2.	No need to use Authentication & Encryption if they are directly connected. Misc:

1.	While adding secondary firewall in a cluster, Interface-based Default Route such as “set interface gateway ” will result in loss of communication as the Interface will become Inactive. Need to add regular Default Route before proceeding. 2.	Duplicate MAC address seen when 2 set of NSRP Clusters with same Cluster ID and VSD-Group are attached to the same switch/or are in same Broadcast Domain. Changing the Cluster ID or VSD group number will resolve the issue.

KBs Referred:

http://kb.juniper.net/KB9311 http://kb.juniper.net/KB9309 http://kb.juniper.net/KB11432

SRX Import config
1. load system terminal Merge|Replace| {}{}{}{} Cntl+D commit

2. Edit Set... set... one by one commit

Juniper SRX Firewalls
Juniper SRX Firewalls run = used in configure mode to use operational mode commands

//Show Routes show route brief show route best x.x.x.x set routing-options static route 10.2.2.0/24 next-hop 10.1.1.254 //Forwarding Table run show route forwarding-table destination x.x.x.x/24

//TraceOptions settings root@fw1# show security flow | display set set security flow traceoptions file matt_trace set security flow traceoptions file files 3 set security flow traceoptions file size 100000 set security flow traceoptions flag basic-datapath set security flow traceoptions packet-filter f0 source-prefix 10.0.0.1/32 destination-prefix 200.1.2.3/32 set security flow traceoptions packet-filter f1 source-prefix 10.0.0.1/32 destination-prefix 200.1.2.3/32 activate security flow traceoptions commit monitor start matt_trace monitor list

!! Kill the capture monitor stop  clear log            !! Clear the log file delete security flow traceoptions commit file delete 

//Show Traceoptions show security flow session source-prefix 10.124.80.42 destination-prefix 117.1.1.25 start shell

egrep ‘matched filter|(ge|fe|reth)-.*->.*|session found|create session|dst_xlate|routed|search|denied|src_xlate|outgoing phy if’ /var/log/matt_trace | sed -e ‘s/.*RT://g’ | sed -e ‘s/tcp, flag 2 syn/–TCP SYN–/g’ | sed -e ‘s/tcp, flag 12 syn ack/–TCP SYN\/ACK–/g’ | sed -e ‘s/tcp, flag 10/–TCP ACK–/g’ | sed -e ‘s/tcp, flag 4 rst/–TCP RST–/g’ | sed -e ‘s/tcp, flag 14 rst/–TCP RST\/ACK–/g’ | sed -e ‘s/tcp, flag 18/–TCP PUSH\/ACK–/g’ | sed -e ‘s/tcp, flag 11 fin/–TCP FIN\/ACK–/g’ | sed -e ‘s/tcp, flag 5/–TCP FIN\/RST–/g’ | sed -e ‘s/icmp, (0\/0)/–ICMP Echo Reply–/g’ | sed -e ‘s/icmp, (8\/0)/–ICMP Echo Request–/g’ | sed -e ‘s/icmp, (3\/0)/–ICMP Destination Unreachable–/g’ | sed -e ‘s/icmp, (11\/0)/–ICMP Time Exceeded–/g’ | awk ‘/matched/ {print “\n\t\t\t=== PACKET START ===”}; {print};’

//Show Sessions run show security flow session destination-prefix x.x.x.x

//Match Policy run show security match-policies from-zone zonea to-zone zoneb source-ip x.x.x.x destination-ip x.x.x.x protocol tcp source-port 1024 destination-port xx

//Check for Block Group show security policies from-zone untrust to-zone trust | display set | grep deny

//Find Syntax for an Existing Command show | display set | xxxxxxxxx

//VPN Troubleshooting show security ike security-associations [index ] [detail] show security ipsec security-associations [index ] [detail] show security ipsec statistics [index ]

//VPN //Set proxy ID’s for a route based tunnel set security ipsec vpn vpn-name ike proxy-identity local 10.0.0.0/8 remote 192.168.1.0/24 service any

//Packet Capture set security datapath-debug capture-file my-capture set security datapath-debug capture-file format pcap set security datapath-debug capture-file size 1m set security datapath-debug capture-file files 5 set security datapath-debug maximum-capture-size 400 set security datapath-debug action-profile do-capture event np-ingress packet-dump set security datapath-debug packet-filter my-filter action-profile do-capture set security datapath-debug packet-filter my-filter source-prefix 1.2.3.4/32

//Super SRX Packet Capture Filter egrep ‘matched filter|(ge|fe|reth ) -.*- > .*|session found|Session \(id|session id|create|dst_nat|chose interface|dst_xlate|routed|search|denied|src_xlate|dip id|outgoing phy if|route to|DEST|post’ /var/log/mchtrace | uniq | sed -e ‘s/.*RT://g’ | awk ‘/matched/ {print “\n\t\t\t=== PACKET START ===”} ; {print} ;’ | awk ‘/^$/ {print “\t\t\t=== PACKET END ===”}; {print};’ ; echo | awk ‘/^$/ {print “\t\t\t=== PACKET END ===”}; {print};’

// Policy commands

show | display set (shows policy) set system syslog set security log set interfaces ge-0/0/3 gigether-options auto-negotation (redundant-parent) set security policies from-zone xxx to-zone xxx policy policy_name match set security zones security-zone untrust address-book address set security nat source rule-set zone-to-zone rule rule-source-nat match source-address 10.0.0.0 set routing-instances set applications

set security ike proposal set security ike policy set security ike gateway set security ipsec proposal set security ipsec policy set security ipsec vpn

show|compare commit check commit comments ticket#2222 and-quit

set security policies from-zone dmz to-zone trust policy 12 match source-address h_10.124.0.1 destination-address h_1.2.3.4 application tcp_22 set security policies from-zone dmz to-zone trust policy 12 then permit set security policies from-zone dmz to-zone trust policy 12 then log session-init session-close

+        match { +            source-address h_10.124.0.1; +            destination-address h_1.2.3.4; +            application tcp_22; +        } +         then { +            permit; +            log { +                session-init; +                session-close; +            } +         } +     }

Various: show system uptime 	Uptime show version 	Version of platform (host/model) show chassis firmware 	Firmware loaded on FPCs show system software detail show chassis routing-engine 	CPU, Memory for Routing-Engine show chassis fan 	Speed and status of fans show chassis environment 	Temperature status of components show chassis hardware detail 	Hardware inventory (backplane) show system core-dumps 	Core-dumps show system alarms 	System alarms show chassis alarms 	Alarms for hardware and chassis show system boot-messages 	Logs from boot sequence show log chassisd 	Logs for SRX chassis (Cards) show log messages 	Recent system messages show configuration security log 	Syslog configuration show system buffers 	Utilization of memory buffers show system virtual-memory 	Virtual memory utilization show system processes 	Processes running on system show security idp memory 	IDP memory statistics show security monitoring performance session 	Session counts on each FPC

MIP in a policy-based VPN
KB9924

This work-around is for configuring a Mapped Internet Protocol (MIP) address in a policy-based VPN, where they are typically created on tunnel interfaces in a route-based VPN. This workaround applies when the customer requirement does not allow for a route-based VPN.

Customer requirements:

A site-to-site VPN tunnel between a Juniper firewall and a Cisco. The Cisco Peer IP address and the Remote subnet must use the same Public IP address. MIPs need to be configured for the servers behind the Juniper Firewall.

For these requirements, a route-based VPN on the Juniper firewall is not an option because a route is needed to the remote network pointing to the tunnel interface. If the peer IP and remote IP addresses are the same for both devices, the IKE negotiation can not be established. A policy-based VPN can be configured for this design, since only a default route is needed and then a policy can be used to determine the VPN. On the Juniper firewall, a MIP needs to be configured for the servers on the private network, which need to be accessed via a VPN from the Cisco site. However, MIPs are not directly supported in policy-based VPN.

If the outgoing interface is in a zone other than Untrust (for example, zone is ISP), follow KB27122- [ScreenOS] How to configure a MIP in a policy based VPN when outgoing interface is in zone other than Untrust

Untrust-Tun is the Tunnel type zone, carrier zone that helps encryption-decryption set interface tunnel.1 zone Untrust-Tun

Fixed IP on the tunnel interface set interface tunnel.1 ip 4.4.4.10/24 MIP will be used by the cisco-remote network to connect to server behind the Juniper firewall's local network set interface tunnel.1 mip 4.4.4.11 host 20.20.20.5 netmask 255.255.255.255

A route needs to be added to send the traffic to the tunnel interface: set route 25.34.5.7 interface tunnel.1 Phase 1 configuration: set ike gateway Netscreen-Cisco-IKE address 25.34.5.7 main outgoing-interface ethernet4 preshare test sec-level standard

Phase 2 configuration: set vpn Netscreen-Cisco-VPN gateway Netscreen-Cisco-IKE sec-level standard Bind Tunnel Zone (Juniper firewall will recognize the MIP configured on the tunnel interface): set vpn Netscreen-Cisco-VPN bind zone Untrust-Tun

Then an appropriate access-list needs to be configured on the Cisco end to support Proxy-IDs generated by the polices in the Juniper firewall. set policy from untrust to trust 2.2.2.2/32 MIP (4.4.4.10) any tunnel vpn Netscreen-Cisco-VPN log set policy from trust to untrust 20.20.20.5/32 2.2.2.2/32 any tunnel vpn Netscreen-Cisco-VPN log

Note: The MIP will work in only one direction. If traffic needs to be initiated from the Netscreen Trust zone over the tunnel and that traffic must use NAT, then a DIP is required, and the DIP cannot use the same IP as the MIP. This is a limitation. If a bi-directional MIP is required a route based VPN must be used.

Workaround if outgoing is other than Untrust Zone
If the outgoing interface is in a zone other than Untrust (for example, zone is ISP) proceed with following:

set zone "ISP" set internet ethernet0/2 zone "ISP" ISP is the zone for outgoing interface ethernet0/2: set internet ethernet0/2 ip 1.1.1.1/24

ISP-Tun zone is the carrier zone for the tunnel for NAT-ing: set zone "ISP-Tun" tunnel ISP

Untrust-Tun is the Tunnel type zone, carrier zone that helps encryption-decryption: set interface tunnel.1 zone ISP-Tun

Fixed IP on the tunnel interface set interface tunnel.1 ip 4.4.4.10/24

MIP will be used by the remote network to connect to server behind the ScreenOS firewall's local network: set interface tunnel.1 mip 4.4.4.11 host 20.20.20.5 netmask 255.255.255.255

A route needs to be added to send the traffic to the tunnel interface; for the translation to take place: set route 6.7.8.9/32 interface tunnel.1

Phase 1 configuration: set ike gateway Netscreen-IKE address 2.2.2.2 main outgoing-interface ethernet0/2 preshare test sec-level standard

Phase 2 configuration: set vpn Netscreen-VPN gateway Netscreen-IKE sec-level standard

Bind Tunnel Zone (ScreenOS firewall will identify the MIP configured on the tunnel interface): set vpn Netscreen-VPN bind zone Untrust-Tun

Then an appropriate access-list must be configured on the remote end to support Proxy-IDs generated by the polices in the ScreenOS firewall. set policy from ISP to trust 6.7.8.9/32 MIP (4.4.4.11) any tunnel vpn Netscreen-VPN log set policy from trust to ISP 20.20.20.5/32 6.7.8.9/32 any tunnel vpn Netscreen-VPN log

get sa detail
CORPORATE-> get sa total configured sa: 1 HEX ID  Gateway   Port Algorithm   SPI Life:sec kb Sta PID vsys 00000001< 2.2.2.2 500 esp:3des/sha1 c2e1f0e4 3296 unlim A/- -1 0 00000001> 2.2.2.2 500 esp:3des/sha1 74098e47 3296 unlim A/- -1 0

We can see that the remote peer is 2.2.2.2. The State shows A/-. The possible states are below:

I/I SA Inactive. VPN is currently not connected. A/- SA is Active, VPN monitoring is not enabled A/D SA is Active, VPN monitoring is enabled but failing thus DOWN A/U SA is Active, VPN monitoring is enabled and UP

Gateway IP address for Next Hop
Why is it necessary to specify 'Gateway IP address for Next Hop' during the configuration of static default route?

SSG-> set route 0.0.0.0/0 int eth0/1
 * Scenario I: Next-hop gateway IP address is not specified in the static default route.

SSG-> get db st

route to 4.2.2.2 cached arp entry with MAC 000000000000 for 4.2.2.2 add arp entry with MAC 000000000000 for 4.2.2.2 to cache table wait for arp rsp for 4.2.2.2 ifp2 ethernet0/1, out_ifp ethernet0/1, flag 10000e00, tunnel ffffffff, rc 0 outgoing wing prepared, not ready

SSG-> get route | i 4.2.2.2 Because the next-hop IP address is not specified in the default route, the firewall is doing an ARP for 4.2.2.2.
 * 16 0.0.0.0/0 eth0/1 0.0.0.0 S 20 1 Root

When the firewall needs to forward a packet via the default route, it needs the MAC address of the default router in order to build the frame to forward the packet.

The reason for the failure is that the firewall is waiting for an ARP response from 4.2.2.2, as if it was on a connected segment. This is indicated by the 'wait for arp rsp for 4.2.2.2', which it never receives.

It then drops the packet with the message 'outgoing wing prepared, not ready' which indicates that there is no ARP response;

SSG-> set route 0.0.0.0/0 int eth0/1 gateway 1.1.1.2
 * Scenario II: Next-hop gateway ip address is specified in the static default route.

SSG-> get db st

route to 1.1.1.2 cached arp entry with MAC 000000000000 for 1.1.1.2 add arp entry with MAC 002688e8c305 for 1.1.1.2 to cache table arp entry found for 1.1.1.2 ifp2 ethernet0/1, out_ifp ethernet0/1, flag 10800e00, tunnel ffffffff, rc 1 outgoing wing prepared, ready

SSG-> get route | i 4.2.2.2 In this scenario, the firewall found the MAC address for the next-hop gateway (ISP router with ip 1.1.1.2) in its ARP table.
 * 15 0.0.0.0/0 eth0/1 1.1.1.2 S 20 1 Root

It was then able to build the frame and forward the packet to the ISP router, which in turn routed the packet to its next hop, until the packet reached the destination IP 4.2.2.2.

SRX Stuck on old technology
The SRX uses stateful inspection which relies on port and protocol for policy decisions, a technique that is ineffective at controlling applications that use dynamic ports, encryption, or tunnel across often used/allowed ports to bypass firewalls.

Stateful Inspection
This solution allows calls to come from any port on an inside machine, and will direct them to port 25 on the outside.

So why is it wrong?

Our defined restriction is based solely on the outside host’s port number, which we have no way of controlling. Now an enemy

can access any internal machines and port by originating his call from port 25 on the outside machine.

What can be a better solution ?

The ACK signifies that the packet is part of an ongoing conversation Packets without the ACK are connection establishment messages, which we are only permitting from internal hosts

Sub interface number
The maximum permitable number for sub interface number in Juniper SSG140 firewall is 100. The firewall will accept a number in the range of 1-100 only. Sub Interface names in Juniper Netscreen firewalls are like: eth0/1.50, eth0/2.100. A name like eth0/2.101 or eth0/2.200 will not be acceptable.

Window size smaller that MTU
If window size is smaller than MTU, packet retransmissions will occur. This is an application issue. This means buffer size is smaller & lager packets are received.



= Certificates = ​ A session symmetric key between two parties is used only once.

The symmetric (shared) key in the Diffie-Hellman method is K = g xy mod p.

In public-key cryptography, everyone has access to everyone’s public key; public keys are available to the public.

Our example uses small numbers, but note that in a real situation, the numbers are very large. Assume that g = 7 and p = 23. The steps are as follows: 1. Alice chooses x = 3 and calculates R 1 = 7 3 mod 23 = 21. 2. Alice sends the number 21 to Bob. 3. Bob chooses y = 6 and calculates R 2 = 7 6 mod 23 = 4. 4. Bob sends the number 4 to Alice. 5. Alice calculates the symmetric key K = 4 3 mod 23 = 18. Bob calculates the symmetric key K = 21 6 mod 23 = 18. The value of K is the same for both Alice and Bob; g xy mod p = 7 18 mod 35 = 18.

Public Announcement: The naive approach is to announce public keys publicly. Bob can put his public key on his website or announce it in a local or national newspaper. When Alice needs to send a confidential message to Bob, she can obtain Bob’s public key from his site or from the newspaper, or even send a message to ask for it. This approach, however, is not secure; it is subject to forgery. For example, Eve could make such a public announcement. Before Bob can react, damage could be done. Eve can fool Alice into sending her a message that is intended for Bob. Eve could also sign a document with a corresponding forged private key and make everyone believe it was signed by Bob. The approach is also vulnerable if Alice directly requests Bob’s public key. Eve can intercept Bob’s response and substitute her own forged public key for Bob’s public key.

CSR has a Public Key.

CA signs it.

Certificate is a proof of public key.

Encrypt using public key & receiver decrypts using private key.

There are two types of certificate authorities (CAs), root CAs and intermediate CAs.

Certificate 1 - Issued To: example.com; Issued By: Intermediate CA 1 Certificate 2 - Issued To: Intermediate CA 1; Issued By: Intermediate CA 2 Certificate 3 - Issued To: Intermediate CA 2; Issued By: Intermediate CA 3 Certificate 4 - Issued To: Intermediate CA 3; Issued By: Root CA

Root CA certificates, on the other hand, are "Issued To" and "Issued By" themselves,

For enhanced security purposes, most end user certificates today are issued by intermediate certificate authorities.

Installing an intermediate CA signed certificate on a web server or load balancer usually requires installing a bundle of certificates.

The CA will also provide a so called intermediate CA file or chain certificate. It proves that your chosen CA is trusted by one of the root CAs. You will need the intermediate CA certificate as 'chain' certificate in your clientssl profile.

Nonce is Number Once

In an asymmetric key encryption scheme, anyone can encrypt messages using the public key, but only the holder of the paired private key can decrypt. Security depends on the secrecy of the private key.

In the Diffie–Hellman key exchange scheme, each party generates a public/private key pair and distributes the public key. After obtaining an authentic copy of each other's public keys, Alice and Bob can compute a shared secret offline. The shared secret can be used, for instance, as the key for a symmetric cipher.


 * Public-key encryption, in which a message is encrypted with a recipient's public key. The message cannot be decrypted by anyone who does not possess the matching private key, who is thus presumed to be the owner of that key and the person associated with the public key. This is used in an attempt to ensure confidentiality.


 * Digital signatures, in which a message is signed with the sender's private key and can be verified by anyone who has access to the sender's public key. This verification proves that the sender had access to the private key, and therefore is likely to be the person associated with the public key. This also ensures that the message has not been tampered with, as any manipulation of the message will result in changes to the encoded message digest, which otherwise remains unchanged between the sender and receiver.