.

Wednesday, December 24, 2014

Zone based Firewall (ZBF)

Zone based Firewall:



Zone based Firewall of ZFW is a new approach to configuring access control in the IOS firewall. Prior to this feature, traffic filtering was accomplished usingaccesslists and stateful traffic inspection rules (CBAC). Both the access-lists and inspection rules apply directly to the physical interfaces, which may poorly reflectorganization’s security policy, as the policy deals with more high-level objects than interfaces.A new core concept of ZFW is zone, which groups different interfaces sharing the same security attributes, the same level of trust. For example: you may have security zones that reflect your enterprise security levelspartitioning. On the figure below, you can see three security zones assigned to three router interfaces:




  By default, traffic is permitted between the interfaces within the same security zone, and blocked between different zones. Traffic between the interface configured in a security zone and interface not in any zone is blocked.In addition, you cannot apply classic firewall rules (e.g. access-lists or inspection rules) to the interface configured in a security zone.There is one default zone in every router, known as self, which encompasses the router’s own IP addresses. Traffic to and from this zone to any other zone is permitted by default, to allow for control plane and management plane traffic. However, you may apply an explicit policy between the self zone and any other
configured zone to control the router-originated traffic. If you apply a policy from
any configured zone to the self zone, the traffic from self zone to the other zone will be permitted, but the returning traffic from the configured zone may be blocked. To resolve this, you may need to assign a policy from zone self to the configured zone and inspect the router-generated traffic.

Zone based firewall implements the same set of features as the classic IOS firewall. It allows defining advanced inspection options, such as deep inspection and parameter tuning. To accomplish all listed features, ZFW uses.

The syntax for the new configuration language was heavily borrowed from the well-known MQC (Modular QoS CLI) and resembles it in many ways, by using policy-maps, class-maps and actions association.




Tuesday, December 23, 2014

Juniper SRX Packet Flow

Juniper SRX Packet Flow:

SECURITY SERVICES PACKET WALK

1) Pull packet from queue

2) Police packet

3) Filter packet


4) Session lookup

5a) No existing session

FW screen check
Static and destination NAT
Route lookup
Destination zone lookup
Policy lookup
Reverse static and source NAT
Setup ALG vector
Install session

5b) Established session

FW screen check
TCP checks
NAT translation
ALG processing

6) Filter packet
7) Shape packet
8) Transmit packet




Juniper SRX Packet Flow in detail (part 2)

Juniper SRX Packet Flow in detail (part 2)

SECURITY SERVICES PACKET WALK


About Services ALG Module:
An Application Layer Gateway (ALG) is a software component that is designed to manage specific protocols such as Session Initiation Protocol (SIP) or FTP on Juniper Networks devices running Junos OS. In Juniper SRX this is where all the services are being matched.
It has multiple module to process the services based on there service request.

1) AppID (Packet): The APPID (application identification) Module is a Junos OS feature that identifies applications as constituents of application groups in TCP/UDP/ICMP traffic.

2) IDP: This Module is use for Intrusion Detect Prevention.

3) SSL Proxy: This Module is use for SSL Inspection (ssl encrypted packet) 

4) ALG: The ALG module is responsible for Application-Layer aware packet processing.

5) UTM: With UTM module, you can implement a comprehensive set of security features that include antispam, antivirus, Web filtering, and content filtering protection.

6) AppFW: This Module is use for identifying and inspecting applications.

7) UserFW: UserFW module is foe identifying the users, basically it's identity awareness. 

Saturday, December 20, 2014

TCP Three Way Handshake

ESTABLISHING A CONNECTION


The “three way handshake” is essentially a unidirectional attempt to establish the connection, i.e. there is an initiator and a responder.
The TCP’s should however be able to establish the connection even if
a simultaneous attempt is made by both TCP’s to establish the
connection. Simultaneous attempts are treated like “collisions” in
“Aloha” systems and these conflicts are resolved into unidirectional
attempts to establish the connection. This scheme was adopted because
(i) Connections will normally have a passive and an active end,
and so the mechanism should in most cases be as simple as
possible.
(ii) It is easy to implement as special cases do not have to be
accounted for.
The example below indicates what a three way handshake between TCP’s

  • A and B looks like

  • A                                                      B

    –>          <SEQ x><SYN>              –>



    <–    <SEQ y><SYN, ACK x+l>  <–



    –> <SEQ x+1><ACK y+l><DATA BYTES> –>

The receiver of a “SYN” is able to determine whether the “SYN” was
real (and not an old duplicate) when a positive “ACK” is returned for
the receiver’s “SYN,ACK” in response to the “SYN”. The sender of a
“SYN” gets verification on receipt of a “SYN,ACK” whose “ACK” part
references the sequence number proposed in the original “SYN” [pun
intended]. If the TCP is in the state where it is waiting for a
response to its SYN, but gets a SYN instead, then it always thinks
this is a collision then it forgets that it had sent a SYN. The TCP will try to
establish the connection again after some time, unless it has to
respond to an arriving SYN. Even if the wait times in the two TCPs
are the same, the varying delays in network transmission will usually
be adequate to avoid a collision on the next cycle of attempts to
send SYN.
The State of TCP When Establishing a Connection
S1 S2 R are three state of TCP while establishing a connection
S1 = SYN sent
S2 =  My SYN verified
R = SYN received

if S1 Value is set 1 than means Syn has been sent. Same with S2 and R.

The example below indicates State of TCP in three way handshake between TCP’s
                      A                                                                            B

                      ------------                                                           -----------
                      S1 S2 R                                                              S1 S2 R
                      0 0 0                                                                     0 0 0

 (M1)            1 0 0 --> <SEQ x><SYN>                                    
(M2)            0 0 0 <-- <SEQ y><SYN )                                <-- 1 0 0
(M1)            B returns no SYN sent                                   --> 0 0 0
(M1)           1 0 0 --> <SEQ z><SYN> *                              --> 0 0 1
(M3)           1 1 1 <-- <SEQ y+1><SYN,ACK z+1>             <-- 1 0 1
(M4)           1 1 1 --> <SEQ z+1><ACK y+1><DATA>       --> 1 1 1

Note: "..." means that a message does not arrive, but is delayed
in the network. State changes are upon arrival or upon departure
of a given message.