• No results found

IPv6 Address Policy

3.9 Features Common to Several Commands

3.9.4 IPv6 Address Policy

If the SiLK suite is configured to handle IPv6 records, the processing of all addresses, whether IPv4 or IPv6, is governed by the address policy. This policy affects a variety of commands, including rwcut, rwuniq, rwstats, rwset, and rwbag but does not affect rwfilter (which uses the --ip-version parameter) or commands that process based on their input, such as rwtuc, rwptoflow, rwsetbuild, and rwpmapbuild. There are five options for this policy, as listed in Table3.17and illustrated in Example3.40.

SiLK flow records have an IP version associated with them. That is, the flow record is identified as IPv4 or IPv6 rather than the individual addresses within the record. Each record contains three IP addresses: source (sIP), destination (dIP), and next-hop (nhIP). ThenhIP field is given the zero address by dedicated sensors such asyaf; only routers that act as sensors provide an actual next-hop address in this field. Some SiLK commands (e.g.,rwgroup) place addresses or other information in this field.

When an IPv4 address appears in an IPv6 record, it is stored as an IPv4-mapped address, in the form ::FFFF:w.x.y.z. How an IPv4-mapped address appears in output depends on the --ipv6-policy option, particularly when it is set toasv4.

In Example3.40, only the first record is an IPv4 record. The SiLK tool that created the record was presented with two IPv4 addresses, so it created an IPv4 record. The second and fifth records were presented to the

Table 3.17: --ipv6-policy Values

Value Description

ignore Processes IPv4 input records but not IPv6 ones. This choice displays addresses in 15- character columns instead of 39-character columns because all the addresses are IPv4 addresses.

asv4 Processes IPv4 records and some IPv6 records. Converts an IPv6 record to an IPv4 record if the source and destination addresses are both IPv4-mapped addresses and the next-hop address is either zero or an IPv4-mapped address. Ignores other IPv6 records. This choice displays addresses in 15-character columns.

mix Processes both IPv4 and IPv6 records. Treats all addresses as having the same version as the record that contains them. This choice displays addresses in 39-character columns, since IPv6 records may be present.

force Processes both IPv4 and IPv6 records. Converts IPv4 records to IPv6 records, converting IPv4 addresses to IPv4-mapped IPv6 addresses. This choice displays addresses in 39- character columns.

only Processes IPv6 input records but not IPv4 ones. This choice displays addresses in 39- character columns.

tool with an IPv6 address and an IPv4 address, creating an IPv6 record with the IPv4 addresses stored as IPv4-mapped IPv6 addresses.

The output in Commands 1, 3, and 5 of Example 3.40have had 15 spaces removed from the two address columns to allow the output to fit within page margins.

• Command 1 in this example shows the default for most configurations: It permits a mixture of IPv4 and IPv6 formatted records. Addresses that were Version 4 before they were stored in IPv6 records are now stored as IPv4-mapped IPv6 addresses and appear as IPv6 addresses with the mix policy. • Command 2 shows the policy of ignoring IPv6 format records, resulting in only one record output and

in formatting space reduced to the needs of IPv4 addresses.

• Command 3 shows the policy of processing only IPv6 records, which again reduces the number of records displayed and also expands the formatting space to that required by IPv6 addresses.

• Command 4 coerces IPv6 addresses to IPv4 format if possible, which processes more records than Command 2 but fewer than all the records, and reduces the formatted width to the space required by IPv4 records. It is possible to format an IPv6 address as IPv4 if the address is in the IPv4-mapped or IPv4-compatible netblocks (see Table 1.1on page 9).

• Command 5 forces all IPv4 records to be processed as IPv6 records using IPv4-mapped addresses and expands the formatting space to that required by IPv6 addresses.

The address policy can be specified in two ways: via the SILK_IPV6_POLICY environment variable or the --ipv6-policy parameter for the relevant tools. In general, the environment variable method tends to be preferred because it avoids further extending the length of SiLK commands.

3.9. FEATURES COMMON TO SEVERAL COMMANDS 77

Example 3.40: Changing Record Display with --ipv6-policy

<1>$ rwcut sample -v4+v6.rw -- fields =1 -5 --ipv6 - policy = mix

sIP | dIP | sPort | dPort | pro |

198.51.100.2| 203.0.113.3| 80|60014| 6|

:: ffff :203.0.113.3| :: ffff :198.51.100.2|60014| 80| 6|

2001: db8 ::10:10| 2001: db8 ::10:12| 25|62123| 6|

2001: db8 ::10:12| 2001: db8 ::10:10|62123| 25| 6|

:: ffff :198.51.100.2| 2001: db8 ::10:10| 0| 256| 58|

<2>$ rwcut sample -v4+v6.rw -- fields =1 -5 --ipv6 - policy = ignore

sIP | dIP | sPort | dPort | pro |

198.51.100.2| 203.0.113.3| 80|60014| 6|

<3>$ rwcut sample -v4+v6.rw -- fields =1 -5 --ipv6 - policy = only

sIP | dIP | sPort | dPort | pro |

:: ffff :203.0.113.3| :: ffff :198.51.100.2|60014| 80| 6|

2001: db8 ::10:10| 2001: db8 ::10:12| 25|62123| 6|

2001: db8 ::10:12| 2001: db8 ::10:10|62123| 25| 6|

:: ffff :198.51.100.2| 2001: db8 ::10:10| 0| 256| 58|

<4>$ rwcut sample -v4+v6.rw -- fields =1 -5 --ipv6 - policy = asv4

sIP | dIP | sPort | dPort | pro |

198.51.100.2| 203.0.113.3| 80|60014| 6|

203.0.113.3| 198.51.100.2|60014| 80| 6|

<5>$ rwcut sample -v4+v6.rw -- fields =1 -5 --ipv6 - policy = force

sIP | dIP | sPort | dPort | pro |

:: ffff :198.51.100.2| :: ffff :203.0.113.3| 80|60014| 6|

:: ffff :203.0.113.3| :: ffff :198.51.100.2|60014| 80| 6|

2001: db8 ::10:10| 2001: db8 ::10:12| 25|62123| 6|

2001: db8 ::10:12| 2001: db8 ::10:10|62123| 25| 6|

Chapter 4

Using the Larger SiLK Tool Suite

The previous chapter described the basic SiLK tools and how to use them; with the knowledge from that chapter and a scripting language (e.g., Bash or Python®), an analyst can perform many forms of traffic analysis using flow records. However, both to speed up and simplify analyses, the SiLK suite includes a variety of additional analytical tools. This chapter describes the other tools in the analysis suite and explains how to use them. Like the previous chapter, this one will introduce these tools, present a series of example analyses, and briefly summarize the functions of the common parameters specific to each tool. Section4.9surveys parameters that are common across several tools, with further information presented in Section3.9.

On completion of this chapter, you will be able to

• track flow record files with rwfileinfo and manipulate them with rwcat, rwappend, rwdedupe, and rwsplit

• create flow record files from text data withrwtuc

• translate packet data to flow records with rwptoflow and use the flows to isolate packets of interest with rwpmatch

• manipulate blocks of IP addresses in the SiLK suite viarwnetmask

• produce address-based representations for analysis using the set and bag tools • associate related flow records via rwmatch and rwgroup

• annotate IP addresses with analysis information using prefix maps • extend the function of SiLK tools by invoking plug-ins

4.1

Manipulating Flow Record Files

Once data are pulled from the repository, analysis may require these data to be extracted, rearranged, and combined with other flow data. This section describes the group of SiLK tools that manipulate flow record files: rwcat, rwappend, rwsplit, rwdedupe, rwfileinfo, and rwtuc.