Steven M. Jordan

Showing posts with label CISCO. Show all posts

Problem: JUNOS DNS-Proxy resolution does not work over the VPN.

Symptoms:

DNS name resolution only resolves external domain names (i.e. Internet).
SRX DNS proxy does not resolve internal/ local domains from DNS server on other side of the VPN..
Ping requests fail from the SRX (i.e., DNS-Proxy) to the remote VPN site.
For Example, SRX2 cannot ping any node behind SRX1 via VPN.
All ping requests from the SRX fail without specifying exit interface.
Ping request from nodes on either side of the VPN are successful. Routing and VPN work.

Topology: The DNS proxy and DNS server are on separate sides of the VPN.

SRX1 is at the data center. Its site hosts the primary domain controller (DC) and DNS servers.
SRX2 is at the branch office.
The SRX2 site does not have a local DC or DNS server. It uses a split-tunnel VPN and split-brain DNS proxy for internal and external name resolution

Solution: Assume routing, DNS-Proxy and firewall configurations are OK. The problem is with how the SRX chooses its default address. Specify the default address for s should fix the problem:


set system default-address-selection

Next, assign the loopback interface with a routed IP address.


set interface lo0 unti 0 family inet address

N.B., Planning to use the DNS proxy with an public DNS server (e.g., 8.8.8.8)? Don't forget to create a corresponding NAT statement:

[edit security nat]


 rule-set self-internet {

                from zone junos-host;

                to zone UNTRUST;

                rule RE-untrust {

                    match {
                        source-address 0.0.0.0/0;

                    }

                    then {

                        source-nat {

                            interface;

Reason: The DNS proxy service uses the SRX loopback interface (lo0) for its source address. The default lo0 addess is 127.0.0.1. Traffic isn't going to go far with that address! Everything works if you assign lo0 with an IP address from your default VLAN!

N.B., This fixes all other issues with ICMP, FTP, etc., across the SRX to VPN as well.

References:

https://www.juniper.net/documentation/en_US/junos13.1/topics/reference/configuration-statement/default-address-selection-edit-system.html

Wireless Threat Detection and Countermeasures: Monitor and Protect Your Wireless Access Points.

Takeaway: Automated countermeasures discover, attack, and disable rouge Wi-Fi devices! This article explores Wireless Access Controllers, Intrusion Detection Systems (IDS), and Intrusion Prevention Systems (IPS). These instructions explain how to enable countermeasures for Juniper Wireless Controllers (WLCs). Cisco, Aruba, and other controllers offer similar mitigation.

Problem: Corporate networks are vulnerable to rouge wireless technology. Wireless access points (WAPs), wireless routers, and wireless bridges can extend the corporate network and provide an insecure entry point. Untrusted wireless technology risks data integrity and confidentiality.

Internal and External Rouge Wireless Threats.

Threats: Internal threats include unapproved wireless devices that extends or bridges the corporate network. For example, an employee may install a residential WiFi router to provide network access to their smartphone. Their intent may not be malicious but it nonetheless exposes the network to compromise.

Hackers or wireless devices in proximity to corporate access points are external threats. External threats can intercept and harm company data. Additional threats can entirely disrupt wireless communication (Table 1).

Enable Countermeasures: The WLC includes countermeasures that attack rouge devices. These countermeasures consist of packets that disrupt client communications to rouge devices. Rouge devices are rendered useless once the WLA initiates an attack. WLC countermeasures are disabled by default. Enable countermeasures on all rouge devices:

LocalWLC#set radio-profile default countermeasures rogue
Alternately, enable countermeasures on all rouge and interfering devices:

LocalWLC#set radio-profile default countermeasures all

Enable ad-hoc countermeasures if desired:

LocalWLC#set rfdetect classification ad-hoc rogue

Configure SSID list to whitelist existing SSIDs:

LocalWLC#set rfdetect ssid-list BIZ_SSID
Enable log messages to display on console:

LocalWLC#set rfdetect log enable
N.B., Interfering devices may include neighboring APs using the same radio channels. The WLC includes RF Auto-Tuning that changes WLA channels as needed. Consider rouge-only countermeasures when located near other businesses.

Rouge Classifications: The WLC identifies all nearby 802.11 wireless devices. It uses a classification system to detect rouge devices:


LocalWLC# sh rfdetect classification

User

Rule       Rules for RF Classification                                 Classification

----     ---------------------------                                  --------------

N         1. If AP in Rogue list  ....................... ROGUE

N         2. If AP is part of Mobility Domain  .......... MEMBER

N         3. If AP in Neighbor list  .................... NEIGHBOR
-------------------------------------------------------------------

Y      4. If AP is Masquerading our SSID  ............ ROGUE

Y         5. Client or Client DST MAC seen in network  .. ROGUE

Y        6. If AP is acting as an Ad-hoc device  ....... SKIP-TEST
-------------------------------------------------------------------

N         7. If SSID is in SSID list  ................... NEIGHBOR
-------------------------------------------------------------------

Y         8. Default Classification  .................... SUSPECT

Rouge List: The WLC attacks all devices in the Rouge list. The WLA does not transmit client traffic while it attacks rouge devices. WLAs can be provisioned in Sentry mode for dedicated scanning and attacking purposes.

Suspect List: Devices in the Suspect list are considered potential Rouges. The WLC does not attack suspect devices unless they become a threat. In most circumstances, suspect devices are neighbor APs which have not been manually added to the Neighbor list.

Neighbor List: The Neighbor list acts as a whitelist. The WLC does not attack its neighbors. Be a good Samaritan and add your neighbors' APs to the Neighbor list. The Juniper WLC GUI makes identifying and adding neighbors a cinch.

Juniper WLC GUI: RF Neighbors

Countermeasures in Action: What happens if an employee connects a wireless AP to the corporate network? For this example, assume the switch access ports are not configured for 802.1X authentication or BPDU Guard.

1. Employee discretely connects a Linksys wireless router to the network.

Employee adds unapproved wireless access point to company network.

2. The Linksys router connects to the company network and advertises its SSID:

3. The Linksys SSID remains in the Suspect list as long as clients are not connected it.

4. The employee connects their laptop to the Linksys SSID. The WLC immediately identifies the Linksys AP as a rouge device:

ROGUE Sep 24 11:11:26.009242 NOTICE ROGUE_AP_ALERT: Client Mac 88:XX:XX:XX:XX:XX(Rogue AP Mac 00:XX:XX:XX:XX:XX) is seen on the wired network by Switch 172.16.1.2 on port X vlan X tag 0. Detected by listener a8:XX:XX:XX:XX:XX(AP 1, radio 1), channel 6 with RSSI -55 SSID "linksys".

5. The WLC begins its countermeasure attack:

ROGUE Sep 24 11:12:35.065652 NOTICE ROGUE_AP_ALERT: COUNTERMEASURES STARTED for Xmtr Mac 00:XX:XX:XX:XX:XX Performer Mac a8:XX:XX:XX:XX:XX SW-I Paddr 172.16.1.2 AP 1 Radio 1 Channel 6

6. Confirm countermeasures:

WLC# sh rfdetect countermeasures
Total number of entries:1

          Type(Adhoc/Infra) Countermeasures                        Port/Radio

Rogue MAC         /Class    Radio Mac        RSSI MX IPaddr                  /Channel
----------------- -------- ----------------- ---- --------------- ------------
00:XX:XX:XX:XX:XX I/rogue  a8:XX:XX:XX:XX:XX -59  172.16.1.2           AP 1/1/6

WLC Detected a Rouge SSID

Conclusion: Tests confirm wireless clients cannot connect to rouge SSIDs when WLC countermeasures are enabled. Interestingly, the WLC countermeasures are similar to those available on some WiFi hacking tools. These countermeasures compliment existing mitigation strategies; Enterprise WPA2, 802.1X authentication; BYOD Policy, client and server certificate authentication; disabling client auto-connect; Windows IPSec, etc...

Table 1. Wireless Threats and Mitigation.

Threat	Type of Attack	Purpose	Mitigation
RF Jamming	DoS - Flooding	Overwhelms WLAN with high-power noise.	WLA detects excessive interference on a channel. WLC Auto-Tuning changes the radio to a different channel.
De-authenticate frames	DoS Precursor to Identity Spoofing	Basis for man-in-the-middle attacks. Spoofing changes source MAC so frames appear to come from a legitimate AP.	WLA checks packets for the source MAC address.
Broadcast De-authenticate Frames	DoS Precursor to Identity Spoofing	Spoofs de-authenticate frames to disconnect all clients attached to an AP.	WLA checks for de-authenticate broadcast frames.
Disassociation frames	DoS Precursor to Identity Spoofing	Disassociation frames from an AP instructs clients to end their association to AP.	WLA checks for disassociation frames
Null probe response	DoS	Rogue devices send probe response with null SSID. NICs can lock up upon null probe responses.	WLA checks for Null probe responses.
Decrypt Errors	Identity Spoofing	Rogue device pretends to be a legitimate device by spoofing the MAC address.	WLA checks for excessive number of decrypt errors. This indicates multiple clients are using the same MAC address.
Fake APs	DoS	Rouge device sends beacon frames for excessive SSIDs or BSSIDs. Clients cannot connect to valid Aps.	WLA check for excessive beacon frames.
Fake SSIDs	Identity Spoofing -MITM	Rouge device pretends to be a legitimate SSID in your network. Clients associate with rouge SSID.	WLA checks for APs masquerading as company SSID.
Spoofed WAPs	Identity Spoofing -MITM	Rouge device pretends to be legitimate AP by changing its MAC source address.	WLC detects spoofed AP attacks based on AP fingerprint. WLA signatures must be enabled to detect AP spoofing.
Netstumbler and Wellenreiter	Reconnaissance	Hacker applications gather information about APs, location, manufacturer, and encryption.	WLC syslog warnings identify Netstumbler and Wellenreiter.
Wireless Bridge	Identity Spoofing	Extends network to personal or rouge devices.	WLA identifies internal wireless bridges.
Ad-Hoc Networks	Identity Spoofing	Client Wireless NICs extend network to personal or rouge devices.	WLA identifies internal Ad-Hoc Networks.
Weak WEP Keys	Brute Force Vulnerability	Network systems vulnerable to attacks.	WLC syslog warnings identify clients using weak WEP.

Note: IDS console messaging and SNMP alerts are additional mitigation features. WLAs are configured to actively scan for threats (i.e. Active Scan) by default.

Table 2. Rouge Determination

Wireless AP, bridge, or ad-hoc Network	Yes	No
Does the device have a known MAC address from the wired network?	Rouge	Suspect
Does the destination header contain a known MAC from the wire network?	Rouge	Suspect
Does the SSID belong to the SSID list?	Member	Rouge
Is the device use a Juniper transmitter?	Suspect	Rouge
Does the client or AP MAC address on the blacklist?	Rouge	Suspect
Does the client or AP MAC address belong to the Rouge list?	Rouge	Suspect
Does the client or AP MAC address belong to the Neighbor list?	Neighbor	Suspect

References: Juniper Mobility System Software Configuration Guide

Artifact: Demonstrate the value of ICT methodology.
By Steven Jordan on 11/26/2013.

Abstract: This document identifies a BGP routing problem that resulted in unstable peering relationships, routing instability, and excessive route flaps. The document also serves as an artifact to demonstrate the value of ICT methodology.

Background: Customers, all from the same organization, complained of poor web site usability. Symptoms of the problem were described as slow loading web pages, limited functionality, and an excessive delay of data enumeration. To be clear, the problem only affected this particular organization.

Solution: Troubleshooting, using ICT methodology, identified a problem at the customer's location. I sent the following email that outlined the resolution process:

Dear Kathy,

It was a pleasure speaking with you on the telephone. I wish it were under better circumstances. I am writing to outline the network problem that prevents staff at your location from connecting to our network.

My research indicates there may be a problem with your organization’s local Internet connection and related routing issues. There are two influencing factors:

1. Network tests sourced from your organization indicate packet loss; well before traffic reaches our servers. The problem may be sourced from your organization or from an upstream ISP.

· A ping test measured bits of data sent and received from your location to our hosted web site. We found approximately 25% of the data was dropped en route.

· A trace route documented the path the packet traveled across the Internet. We found there were over 10 separate network hops from your organization to our servers (not unusual). Each “hop” represents a different Internet Service Provider (ISP) router.

· A separate PING test to each hop indicated that 25% of the data was lost. We are reasonably certain that 25% of all data sent from your location is lost; from at least the CenturyLink/Quest hop. Our server farm is located several hops upstream from the Quest network.

2. There may be BGP routing problems with your organization's network. There were multiple BGP route announcements sourced from your network today.

The Internet uses a routing protocol called Boarder Gateway Protocol (BGP). Your organization uses BGP to host a single IP subnet with multiple ISPs. If the primary ISP is unavailable the network will failover to the secondary ISP, while still using the same IP subnet.

I determined there were hundreds of route updates and withdraws that continued up until 6/30/2013 at 3:21:PM PST. The following graph is a snap shot of the multiple paths to your organization’s network from external ISPs:

There were excessive route flaps and instability during this time-frame. I suspect there are still unintended BGP peering relationships to your organization’s network. Multiple inbound paths from different ISPs may cause data loss. I cannot provide further details because I am not familiar your organization’s private network. I can confirm that the problem is severe enough to interfere with our service. Unless the problem is resolved, your staff will begin to notice issues from other web sites as well.

Earlier today, I spoke with Bob from your IT department’s help desk. Bob was very helpful as he assisted with some of the network tests. It is my understanding that Bob planned to escalate the issue based on the ping and trace route tests. I also encourage you to forward this email to the appropriate network department to assist the escalation process. Re-announcing the BGP routes to upstream ISPs should resolve the network instability.

Please contact me with any questions. This issue is important to me and I will do whatever I can to help make our service accessible to your staff. Please call my cell phone any time this evening if I can be of assistance.

Sincerely,

Steven M. Jordan

Network Administrator

Disable Juniper Ports

Problem:

Solution:

Clear BGP Sessions

Problem:

Solution:

Command:

Juniper SRX DNS Proxy Issues Over the VPN

Prevent Rouge Access Points: Wireless IDS/ IPS

Wireless Threat Detection and Countermeasures: Monitor and Protect Your Wireless Access Points.

BGP Troubleshooting Artifact

My Instagram