Hyper-V ConceptsIt's time to get familiar with Hyper-V Virtualization, virtual servers, virtual switches, virtual CPUs, virtual deployment infrastructure (VDI) and more.
This article examines the concept of NAT Reflection, also known as NAT Loopback or Hairpinning, and shows how to configure a Cisco ASA Firewall running ASA version 8.2 and earlier plus ASA version 8.3 and later, to support NAT Reflection. NAT Reflection, is a NAT technique used when devices on the internal network (LAN) need to access a server located in a DMZ zone using its public IP address.
What’s interesting is that NAT Reflection is not supported by all firewall appliances, however Cisco ASA Firewalls provide 100% support, making any NAT scenario possible. NAT Reflection is also seen at implementations of Cisco’s Telepresence systems where the ExpressWay-C server on the internal network needs to communicate with the ExpressWay-E server in the DMZ zone using its public IP address.
In the example below, ExpressWay-C with IP address 192.168.1.50 needs to access ExpressWay-E (DMZ zone, IP address 192.168.5.5) using its public IP address of 22.214.171.124. This type of setup also happens to be one of the two most popular configurations:
Figure 1. NAT Reflection on a 3-Port ASA Firewall with Cisco Telepresence (ExpressWay-C & ExpressWay-E)
ExpressWay-C packets traversing the ASA Firewall destined to ExpressWay-E’s public IP address will have the following transformation thanks to the NAT Reflection configuration:
When ExpressWay-C packets arrive to the ExpressWay-E server, they will have the following source & destination IP address: Source IP: 192.168.5.1, Destination IP: 192.168.5.5
Translation of the source IP address (SNAT) of packets (192.168.1.50 to 192.168.5.1) for this traffic flow is optional however required specifically for the Cisco ExpressWay setup. The configuration commands for the above setup is as follows:
For ASA Versions 8.3 and later:
This article examines the differences between logical and technical web application vulnerabilities which tends to be a very confusing topic especially for web application developers and security – penetration experts because it would make sense that a vulnerability by any other name is simply confusing something that should be simple.
However, there are significant differences between technical and logical vulnerabilities which are critically important — especially if you are developing or penetration testing a web application.
Automated web application security scanners are indispensable when it comes to scanning for potential vulnerabilities. Web applications today have become complicated the point where trying to eliminate all vulnerabilities manually is nothing short of foolish. The task is too large to even attempt. And, even if you did, you are likely to miss far too many as a result of human error.
Don’t let that lead you to believe that humans have no place in the process. While computers are indispensable in their ability to tirelessly scan for technical vulnerabilities, humans have the unique ability to not only think logically, but also analytically.
As a result, we still play a critical role in the process of identifying vulnerabilities in websites and web applications and will likely do so for some time to come.
But what is the difference between logical and technical vulnerabilities? And where should humans intervene in the detection process? To understand this, let’s take a closer look at the difference between the two.
Free Website / Webserver Scanning for Exploits & Security Issues - Netsparker Cloud - No Install Necessary - Try it Now!
Technical vulnerabilities is an area where automated scanners excel — it is a rule-based process. It is also time intensive, because of the vast number of attack vectors and potential vulnerabilities. For a human to complete this process, while possible, would be extremely expensive and likely full of both false-positives and false-negatives.
A common example of a technical vulnerability (for example SQL Injection) would be an application that requires information to be submitted by a user through a form. Any data submitted needs to be properly sanitized and failure to do so could make your application vulnerable to attack.
Testing for this is a simple task. For example, a hacker could probe for a vulnerability by submitting an email address with a single quotation at the end of the text. The response they receive might indicate the presence of a vulnerability.
This article is the second-part of our Palo Alto Networks Firewall technical articles. Our previous article was introduction to Palo Alto Networks Firewall appliances and technical specifications, while this article covers basic IP management interface configuration, DNS, NTP and other services plus account password modification and appliance registration and activation.
The introduction of Next Generation Firewalls has changed the dimension of management and configuration of firewalls, most of the well-known Firewall vendors have done a major revamp, be it the traditional command line mode or the GUI mode.
Palo Alto Networks is no different to many of those vendors, yet it is unique in terms of its WebUI. It’s a whole new experience when you access the WebUI of Palo Alto Networks Next-Generation Firewalls.
In order to start with an implementation of the Palo Alto Networks Next-Generation Firewalls one needs to configure them. Palo Alto Networks Next-Generation Firewalls can be accessed by either an out-of-band management port labelled as MGT or a Serial Console port (similar to Cisco devices). By using the MGT port, one can separate the management functions of the firewall from the data processing functions. All initial configurations must be performed either on out-of-band management interface or by using a serial console port. The serial port has default values of 9600-N-1 and a standard roll over cable can be used to connect to a serial port.
Figure 1. Palo Alto Networks Firewall PA-5020 Management & Console Port
By default, Palo Alto Networks Next-Generation Firewalls use MGT port to retrieve license information and update the threats and application signature, therefore it is imperative the MGT port has proper DNS settings configured and is able to access the internet.
To access the Palo Alto Networks Firewall for the first time through the MGT port, we need to connect a laptop to the MGT port using a straight-thru Ethernet cable. By default, the web gui interface is accessed through the following IP Address and login credentials (note they are in lower case):
For security reasons it’s always recommended to change the default admin credentials. Until this condition is satisfied, the Palo Alto Networks Firewall alerts the administrator to change the default password every time he logs in, as shown in the screenshot below:
Figure 2. Palo Alto Networks Firewall alerts the administrator to change the default password
Below is a list of the most important initial setup tasks that should be performed on a Palo Alto Networks Firewall regardless of the model:
Let’s take a look at each step in greater detail.
Step 1: Establish connectivity with the Palo Alto Networks Firewall by connecting an Ethernet cable between the Management and the laptop’s Ethernet interface.
Step 2: Configure the laptop Ethernet interface with an IP address within the 192.168.1.0/24 network. Keep in mind that we’ll find the Palo Alto Networks Firewall at 192.168.1.1 so this IP must not be used.
Step 3: Open a web browser and navigate to the URL https://192.168.1.1 – Take note that this is an HTTPS site. At this point the Palo Alto Networks Firewall login page appears.
Step 4: Enter admin for both name and password fields.
Step 5: From the main menu, click Device > Administrators > admin
At this point we have connectivity to the Palo Alto Networks Firewall and need to change the management IP address:
Part 4 of our OSPF Routing Protocol Series covers how OSPF uses Link State Advertisement (LSA) to exchange information about the network topology between routers. When a router receives an LSA, it is stored in the Link-State DataBase (LSDB). Once the LSDBs between routers are in sync, OSPF uses the Shortest Path First (SPF) algorithm to calculate the best routes for each network. It is important to understand that LSAs are information about a route that is transported inside Link State Update (LSU) packets.
Each single Link State Update (LSU) packet can contain one or more LSAs inside it and when an LSU is sent between OSPF routers, it floods the LSA information through the network.
It is very important for any network engineer to understand how LSAs are contained within an LSU. We’ll use the example below, where an OSPF router sends an LSU to the OSPF Designated Router (DR) containing LSA information about a new network:
Figure 1. OSPF Link State Multicast Update (LSU) packet containing a Link State Advertisement (LSA)
As shown above, LSAs are contained within LSUs, which are all part of an OSPF packet encapsulated within an Ethernet frame (assuming an Ethernet network).
Our diagram of the LSU/LSA packet structure is confirmed by capturing an OSPF Ethernet frame below. We’ve highlighted each section (LSA, LSU, OSPF Header) using the same colors:
Figure 2. OSPF Link State Update and List State Advertisement within an Ethernet frame
Notice that the destination IP address is multicast address 126.96.36.199, as expected since routers send updates to the Designated Router (DR) using this multicast address. This is also analyzed under the Working Inside a Single Area section in our article How OSPF Protocol Works & Basic Concepts: OSPF Neighbor, Topology & Routing Table, OSPF Areas & Router Roles, Theory & Overview
OSPF currently defines 11 different LSA types, however, despite the large variety of LSAs only around half of them are commonly found in OSPF networks. Table 1 below shows the most popular LSA types, the type of OSPF routers (DR, ABR, ASBR etc) that generate them along with their function and the OSPF areas they affect:
Monitoring, Auditing and obtaining Security Alerts for websites and blogs based on popular CMS systems such as WordPress, has become a necessity. Bugs, security exploits and security holes are being continuously discovered for every WordPress version making monitoring and auditing a high security priority. In addition, multi-user environments are often used for large WordPress websites, making it equally important to monitor WordPress user activity.
Users with different privileges can login to the website’s admin pages and publish content, install a plugin to add new functionality to the website, or change a WordPress theme to change the look and feel of the website. From the admin pages of WordPress users can do anything, including taking down the website for maintenance, depending on their privileges.
Every type of multi-user software keeps an audit trail that records all user activity on the system. And, since modern business websites have become fully blown multi-user web applications, keeping a WordPress audit trail is a critical and must do task. A default installation of WordPress does not have an audit trail, but the good news is that there are plugins such as WP Security Audit Log that allow you to keep an audit trial of everything that is happening on your WordPress.
Figure 1. Plugins like WP Security Audit Log provide detail tracking of all necessary events (click to enlarge)
There are several advantages to keeping track of all the changes that take place on your WordPress website in an audit trail. Here are just a few:
By keeping a WordPress audit trail you can find out who did what on your WordPress website. For example; who published an article, or modified existing and already published content of an article or a page, installed a plugin, changed the theme or modified the source code of a file.