Site to Site VPN, Remote VPN

Site-to-site VPN

A site-to-site VPN allows offices in multiple fixed locations to establish secure connections with each other over a public network such as the Internet. Site-to-site VPN extends the company's network, making computer resources from one location available to employees at other locations. An example of a company that needs a site-to-site VPN is a growing corporation with dozens of branch offices around the world.

There are two types of site-to-site VPNs:

• Intranet-based -- If a company has one or more remote locations that they wish to join in a single private network, they can create an intranet VPN to connect each separate LAN to a single WAN.
• Extranet-based -- When a company has a close relationship with another company (such as a partner, supplier or customer), it can build an extranet VPN that connects those companies' LANs. This extranet VPN allows the companies to work together in a secure, shared network environment while preventing access to their separate intranets.

Even though the purpose of a site-to-site VPN is different from that of a remote-access VPN, it could use some of the same software and equipment. Ideally, though, a site-to-site VPN should eliminate the need for each computer to run VPN client software as if it were on a remote-access VPN. Dedicated VPN client equipment, described later in this article, can accomplish this goal in a site-to-site VPN.

Remote-access VPN

A remote-access VPN allows individual users to establish secure connections with a remote computer network. Those users can access the secure resources on that network as if they were directly plugged in to the network's servers. An example of a company that needs a remote-access VPN is a large firm with hundreds of salespeople in the field. Another name for this type of VPN isvirtual private dial-up network (VPDN), acknowledging that in its earliest form, a remote-access VPN required dialing in to a server using an analog telephone system.

There are two components required in a remote-access VPN. The first is a network access server (NAS, usually pronounced "nazz" conversationally), also called a media gateway or a remote-access server (RAS). (Note: IT professionals also use NAS to mean network-attached storage.) A NAS might be a dedicated server, or it might be one of multiple software applications running on a shared server. It's a NAS that a user connects to from theInternet in order to use a VPN. The NAS requires that user to provide valid credentials to sign in to the VPN. To authenticate the user's credentials, the NAS uses either its own authentication process or a separate authentication server running on the network.

The other required component of remote-access VPNs is client software. In other words, employees who want to use the VPN from their computers require software on those computers that can establish and maintain a connection to the VPN. Most operating systems today have built-in software that can connect to remote-access VPNs, though some VPNs might require users to install a specific application instead. The client software sets up the tunneled connection to a NAS, which the user indicates by its Internet address. The software also manages the encryption required to keep the connection secure. You can read more about tunneling and encryption later in this article.

Large corporations or businesses with knowledgeable IT staff typically purchase, deploy and maintain their own remote-access VPNs. Businesses can also choose to outsource their remote-access VPN services through an enterprise service provider (ESP). The ESP sets up a NAS for the business and keeps that NAS running smoothly.

Public Key Infrastructure (Digital Cert )

In cryptography, a public key certificate (also known as a digital certificate oridentity certificate) is an electronic document which uses a digital signature to bind a public key with an identity — information such as the name of a person or an organization, their address, and so forth. The certificate can be used to verify that a public key belongs to an individual.

In a typical public key infrastructure (PKI) scheme, the signature will be of a certificate authority (CA). In a web of trust scheme, the signature is of either the user (a self-signed certificate) or other users ("endorsements"). In either case, the signatures on a certificate are attestations by the certificate signer that the identity information and the public key belong together.

For provable security this reliance on something external to the system has the consequence that any public key certification scheme has to rely on some special setup assumption, such as the existence of a certificate authority.

Certificates can be created for Unix-based servers with tools such as OpenSSL's command. or SuSE's gensslcert. These may be used to issue unmanaged certificates, Certification Authority (CA) certificates for managing other certificates, and user and/or computer certificate requests to be signed by the CA, as well as a number of other certificate related functions.

Similarly, Microsoft Windows 2000 Server and Windows Server 2003 contain a Certification Authority (CA) as part of Certificate Services for the creation of digital certificates. In Windows Server 2008 the CA may be installed as part of Active Directory Certificate Services. The CA is used to manage and centrally issue certificates to users and/or computers. Microsoft also provides a number of different certificate utilities, such as SelfSSL.exe for creating unmanaged certificates, and Certreq.exe for creating and submitting certificate requests to be signed by the CA, and certutil.exe for a number of other certificate related functions.

Certificates and web site security

The most common use of certificates is for HTTPS-based web sites. A web browser validates that an SSL (Transport Layer Security) web server is authentic, so that the user can feel secure that his/her interaction with the web site has no eavesdroppers and that the web site is who it claims to be. This security is important for electronic commerce. In practice, a web site operator obtains a certificate by applying to a certificate provider (a CA that presents as a commercial retailer of certificates) with a certificate signing request. The certificate request is an electronic document that contains the web site name, contact email address, and company information. The certificate provider signs the request, thus producing a public certificate. During web browsing, this public certificate is served to any web browser that connects to the web site and proves to the web browser that the provider believes it has issued a certificate to the owner of the web site.

Before issuing a certificate, the certificate provider will request the contact email address for the web site from a public domain name registrar, and check that published address against the email address supplied in the certificate request. Therefore, an https web site is only secure to the extent that the end user can be sure that the web site is operated by someone in contact with the person who registered the domain name.

As an example, when a user connects to https://www.example.com/ with his browser, if the browser gives no certificate warning message, then the user can be theoretically sure that interacting with https://www.example.com/ is equivalent to interacting with the entity in contact with the email address listed in the public registrar under "example.com", even though that email address may not be displayed anywhere on the web site. No other surety of any kind is implied. Further, the relationship between the purchaser of the certificate, the operator of the web site, and the generator of the web site content may be tenuous and is not guaranteed. At best, the certificate guarantees uniqueness of the web site, provided that the web site itself has not been compromised (hacked) or the certificate issuing process subverted.

http://en.wikipedia.org/wiki/Public_key_certificate

Authentication, Authorization and Accounting

Authentication, authorization, and accounting (AAA) is a term for a framework for intelligently controlling access to computer resources, enforcing policies, auditing usage, and providing the information necessary to bill for services. These combined processes are considered important for effective network management and security.

As the first process, authentication provides a way of identifying a user, typically by having the user enter a valid user name and valid password before access is granted. The process of authentication is based on each user having a unique set of criteria for gaining access. The AAA server compares a user's authentication credentials with other user credentials stored in a database. If the credentials match, the user is granted access to the network. If the credentials are at variance, authentication fails and network access is denied.

Following authentication, a user must gain authorization for doing certain tasks. After logging into a system, for instance, the user may try to issue commands. The authorization process determines whether the user has the authority to issue such commands. Simply put, authorization is the process of enforcing policies: determining what types or qualities of activities, resources, or services a user is permitted. Usually, authorization occurs within the context of authentication. Once you have authenticated a user, they may be authorized for different types of access or activity.

The final plank in the AAA framework is accounting, which measures the resources a user consumes during access. This can include the amount of system time or the amount of data a user has sent and/or received during a session. Accounting is carried out by logging of session statistics and usage information and is used for authorization control, billing, trend analysis, resource utilization, and capacity planning activities.

Authentication, authorization, and accounting services are often provided by a dedicated AAA Server, a program that performs these functions. A current standard by which network access servers interface with the AAA server is the Remote Authentication Dial-In User Service (RADIUS).

Reference : http://searchsecurity.techtarget.com/definition/authentication-authorization-and-accounting

Cisco IOS Access Control List

WHAT IS AN ACCESS CONTROL LIST?

In the Cisco IOS, an access control list is a record that identifies and manages traffic. After identifying that traffic, an administrator can specify various events that can happen to that traffic.

WHAT'S THE MOST COMMON TYPE OF ACL?

IP ACLs are the most popular type of access lists because IP is the most common type of traffic. There are two types of IP ACLs: standard and extended. Standard IP ACLs can only control traffic based on the SOURCE IP address. Extended IP ACLs are far more powerful; they can identify traffic based on source IP, source port, destination IP, and destination port.

WHAT ARE THE MOST COMMON NUMBERS FOR IP ACLS?

The most common numbers used for IP ACLs are 1 to 99 for standard lists and 100 to 199 for extended lists. However, many other ranges are also possible.

• Standard IP ACLs: 1 to 99 and 1300 to 1999
• Extended IP ACLs: 100 to 199 and 2000 to 2699

HOW CAN YOU FILTER TRAFFIC USING ACLS?

You can use ACLs to filter traffic according to the "three P's"—per protocol, per interface, and per direction. You can only have one ACL per protocol (e.g., IP or IPX), one ACL per interface (e.g., FastEthernet0/0), and one ACL per direction (i.e., IN or OUT).

HOW CAN AN ACL HELP PROTECT
MY NETWORK FROM VIRUSES?

You can use an ACL as a packet sniffer to list packets that meet a certain requirement. For example, if there's a virus on your network that's sending out traffic over IRC port 194, you could create an extended ACL (such as number 101) to identify that traffic. You could then use thedebug ip packet 101 detail command on your Internet-facing router to list all of the source IP addresses that are sending packets on port 194.

References:

http://www.techrepublic.com/article/cisco-ios-access-lists-10-things-you-should-know/5731134

Context-Based Access Control

Context-Based Access Control

WHAT IS CBAC?

Cisco's Context-Based Access Control (CBAC) is a component of the IOS firewall feature set. Similar to reflexive ACLs, CBAC enables dynamic modification of access lists to allow certain incoming flows by first inspecting and recording flows initiated from the protected internal network. However, whereas reflexive ACLs act solely on L2-L4 protocol attributes, CBAC is able to inspect all the way to the application layer, taking into consideration characteristics of a flow on a per-protocol basis (or context).

From the conceptual illustration, we see that there are four logical points (marked in blue) at which the router can inspect traffic:

1. Inbound on the internal interface
2. Outbound on the external interface
3. Inbound on the external interface
4. Outbound on the internal interface

While we can deploy independent, static ACLs at one, some, or all of these points simultaneously, CBAC is configured and operates per interface, dynamically modifying ACL entries facing one direction based on the traffic it sees flowing in the opposite direction.

For example, let's assume we first want to allow by default all traffic traversing the router from the internal LAN (192.168.0.0/24) toward the Internet (for our purposes, 10.0.0.0/8). This is already the case, as the router will of course forward all routable traffic when no access restrictions have been applied. We also want to deny by default all traffic flowing from the Internet toward the LAN; to accomplish this we can use a simple ACL to deny all IP traffic. We'll apply it to the external interface in the inbound direction (versus the internal interface outbound) so that the router itself is protected from untrusted traffic as well.

Reference:

http://packetlife.net/blog/2009/mar/10/ios-context-based-access-control-cbac/

R1(config)# ip access-list extended DENY_ALL
R1(config-ext-nacl)# deny ip any any
R1(config-ext-nacl)# exit
R1(config)# interface f0/0
R1(config-if)# ip access-group DENY_ALL in

Secure Perimeter Routers & Disable Services & Logging

The network is the entry point to your application. It provides the first gatekeepers that control access to the various servers in your environment. Servers are protected with their own operating system gatekeepers, but it is important not to allow them to be deluged with attacks from the network layer. It is equally important to ensure that network gatekeepers cannot be replaced or reconfigured by imposters. In a nutshell, network security involves protecting network devices and the data that they forward.

The Diagram below show the basic components of a network, which act as the front-line gatekeepers, are the router, the firewall, and the switch. 

The router is the very first line of defense. It provides packet routing, and it can also be configured to block or filter the forwarding of packet types that are known to be vulnerable or used maliciously, such as ICMP or Simple Network Management Protocol (SNMP).

If you don't have control of the router, there is little you can do to protect your network beyond asking your ISP what defense mechanisms they have in place on their routers.

The configuration categories for the router are:

• Patches and updates
• Protocols
• Administrative access
• Services
• Auditing and logging
• Intrusion detection

Patches and Updates

Subscribe to alert services provided by the manufacturer of your networking hardware so that you can stay current with both security issues and service patches. As vulnerabilities are found — and they inevitably will be found — good vendors make patches available quickly and announce these updates through e-mail or on their Web sites. Always test the updates before implementing them in a production environment.

Use Ingress and Egress Filtering

Spoofed packets are representative of probes, attacks, and a knowledgeable attacker. Incoming packets with an internal address can indicate an intrusion attempt or probe and should be denied entry to the perimeter network. Likewise, set up your router to route outgoing packets only if they have a valid internal IP address. Verifying outgoing packets does not protect you from a denial of service attack, but it does keep such attacks from originating from your network.

Reference : http://msdn.microsoft.com/en-us/library/ff648651.aspx

Common Threats to Router and Switch Physical & Mitigation

Common Threats to Router and Switch Physical & Mitigation

There are typically four types of common threats for router and switch.

Hardware threats

Hardware threats involve threats of physical damage to the router or switch hardware. Mission-critical Cisco network equipment should be located in wiring closets or in computer or telecommunications rooms that meet these minimum requirements:

• The room must be locked with only authorized personnel allowed access.
• The room should not be accessible via a dropped ceiling, raised floor, window, duct-work, or point of entry other than the secured access point.
• If possible, use electronic access control with all entry attempts logged by security systems and monitored by security personnel.
• If possible, security personnel should monitor activity via security cameras with automatic recording.
• Hardware threats involve physical damage to network components, such as servers, routers, and switches

Electrical threats

Electrical threats include irregular fluctuations in voltage, such as brownouts and voltage spikes, Electrical threats, such as voltage spikes, insufficient supply voltage (brownouts), unconditioned power (noise), and total power loss, can be limited by adhering to these guidelines:

• Install uninterruptible power supply (UPS) systems for mission-critical Cisco network devices.
• Install backup generator systems for mission-critical supplies.
• Plan for and initiate regular UPS or generator testing and maintenance procedures based on the manufacturer-suggested preventative maintenance schedule.
• Install redundant power supplies on critical devices.
• Monitor and alarm power-related parameters at the power supply and device levels.

Environmental threats

Environmental threats include very low or high temperatures, moisture, electrostatic, and magnetic Interference Environmental threats, such as temperature extremes (too hot or too cold) or humidity extremes (too wet or too dry), also require mitigation. Take these actions to limit environmental damage to Cisco network devices:

• Supply the room with dependable temperature and humidity control systems. Always verify the recommended environmental parameters of the Cisco network equipment with the supplied product documentation.
• Remove any sources of electrostatic and magnetic interference in the room.
• If possible, remotely monitor and alarm the environmental parameters of the room.

Maintenance threats

Maintenance threats include not having backup parts or components for critical network components; not labeling components and their cabling correctly Maintenance threats include poor handling of key electronic components, electrostatic discharge (ESD), lack of critical spares, poor cabling, poor labeling, and so on. Maintenance-related threats are a broad category that includes many items. Follow the general rules listed here to prevent maintenance-related threats:

• Clearly label all equipment cabling and secure the cabling to equipment racks to prevent accidental damage, disconnection, or incorrect termination.
• Use cable runs, raceways, or both to traverse rack-to-ceiling or rack-to-rack connections.
• Always follow ESD procedures when replacing or working with internal router and switch device components.
• Maintain a stock of critical spares for emergency use.
• Do not leave a console connected to and logged into any console port. Always log off administrative interfaces when leaving a station.
• Do not rely upon a locked room as the only necessary protection for a device. Always remember that no room is ever totally secure. After intruders are inside a secure room, nothing is left to stop them from connecting a terminal to the console port of a Cisco router or switch.

Reference : http://computernetworkingnotes.com/network-security-access-lists-standards-and-extended/mitigating-common-threats.html