Showing posts with label network security. Show all posts
Showing posts with label network security. Show all posts

Thursday, March 28, 2013

Cisco Flexible Packet Matching (FPM) in 15.x

Cisco FPM on ISR router is about detecting a certain pattern (e.g. regular expression) in the payload packets before deciding whether to forward or drop it. One good example is to drop malicious packets and even Skype login that attempt to change its communicating methods over time. Your IPS signatures may not even be updated quick enough.

There is an easy-to-follow FPM guide on Getting Started with Cisco IOS Flexible Packet Matching. It even stated that almost all Cisco ISR platforms support this feature. I've learnt that only certain trains and versions can support FPM commands and they may not even be the latest versions. Use "Cisco Software Advisor" on "Feature/Software" tab to determine which IOS trains and versions support FPM. Of course, you'll need a CCO account to login.

In 15.x, there is also a change in loading FPM PHDF files. Not only you don't have to download the phdf files, there is a slight change in loading FPM PHDF files:

Router(config)#load protocol system:fpm
%Complete file name to be loaded is required

Instead, you'll have to do this
Router(config)# load fpm
Try to load bundle PHDF files ...

Then do a "show protocols phdf all" to see loaded phdf files. It should include all standard PHDFs: ether.phdf, ip.phdf, tcp.phdf, and udp.phdf. These PHDFs provide Layer 2-4 protocol definition according to Flexible Packet Matching Deployment Guide.

Nested Access Control
Cisco FPM supports nested access control policy i.e. enforce a child policy on parent policy. You can define a "class-map type stack" to check on the protocol fields and use another "class-map type access-control" to check on the payload contents. For example, you want to check for a password on the payload on protocol number 17 (UDP) on port 1234. The example config would be:

!--- Define the values to be checked on UDP header port 1234
class-map type stack match-all UDP-CHECK
 match field IP protocol eq 0x11 next UDP
 match field UDP dest-port eq 1234 next UDP

!---- Ensure the payload to contain the password string. You can also use regular expression
class-map type access-control match-all PASSWORD-CHECK
 match start UDP payload-start offset 0 size 100 string "password"

!---- Define the child policy and just log the packets if payload contains the password
policy-map type access-control CHILD-POLICY
 class PASSWORD-CHECK
   log

!---- Nested policy on Parent. Check on UDP header then the payload. Otherwise, drop the packet.
policy-map type access-control PARENT-POLICY
 class UDP-CHECK
   service-policy CHILD-POLICY
 class class-default
   log
   drop

!--- Enforce the FPM policy on the router interface
interface GigabitEthernet0/0
  service-policy type access-control output PARENT-POLICY


Tuesday, May 8, 2012

How to add new interfaces on Juniper SRX chassis cluster

There are many good JUNOS articles on setting up the Juniper SRX chassis. But I just want to summarize the steps on how to add new interfaces to existing chassis cluster. In other words, the following pre-requites are complete as follows:
  1. Configuring Chassis Cluster information on both nodes e.g. set chassis cluster-id 1 node 0 
  2. Configuring Redundancy Groups (RG) and specify which node should be the primary node for each RG. e.g. set chassis cluster redundancy-group 1 node 0 priority 200. This is also where you determine whether it is a Active-Passive or Active-Active setup
  3. Configuring Out-of-Band management interface for fxp0 - optional
  4. Configuring Virtual Routing instances (a.k.a VRF-lite in Cisco networking) - optional 
  5. Configure the number of Redundant Interfaces using "set chassis cluster reth-count n" where n is the number of reth.
  6. Configuring Redundant Interface (reth) using at least one interface from each node
  7. Configuring control link using fxp1 interface where configuration synchronization takes place between 2 nodes 
  8. Configuring fabric interface (fabn where n denotes the node id) consisting of at least one ethernet interface from each node
  9. Successful cluster setup!
After you have established the cluster successfully, you may wish to add more interfaces to it. The additional steps are as follows:

Step1: Increase the reth count by using
  • set chassis cluster reth-count n where n is the new number of reth interfaces
Step 2: Identify 2 similar interfaces (one from each node e.g. ge-0/0/2 and ge-8/0/2) to form a new reth. e.g. 
  • set interfaces ge-0/0/2 gigether-options redundant-parent reth2
  • set interfaces ge-8/0/2 gigether-options redundant-parent reth2
Step 3: Configure new reth2 by heading to "edit interfaces reth2"
  • Enable VLAN tagging if you intend to use VLAN: "set vlan-tagging"
  • Create new sub-interface: "set unit nnn vlan-id " where nnn is any sub-interface number.
  • Assign IP address to sub-interface: "set unit nnn family inet address 1.1.1.1/24" 
  • Return to top level edit: "top"
Step 4: Assign this interface to the virtual routing instance
  • set routing-instances interface reth2.nnn
Step 5: Assign this interface to the appropriate security zone
  • set security zones security-zone interfaces reth2.nnn
Step 6: Check new configurations and commit
  • top
  • show | compare rollback 0
  • commit

Wednesday, May 25, 2011

Part 2: Forefront TMG URL Filtering

Following up on part 1 regarding Forefront TMG user authentication on AD mode, this part would look into URL content filtering feature. By default when URL filter is enabled during the startup wizard, TMG will block access to certain undesirable sites, including porno, gambling, malware etc.

Quite often, when you visit free news sites, you would be greeted with anonying Web Advertisements (Web Ads). And you wish to block them. Let's take a popular free news site at http://www.channelnewsasia.com/. Immediately, you will be seeing Web Ads on its top banner:


You can configure TMG to add Web Ads URL category into the block list. On the TMG console, right click on the "Web Access Policy" and choose "Configure Web Access Policy" on the context menu.

When the wizard starts, choose "No, do not create the rule for me" on the first page. On the next page (Blocked Web Destinations), click "Add", expand the "URL categories". Add "Web Ads" item. 


Complete the rest of the wizard as in default options. Apply the new changes. When you restart the client Web browser and visit the same Web site again, you'll notice that most (if not all) of the Web ads are gone.


New Site Categories Reporting in Service Pack 1
Among the new features in Service Pack 1, the new User Activity report displays the sites and site categories accessed by any user. All Forefront TMG reports also have a new look and feel. Reports can be generated one-time or recurrently. For example, you can see a sample one-time generated report for top visited URL categories as follows:


Rooms for Improvement in Reporting
Nevertheless, I still find the reporting features quite basic and lacking, as I couldn't find any filtering and search options in the report generation. 

Tuesday, May 24, 2011

Part 1: User Authentication for Forefront Threat Management Gateway (TMG) 2010

Traditional hardware-based network firewalls have one serious limitation - you can't control and track user access unless you are forcing them to perform another layer of firewall login on top of domain desktop login. If you really do, it certainly would cause much unhappiness among your users. On the other hand, if you can't control user access and track them directly from your firewall logs, you won't impress your auditors either. Hence, a simple solution to please both groups is to implement an Active Directory (AD) aware firewall solution.

One such firewall product to be seriously considered is from the maker of AD - Microsoft Forefront Threat Management Gateway (TMG) 2010 with latest Service Pack 1 (SP1). Besides being an AD-integrated firewall, it is also featuring Intrusion Prevention System (IPS), URL content filter, Web content cache and forward/reverse application proxies  - all rolled into one system.

Prior to deployment, various types of user authentication and application supports should be considered. There are 3 types of client setup to be considered:
  1. SecureNAT clients that "hide" behind some IP address. Mainly used only for anonymous Internet access. However, it does not support user authentication.
  2. Firewall clients (a.k.a TMG clients) that provide proxied winsock connections between the user applications and TMG. It automatically send client credentials with requests, which include Integrated AD authentication,  LDAP authentication, or RSA authentication (OTP).
  3. Web Proxy clients supports above authentication mechanisms. However, the only application supported is the Web browser itself. No credentials are supplied if anonymous access is enabled.
From above, you can see that the strongest & most powerful client protection is provided by the TMG clients.

Forefront TMG Installation
The initial TMG setup can be pretty straightforward, as you will be guided by a step-by-step GUI wizard (click here for details). I have configured a test setup using Hyper-V as follows:


Mass Installation of TMG Clients using AD Deployment
To simulate mass deployment on an AD domain, I have assigned the TMG clients (a.ka. software pushdown) to all computers (or users) using Group Policy - Software Installation. For mass deployment, it is also more efficient to use client auto-detection and auto-configuration using information stored in Active Directory or DNS/DHCP (click here for details). AD detection would be preferred. In the absence of AD, DNS/DHCP discovery will be used.

To publish TMG information on AD, you would also need the ADconfig Pack, which can be downloded. To store information on Active Directory, at the command prompt, type: TmgAdConfig.exe add -default -type winsock -url [-f] where the service-url entry should be in the format http://{TMGServer}:8080/wspad.dat.

TMG Client Default Automatic Detection

Enable AutoDiscovery on TMG Management Console
(Networking -> Edit Internal Network -> AutoDiscovery Tab)
DNS Setup
Another important setup to note is the DNS configuration. Just as in normal AD environment, you should configure the TMG server and the clients to reference AD-integrated DNS servers (typically Domain Controllers). Both DC1 and client1 should set TMG server as default gateway. TMG server should have a default route set directly to the Internet.

For testing purposes, you may configure the default forwaders of DNS servers to your ISP name servers.

Firewall Policy
For user authentication testing for Internet access, I have configured the following firewall rules:

There are only 3 rules configured. The first rule is system default generated rule that block users from accessing potentially harmful sites. The second rule is to permit DC1 to forward client DNS requests to ISP name servers. The third rule is to limit HTTP/HTTPS access just to AD users authorised to access the Internet.

Client Testing
To simulate an unauthenticated user trying to access Internet, I login to Win7 client1 using local computer account. As expected, the Internet access is denied for anonymous access as shown under the "Logs and Reports" section of the TMG management console.

Subsequently, I login using a domain user account. Internet access to xin.msn.com succeeded.


Security Considerations for Active Directory Forest
As you can see from above, Forefront TMG succeeded in controlling user access based on Active Directory information. The logs also reveal User Identity and destination URLs instead of merely just client and desintation IP addresses as in most network firewall logs. As the firewall is relying on AD for user authentication and authorization, Microsoft advises further protection using forest segregation and one-way trust in Technet. Below is an extract:

In a domain environment, if Active Directory Domain Services (AD DS) is compromised for example by an internal attack, the firewall could also be compromised because a user with Domain Administrator rights can administer every domain member, including the server running Forefront TMG. Similarly, if the firewall is compromised, the domain in which Forefront TMG is located is also at risk. By default, the Domain Admins group is in the Administrators group on the Forefront TMG server.

At the edge, you can install Forefront TMG as a domain member or in workgroup mode. As a domain member, it is recommended that you install Forefront TMG in a separate forest (rather than in the internal forest of your corporate network), with a one-way trust to the corporate forest. This may prevent the internal forest from being compromised, even if an attack is mounted on the forest of the Forefront TMG computer. However, there are some limitations with this deployment; for example, you can configure client certificate authentication only for users defined in the Forefront TMG domain, and not for users in the corporate internal domain or forest.

Monday, November 29, 2010

RADIUS and VRF

In my earlier post "Setting up RADIUS authentication for Cisco devices", there is a set of example Cisco IOS commands to define the RADIUS server for Cisco authentication. However, it can't work if you apply VRF, even if you use the "ip radius source-interface" command.

If you have Cisco devices using Multi-VRF and/or MPLS related commands, you have to define "aaa group server" instead. Other advantages include server load-balancing and grouping them for different purposes, such dot1x and login etc. Below are the example commands.

(config)# aaa authentication login NetworkLogin group NetworkRadius local
! group up the servers
(config)# aaa group server radius NetworkRadius
(config-sg-radius)# server 1.1.1.1 auth-port 1812 acct-port 1813

! define VRF and source interface
(config-sg-radius)# ip vrf forwarding YOUR_VRF
(config-sg-radius)# ip radius source-interface Loopback 0
! define the radius server
(config)# radius-server host 1.1.1.1 auth-port 1812 acct-port 1813 timeout 5 key ****
! apply the RADIUS authentication list
(config)# line vty 0 4
(config-line)# login authentication NetworkLogin

To verify the configuration, do "show radius server-group all" on the exec mode.

Tuesday, November 16, 2010

RADIUS Shared Key Template

In one of the comments in my earlier post "Setting up RADIUS authentication for Cisco devices", someone asked whether he should have all network devices having different radius keys. Don't get it wrong, this is the shared key between the RADIUS server and the client (e.g. Cisco or other network security devices), which is a RADIUS requirement. We are not referring to the individual user credential used to gain administrative access into the Cisco devices or the network resources. Note that the same RADIUS protocol is also commonly used for other applications, such IEEE 802.1x, WPA2, remote dial-in etc. These applications would also face similar issue of having shared secret between the security device and the RADIUS server. See this RADIUS overview on Wiki.

I felt that might poised another more serious security issue. Imagine there can be hundreds of devices under his care, what if he lost or accidentally leaked that long password list?

To strike a good balance between manageability and security, I would advise that those less critical devices can share a common key while applying another common key for more sensitive/critical devices (fewer in number). For highly sensitive/critical devices, a unique key may be applied.

Fortunately, Microsoft RADIUS or the Network Policy Server (NPS) in Windows 2008 R2 provides shared secret template feature to facilitate that. A group of devices belonging to similar security level can share a common shared secret template.

To create a new template, open up NPS server console, expand on "Template Management", right-click on "Shared Secret" and add "New". A small windows would pop up:



Give it a name and add in the shared secret. Click "Ok". On the properties of RADIUS client, select the relevant template on the drop-down box.

Wednesday, August 18, 2010

Setting up RADIUS authentication for Cisco devices

I know this is not new but would like to elaborate slightly further for my team. The "Network Policy Server" in Windows 2008 can serve as a central AAA mechanism for all Cisco logins. Furthermore, each network administrator can login using their individual credential (which is AD-integrated) instead of sharing a common set of local passwords, which is an administrative nightmare if these passwords are compromised.

This blog explained the initial setup. To continue adding more RADIUS client (i.e. Cisco devices), log on to the NPS server and fire up the Network Policy Server console.

1) Add RADIUS client
Right click on RADIUS client and click "New". Enter the name of device and the IP address. As a Cisco device may have multiple interfaces, I would prefer using the loopback address. Also, supply the pre-shared key between the server and the client.


Note: Both IP addresses and the key must match. If not, authentication would fail.

2) Cisco Configuration
Cautious: Make sure you have another running line or console before you do this.

aaa new-model
#use radius login 1st. when time-out, use local password
#you may want to define your own list. Make sure the list in red must match the login vty below
aaa authentication login RadiusList group radius local
#make sure it matches the client IP address in the NAP server earlier
ip radius source-interface Loopback0
#replace the below brackets with your values
radius-server host [server_IP] auth-port 1812 acct-port 1813 timeout 5 key [your_key]

#apply authentication method
line vty 0 4
access-class MGMT_ACL in
logging synchronous
login authentication RadiusList
transport input ssh

3) Verifying & Troubleshooting
Try ssh into the device. If unsuccessful, check network connectivity from the client using "ping [server_IP] source loopback0". Run "debug radius" command and go to the event viewer of the server. For easy viewing, open up the Server Manager console and click on the "Network Policy Manager" where the login events are filtered automatically for you.

4) Change the prompt (Optional)
How do you know which are the devices use RADIUS or local authentication? Simple, just change the login & password prompts.

aaa authentication banner ^CAccess to this device is protected by NAP^C
aaa authentication password-prompt "NAP password:"
aaa authentication username-prompt "Your NAP id:"

Monday, June 14, 2010

IEEE 802.1AE (a.k.a MACSec)

IEEE 802.1AE Media Access Control Security (MACSec) aims to integrate security protection into wired Ethernet to secure LANs from attacks such as passive wiretapping, masquerading, man-in-the-middle and some denial-of-service attacks.

MACSec helps assure ongoing network operations by identifying unauthorized stations on a LAN and preventing communication from them. It protects control protocols that manage bridged network and other data through cryptography techniques that authenticate data origin, protect message integrity, and provide replay protection and confidentiality. By assuring that a frame comes from the station that claimed to send it, MACSec can mitigate attacks on Layer 2 protocols. The proposed standard safeguards communication between trusted components of the network infrastructure by providing hop-by-hop security. This distinguishes it from IPSec, which protects applications on an end-to-end basis. Network administrators make use of MACSec by configuring a set of network devices to use the protocol.

When a frame arrives at a MACSec station, the MACSec Security Entity (SecY) decrypts the frame if necessary and computes an integrity check value (ICV) on the frame and compares it with the ICV included in the frame. If they match, the station processes the frame as normal. If they do not match, the port handles the frame according to a preset policy, such as discarding it.

802.1AE provides encapsulation and the cryptography framework for Ethernet protection. It requires supporting protocols for key management, authentication and authorization. To meet this need, the IEEE is defining an additional standard, 802.1af MAC Key Security, an extension of 802.1X that manages short-lived session keys used to encode and decode messages. An initial key, or master key, is typically obtained by an external method such as 802.1X and IETF's Extensible Authentication Protocol. A third related protocol under development is 802.1AR, Secure Device Identity, which ensures the identity of the trusted network component.

Currently, Cisco incorporates MACSec as a security feature under the Cisco TrustSec Framework

Reference: http://www.networkworld.com/details/7593.html?def

More about Cisco TrustSec Architecture

Sunday, January 24, 2010

Advanced Persistent Threat

With the recent advent of highly sophisticated attacks on Google and other commercial organisations, there is a new security term in cyber-security that called "Advanced Persistent Threat (APT)".

Look at this definition: source: [mandiant.com]
The Advanced Persistent Threat (APT) is a sophisticated and organized cyber attack to access and steal information from compromised computers. The intruders responsible for the APT attacks target the Defense Industrial Base (DIB), financial industry, manufacturing industry, and research industry. The attacks used by the APT intruders are not very different from any other intruder. The main differentiator is the APT intruder’s perseverance and resources. They have malicious code (malware) that circumvents common safeguards such as anti-virus and they tend to generate more activity than wanton “drive by hacks” on the Internet. The intruders also escalate their tools and techniques as a victim firm’s capability to respond improves. Therefore, the APT attacks present different challenges than addressing common computer security breaches.

Thursday, November 26, 2009

VRF aware Site-to-Site IPSec

Cisco introduced new configuration guidelines for VRF aware IPSec. I spent a day worth and finally got it working. The understanding of Front Door VRF (FVRF) and and Inside VRF (IVRF) is key. Each IPsec tunnel is associated with two VRF domains. The outer encapsulated packet belongs to one VRF domain, which Cisco called it FVRF. The inner & encrypted IP packet belongs to another domain called the IVRF.

Part 1 is the base configuration without any IPSec. I'm using Loopback interface to simulate internal trusted network address (e.g. LAN). GRE tunnel is setup to bridge 2 separate LANs. In part 2, IPSec profile is applied to encrypt GRE tunnel (a.k.a GRE over IPSec).

Part 1 - Base Configuration
hostname Router1
ip vrf FVRF
rd 0:0
!
ip vrf IVRF
rd 1:1
!
interface Loopback0 # internal address
ip vrf forwarding IVRF
ip address 192.168.255.1 255.255.255.255
!
interface Tunnel0
ip vrf forwarding IVRF
ip add 192.168.1.1 255.255.255.252
tunnel source Serial1/0
tunnel destination 192.168.1.2
tunnel vrf FVRF
!
interface Serial1/0
ip vrf forwarding FVRF
ip address 192.168.1.1 255.255.255.252
!
ip route vrf IVRF 192.168.255.2 255.255.255.255 Tunnel0

----
hostname Router2
ip vrf FVRF
rd 0:0
!
ip vrf IVRF
rd 1:1
!
interface Loopback0
ip vrf forwarding IVRF
ip address 192.168.255.2 255.255.255.255
!
interface Tunnel0
ip vrf forwarding IVRF
ip add 192.168.1.2 255.255.255.252
tunnel source Serial1/0
tunnel destination 192.168.1.1
tunnel vrf FVRF
!
interface Serial1/0
ip vrf forwarding FVRF
ip address 192.168.1.2 255.255.255.252
!
ip route vrf IVRF 192.168.255.1 255.255.255.255 Tunnel0

Part 2 - IPSec related crypto configuration
Router1
crypto keyring vpnKey vrf FVRF
pre-shared-key add 192.168.1.2 key vpnkey
no crypto xauth s1/0 #exempt extended authentication for physical interface
!
crypto isakmp policy 1
authentication pre-share
!
crypto isakmp profile isaPro
vrf FVRF
keyring vpnKey
match identity add 192.168.1.2 255.255.255.255 FVRF
!
crypto ipsec transform-set myset esp-des esp-md5-hmac
!
crypto ipsec profile ipsecPro
set transform myset
set isakmp-profile isaPro
!
int Tunnel0
tunnel mode ipsec ipv4 #apply IPSec to protect GRE tunnel
tunnel protection ipsec profile ipsecPro
!
-------

Router2
crypto keyring vpnKey vrf FVRF
pre-shared-key add 192.168.1.1 key vpnkey
!

no crypto xauth s1/0
!
crypto isakmp policy 1
authentication pre-share
!
crypto isakmp profile isaPro
vrf FVRF
keyring vpnKey
match identity add 192.168.1.1 255.255.255.255 FVRF
!
crypto ipsec transform-set myset esp-des esp-md5-hmac
!
crypto ipsec profile ipsecPro
set transform myset
set isakmp-profile isaPro
!
int Tunnel0
tunnel mode ipsec ipv4
tunnel protection ipsec profile ipsecPro



Verification
Router1#ping vrf IVRF 192.168.255.2 source lo0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.255.2, timeout is 2 seconds:
Packet sent with a source address of 192.168.255.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 372/429/512 ms

Router1#sh crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst src state conn-id slot status
192.168.1.1 192.168.1.2 QM_IDLE 1001 0 ACTIVE

IPv6 Crypto ISAKMP SA

Router1#sh crypto session
Crypto session current status

Interface: Tunnel0
Profile: isaPro
Session status: UP-ACTIVE
Peer: 192.168.1.2 port 500
IKE SA: local 192.168.1.1/500 remote 192.168.1.2/500 Active
IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 0.0.0.0/0.0.0.0
Active SAs: 2, origin: crypto map