Tag Archives: IPv4

Infamous IP Address Resurfaces

A couple of days ago researchers over at Sucuri posted a blog, detailing some investigative work on suspicious redirects which turned out to be the result of NameCheaps Free DNS service.

I won’t cover the detail of the blog (go read it, its a great piece of work) but one of the most surprising and interesting things (to me at least) uncovered was the resurrection of an IP related to the prehistoric and infamous conficker virus’s C2 domains.

So it just goes to show that I’m not the only person in security that like to pay homage to the past, even if I do it in a slightly less conspicuous fashion.

IPv4 Threat Intelligence – PowerShell Script

Following on from by previous post about gathering IPv4 threat intelligence automatically with Python scripts I thought I would follow it up with a PowerShell script I wrote that does something similar.

This script will work on Windows without the need for any extra installs, so it is perfect for users that only have access to Windows in the workplace.

It is often the case that security analysts and sys-admins need to grab bulk lists of IPv4 addresses from a data source, this data source can be logs, websites and intelligence feeds. Data sources such as these can contain lots of redundant data, such as domain names, time stamps etc. etc. In general removing this data can be done simply with a script and this is exactly what that script does.

I have seen a few scripts kicking about that do something similar to this, but they generally contain way more lines of code than is needed (although this does have some ASCII art of cats and dogs that really doesn’t need to be there) as well as requiring some kind of user input. This script is very tight with the code and the only user input required is dragging the input file over to the scripts directory.

This script allows you to take the data source in the form of a file and automatically convert it to a .csv of IPv4 addresses, fully de-deduped and with all redundant removed, ready to be used for whatever purpose you have in mind for it.

The Script is quite raw at the moment, so you will need to make a couple of edits to tailor it to your environment. See below for the bits that you may wish to edit:

  • Put the script in you documents folder as such $home\Documents\ipv4\
  • The file you want to run the script on will need to be dumped in the same folder
  • The ipv4_* wildcard is used to detect the input file
  • Follow this guide if you want to run the PowerShell script with a simple double click of a batch script

I have a script very similar to this that does the same thing, but grabs the input data from the web (similar to the python scripts, but in PowerShell), I will post this in the next few days.

Find the script here on GitHub

Automatically gather IPv4 Threat Intelligence

To paraphrase Sun Tzu “Know your enemy as you know yourself”. Yes I know this is used in security ad nauseam and I profusely apologise for rolling out this tired old cliché, but as is often true, within the cliché lies the truth, and Sun Tzus famous quote is no different.

Collecting threat intelligence on the enemy (or possible enemy) and feeding it into your tool set can help you watch and protect against interactions with online addresses that could pose a threat to your environment.

There are a number of online resources that provide this intelligence for free, but collecting it and formatting it into a .CSV file ready for direct import into your tools file can be cumbersome if it is not automated.

Tools such as SIEM’s can take lists of IPv4 addresses directly from a .CSV file and use them to test rules against or build reports on.

Example use cases are amongst others; IP reputation lists to flag up whenever your environment attempts to interact with IP’s with a poor reputation, IP’s known to host Malware, known c2 servers or any interaction with a TOR exit node.

To this end I have written a Python script, that will automatically grab the latest threat intel from a few sites. The script is pretty straight forward and can be easily edited to grab lists of IPv4 addresses from whatever site you want.

The tor exit node list updates quite often, it is probably better to schedule a cron job to automatically update that list, I will post a dedicated script for this and any other use cases that spring to mind in the future, as well as PowerShell scripts for Windows users that do not want to install Python.

Couple of notes on these scripts:

  • The Linux script runs on Python 2.7 as this is the version most commonly pre-installed on Linux distros.
  • The linux script uses raw_input instead of input as input contains an eval function hiding behind it which may lead to a possible code injection vulnerabilities when used in python 2.7.
  • The Windows script uses Python 3 as most windows users will need to manually install Python and it makes sense for them to use the most recent version.
  • The Windows script uses input as Python 3 does not have the same code injection vulnerability risk

Linux, Python 2.7 script. GitHub.

Windows, Python 3 script. GitHub

Mobile IPv6 Part 1

Mobility in IPv6

One of my favourite protocols is IPv6, this post is going to be part of a three part series covering IPv6 or more specifically: Mobility in IPv6. For me IPv6 is the hero of the network layer protocols, and will soon become the main network protocol of the internet. IPv6 was developed by the Internet Engineering Task Force and had its specification laid out in RFC 2460. This new version of the IP protocol was designed to make up for the folly of IPv4, whose finite number of addresses are all but completely exhausted. IPv6 addresses are of course also finite, but the amount of them is significantly greater than IPv4, there are so many IPv6 address that it is anticipated that we may never run out of them. If you want to find out how many IPv6 addresses there are exactly and compare the amount with the total number of IPv4 address, then have a look here.

IPv6 didn’t just bring extra addressing capacity, it also brought along a number of other improvements including a simplified header, security improvements, improved support for extensions and options.

In an earlier post I talked about IPv6 and how to enable and use it with common enterprise network technologies such as address allocation, DNS, email, web services and printing, if you want to get an overview of IPv6 and some of its uses then go and have a read here.

In this post I am going to concentrate on how IPv6 fits in with today’s mobile world, a world where nodes can be anything from mobile phones, vehicles, sensors and many other wide and varying devices from the common to the uncommon, from the normal to the bizarre, this mobile world and its vast array of devices are part of what is colloquially known as the Internet of Things.

It can be argued that the Internet of Things is merely just the internet, or more precisely the extension of the internet to more than just fixed stationary networks with fixed stationary nodes such as PC’s, servers or printers. Traversing the internet today is data traveling from a range of mobile devices, probably the most visible being smartphones connected via technologies such as Wi-Fi and a range of mobile data networks run by the telecommunication companies plus various other types of network that support mobile nodes. The amount of mobile devices on the internet is far from saturation point, in the coming years we will see an increase of the amount of nodes transmitting and receiving data while on the move.

This post, and the following parts are going to talk about Mobile IPv6 and a selection of the protocols that extend and support it. Before we get on to Mobile IPv6, let’s have a look at its predecessor, Mobile IPv4.

Mobile IPv4

When IP protocols where developed they were designed to operate over wired media, although IP protocols are technically media independent, the addressing structure of the IP protocols was designed with fixed networks in mind, Stationary local networks with stationary nodes, and stationary wide area networks with stationary nodes. The system worked well, each network would have a fixed prefix and each node on the network would have a unique address from the range of the prefix. Around the last fifteen years of the 20th century however things began to change, wireless media was fast becoming a practical alternative to its wired cousins.

The network was evolving, and the IP protocols had to evolve with it. In 2002 in the Internet Engineering Task Force’s (IETF) RFC 3344, the specification for IP mobility support for IPv4 was laid out, it described a process of allowing an IPv4 node to travel from one network to another while being able to manage the mobility of the node and how a node would be handed off from one network to another all while maintaining a connection with a Corresponding Node (CN). This was revised and improved in RFC 5944. This specification allowed for location independent routing of IP packets on the internet to a roaming Mobile Node (MN), it introduced the Home Addresses (HoA) and Care of Address (CoA), in simple terms the HoA would deal with the end to end communication and the CoA would deal with the routing the data to and from the MN. The basic premise being that a node was issued with an IPv4 HoA by a Home Agent (HA), when a node roams into a foreign network, it sends out a solicitation message looking for a Foreign Agent (FA). The FA replies to the solicitation message with a solicitation advertisement, when this is accepted the node is issued with a second IPv4 address from the FA, this second address is the CoA.

So now the node is in a foreign network with two IPv4 address, a HoA and a CoA, the next step is to send a RegReq (Registration Request) message to its HA, when the HA receives this request it replies with a RegReply (Registration Reply) message. Once this process is done the two addresses are linked on the HA. So now this is all in place, the MN is able to communicate with other devices on the internet. Let’s say there is a PC wanting to send data to the MN. How exactly would it find the mobile device? OK so we have two devices, a mobile phone roaming around, this is our MN and our other device is a PC, this is our CN. When the PC sends data, it sends it to the HA, the HA looks up its database to see what addresses it has linked with MN’s HoA and then forwards the data through a tunnel to CoA, delivering the data to the MN. When the MN wants to reply this process is reversed. So far so good, but this process is designed to work with IPv4, and as we already know, IPv4 is no longer a viable addressing scheme for the long term sustainability of the internet.

Mobility Support in IPv6

IPv6 also requires mobility, and has its own set of extensions and support protocols that allow the saviour of the internet to be mobile, fast and efficient. In this section I begin to cover them. Let’s start with mobility management.

Mobility Management

The role of mobility management is to locate the MN and maintain connection to them during the handover from one network to the other. Different systems, such as Wi-Fi or the Telecommunication Networks like GSM, 3G, 4g etcetera, use different mobility management schemes. They can be broken down into two broad groups. The first is horizontal mobility, this is intra-system mobility, dealing with handoffs in a homogenous system, the other is vertical mobility, intra-system mobility with handovers taking place between two heterogeneous systems. Horizontal mobility can have a lot of the work placed on layer 2 protocols such as Stream Control Transmission Protocol (SCTP). Vertical mobility in many cases however relies on layer 3 IP protocols, although higher level protocols such as Session Initiation Protocol (SIP) can be used in some scenarios. It is in layer 3 of the TCP/IP protocol stack that we will find the Mobile IPv6 family of protocols.

Mobile IPv6

Mobility in IPv6 works differently from mobility in IPv4, it replaces the Agent advertisement with IPv6’s Neighbour Discovery function and there is no longer the requirement for a FA. Address allocation similarly uses IPv6’s build in ability to auto configure, although a DHCPv6 server can also be used. The RegReq and RegReply messages are gone, replaced with Binding Updates (BU) and Binding Acknowledgements (BA).

So how do all these differences change the way IPv6 works?…I thought you would never ask.

A mobile node is powered on, ready for a day exploring the big bad world, its first port of call is to acquire an address, as I said before two methods for this are via auto-configuration or via a DHCPv6 server. If you would like to read about that process in more detail have look at this blog post I posted a while ago.

Once our MN has a topologically correct IPv6 address it is ready to start communicating with other nodes, this address is the HoA. But when the device wants to leave its home network and travels into a foreign network, mobility is required. When the device enters a foreign network it will configure a second topologically correct address for the foreign network, in the same way it did for its HoA. This new address is the CoA, the node now needs to bind these two addresses together on the HA, an agent that belongs to the nodes original network. The node sends a BU to the home agent, the HA then performs Duplicate Address Detection (DAD), if there is no duplicate address the HA binds the HoA and the CoA in its database and replies to the node with a BA.

Now when a CN wants to send data to the MN it will do so in keeping with the IPv6 protocol it will encapsulate the packets within a IPv6 header. The source address for these packets will belong to itself, but the destination address will not be the nodes address but the address of the HA. When the HA receives these packets they are then encapsulated with an additional IPv6 header, in this second, outer layer the source address belongs to the HA and the destination address is the MN’s CoA, the packets are then routed directly to the MN. When the MN receives these packets it first decapsulates the outer IPv6 header, then the inner IPv6 header, this makes the entire mobility scheme completely transparent to the upper layer applications, allowing them to have a conversation with the CN as if the mobility didn’t exist.

That will do it for part one, here we have covered the basics of mobility in both IPv4 and IPv6, in part two we will delve into Mobility in IPv6 in a little more detail and flesh out the process described above. We will cover Route Optimisation, Hierarchical Mobile IPv6 (HMIPv6) and Fast Handovers for Mobile IPv6 (FMIPv6). In part three we will see Media Independent Handovers (MIH), Network Mobility (NEMO), which provides the mobility not for a single IPv6 node, but for an entire IPv6 Network to become mobile, then Proxy Mobile IPv6 (PMIPv6) will also be discussed, before wrapping up the trilogy of posts about Mobility in IPv6.

See you in Part two.