Hi viewer's I am back with new posts
Translate
Sunday, 27 December 2015
Thursday, 2 July 2015
ALERT
Hi viewers, I am working on site to site IOS VPN carried out by legacy method. Its very innovative and by my style of studying. You will get lot of it by viewing that.
Thursday, 25 June 2015
BASIC UNDERSTANDING FOR THE POINT
UNDERSTANDING AT POINT HOW ENGINE WORKS:
1. First
we need to create ISAKMP policy which includes HAGLE.
2. Then
tell who is the peer and key or identity to authenticate.
3. Create
a ACL for identifying interesting traffic.
4. Create
a IPSEC TRANSFORM SET which says what is Encryption and Encapsulation.
5. Create
MAP and include IPSEC TRANSFORM SET, PEER and ACL no.
6. Associate
the MAP on the peer interface so that when traffic initiates the MAP comes in
action.
Sunday, 14 June 2015
VPN AH & ESP
Authentication Header and Encapsulating Security Payload
Both AH and ESP operate at the
network layer of the OSI model and, as a result, have their own protocol
numbers for protocol identification carried out by devices in the VPN path. (The
protocol numbers assigned are 51 and 50, respectively.) As mentioned earlier,
ESP can provide the optional encryption function for data traversing the VPN
connection. Therefore, ESP is the
preferred choice for use with IPsec. The data encryption function provided by
ESP is carried out by one of the following symmetric key algorithms:
Digital
Encryption Standard (DES)
Triple DES
(3DES)
Advanced
Encryption Standard (AES) (preferred)
The origin authentication, provided
by both AH and ESP, can be carried out by one of the following hash algorithms:
Message digest
5 algorithm (MD5)
Secure Hash
(SHA) (and
only for IKEv2: SHA256, SHA384, SHA512)
AH is unavailable for use on the
ASA because of the lack of an encryption option. Therefore, when configuring a
VPN, only ESP is available to us. Because ESP and AH operate at the network
layer, the original host and destination IP addresses remain in the packet
throughout the network, exposing them to potential attackers of the VPN
connection. However, which IPsec mode (either Transport or Tunnel) is chosen
determines the amount of the original packet to be hidden.
Normal Frame:
Ethernet Header
|
IP Header
|
TCP/UDP Header
|
DATA
|
AH Transport mode frame
Ethernet Header
|
IP header
Authenticated
|
AH Header
Authenticated
|
TCP/UDP Header
Authenticated
|
DATA
Authenticated
|
AH Tunnel mode frame
Ethernet
Header
|
New
IP Header
Authenticated
|
AH
Header
Authenticated
|
IP
Header
Authenticated
|
TCP/UDP
Header
Authenticated
|
DATA
Authenticated
|
ESP
Transport mode frame
Ethernet Header
|
IP Header
|
ESP
Header
Authenticated
|
Encrypted
TCP/UDP
Header
Authenticated
|
Encrypted
Data
Authenticated
|
ESP Trailer
Authenticated
|
ESP Authentication
Authenticated
|
ESP
Tunnel mode frame
Ethernet Header
|
New IP Header
|
ESP Header
Authenticated
|
Encrypted
IP Header
Authenticated
|
Encrypted
TCP/UDP Header
Authenticated
|
Encrypted
Data
Authenticated
|
ESP Trailer
Authenticated
|
ESP Authentication
Authenticated
|
In both AH and ESP Transport mode,
the original IP addresses remain untouched and are visible to potential
attackers. However, when operating within Tunnel mode, the AH and ESP headers
are placed after the original IP header, and a new IP header is added. This
header contains the IP addresses of the VPN endpoints (ASA, PIX, concentrator,
or router), which are generally public IP addresses and contain no information,
thus not allowing an attacker to determine any valuable information about the
internal network. ASA, as a VPN tunnel endpoint, supports only Tunnel mode.
Even if Transport mode is configured on the ASA, the resulting VPN tunnel
negotiates and uses Tunnel mode. This is also the case for Cisco routers
running IOS. However, this restriction applies only to native IPsec
functionality, Transport mode is supported on IOS routers (for example, when generic routing encapsulation [GRE] tunneling
is used along with IPsec, but not on the ASA, which does not support GRE
termination).
Saturday, 13 June 2015
VPN XAUTH
XAUTH
An
optional Extended Authentication (XAUTH) phase can also take place after
successful Phase 1 SA creation. XAUTH carries out the process of end
host/device authentication before a user can use the VPN connection. Be careful
not to confuse this optional step with the peer authentication carried out
within IKEv1 Phase 1. The difference is IKEv1 Phase 1 carries out the
authentication of the VPN peers used to terminate each end of the SA, whereas
XAUTH is used for the authentication of users or devices that will be
transmitting and receiving data across the established VPN tunnel. This phase
can occur in remote-access or Easy VPN scenarios, but not in site-to-site VPNs.
XAUTH
authentication can be achieved by using either of the following:
Static username and passwords
One-time passwords (OTP)
VPN IKEv1 PHASE II
IKEv1 Phase 2
This second mandatory phase uses
the negotiated parameters in Phase 1 for secure IPsec SA creation. However,
unlike the single bidirectional SA created within Phase 1, the IPsec SAs are
unidirectional, meaning a different session key is used for each direction (one
for inbound, or decrypted, traffic, and one for outbound, or encrypted,
traffic). This is applicable for any administrator-configured source-destination
network pair. Therefore, you might end up with four unidirectional IPsec SAs if
you have two source-destination network pairs defined in a VPN policy.
During IKEv1 Quick mode (Phase 2),
IKEv1 transform sets (a list of encryption and hashing protocols) used for
IPsec policy negotiation and unidirectional SA creation are exchanged between
peers. Regardless of the parameters/attributes selected within a transform set,
the same five pieces of information are always sent:
IPsec encryption algorithm (DES, 3DES,
AES)
IPsec authentication algorithm (MD5,
SHA-1)
IPsec protocol (AH or ESP)
IPsec SA lifetime (seconds or kilobytes)
IPsec mode (Tunnel,
Transport)
VPN IKE PHASE I
IKEv1 Phase 1
During
this phase, both peers negotiate parameters (integrity and encryption
algorithms, authentication methods) to set up a secure and authenticated tunnel.
This is also called a management channel because no user data is flowing through
it (and it is actually a bidirectional IKE SA). It is called bidirectional
because both peers use only one session key to secure both incoming and
outgoing traffic. Peer authentication can be carried out by one of the
following methods:
Pre-shared keys
Digital certificates
IKEv1
uses either IKEv1 Main mode or IKEv1 Aggressive mode in Phase 1 to carry out the
actions required to build a bidirectional tunnel. It then uses IKEv1 Quick mode
for phase 2 operations.
IKEv1
Main mode (Phase 1) uses three pairs of messages (making six in total) between peers:
Pair 1 consists of the IKEv1 security
policies configured on the device:
One
peer (initiator) begins by sending one or more IKEv1 policies, and the
receiving peer responds (responder) with its choice from the policies.
Pair 2 includes DH public key exchange:
DH
creates shared secret keys using the agreed upon DH group/algorithm exchanged
in pair 1 and encrypts nonces (a randomly generated number) that begin life by
first being exchanged between peers. They are then encrypted by the receiving
peer and sent back to the sender and decrypted using the generated keys.
Pair 3 is used for ISAKMP authentication:
Each
peer is authenticated and their identity validated by the other using
pre-shared keys or digital certificates. These
packets
and all others exchanged from now on during the negotiations are encrypted and
authenticated using the policies exchanged and agreed upon in pair
IKEv1
Aggressive mode (Phase 1) uses just three messages rather than the six used
with Main mode. The same information is exchanged between peers. However, the
process is abbreviated by carrying out the following actions:
The initiator sends DH groups signed
nonces (randomly generated numbers), identity information, IKEv1 policies, and
so on.
The responder authenticates the packet and
sends back accepted IKEv1 policies, nonces, key material, and an identification
hash that are required to complete the exchange.
The initiator authenticates the
responder’s packet and sends the authentication hash.
Wednesday, 10 June 2015
VPN TERMINOLOGY IKE V1
IKEv1
IKEv1 provides a framework for the
parameter negotiation and key exchange between VPN peers for the correct
establishment of an SA. However, the actual processes of key exchange and
parameter negotiation are carried
out by two protocols used by IKEv1:
Internet
Security Association and Key Management Protocol (ISAKMP)
Oakley
ISAKMP takes care of
parameter negotiation between peers (for example, DH groups, lifetimes,
encryption [if required], and authentication). The process of negotiating these
parameters between peers is required for the successful establishment of SAs.
After an SA has been established, ISAKMP defines the procedures followed for
correct maintenance and removal of the SA during connection termination.
Oakley provides the
key-exchange function between peers using the DH protocol. DH is an
asynchronous protocol, meaning each peer uses its own set of keys for
communications establishment and operation between peers. However, the keys are
never exchanged, providing a much higher level of security than synchronous
protocols (DES, 3DES, and so on) that require both peers to use the same keys
for operation. After both peers have established their shared communication
path, they can proceed to exchange the keys used by the various synchronous
protocols for authentication and encryption purposes.
Tuesday, 9 June 2015
VPN TERMINOLOGY KEYS
Symmetric and Asymmetric Key Algorithms:
Before these protocols can
establish a secure communications tunnel (VPN) between two endpoints, they
generate, exchange, and use keys as a means to authenticate/encrypt the
information used to create a secure tunnel that is sent between both parties.
Symmetrical
Encryption:
One
key to encrypt as well as Decrypt
Symmetrical
Encryption Algorithm:
DES Digital Encryption Standard 56bit
3DES Triple DES 168bit
AES Advance Encryption Standard 128 , 192 , 256
bit
IDEA International Data Encryption Algorithm
Asymmetric
Encryption:
One
key to encrypt and second key to decrypt, one key is called private key which
is keep private and the second key is called as public key which is
distributed. The data encrypted by the public key can only be decrypted by the
private key and vice-versa. when we need to create session for any bank
transaction we use Asymmetrical encryption as its heavy and secure whereas when
we need to do file transfer or any data transfer we use symmetrical encryption.
Public/private
key pairs commonly use digital certificates as a method of key distribution.
Internet shopping and other sites often use SSL/TLS as a way to secure
transactions on their websites. In this case, you usually receive a copy of the
server’s digital certificate. Within the certificate is a copy of the server’s
public key. By using this public key, the host and server can set up a secure
communications path (because the server has a corresponding private key).
Examples of asymmetric key algorithms include the following:
Rivest,
Shamir, and Adleman (RSA)
Diffie-Hellman (DH)
VPN TERMINOLOGY IPSEC
IPsec
IPsec
is composed of a collection of underlying protocols that together provide the overall
operation of parameter negotiation, connection establishment, tunnel
maintenance, data transmission, and connection teardown.
Three protocols are used in the
IPsec architecture to provide key exchange in addition to the integrity,
encryption, authentication, and antireplay features discussed earlier:
IKEv1 or IKEv2 is used by IPsec for the
exchange of parameters used for key negotiation, the exchange of the derived
authentication/encryption keys, and overall establishment of security associations (SA) .
Encapsulating
Security Payload (ESP) provides
a framework for the data integrity, encryption, authentication, and antireplay
functions of an IPsec VPN.
Authentication
Header (AH) provides
a framework for the data integrity, authentication, and antireplay functions.
(No encryption is provided when using AH.)
Sunday, 7 June 2015
Subscribe to:
Posts (Atom)