RANONYMIZE.CONF(5)

๐Ÿ“ฆ
version 5.0.2+git20250321.41f65e2 ยท 3 versions
, in debian trixie, ubuntu questing, ubuntu resolute, ubuntu stonking

๐Ÿ’– RANONYMIZE.CONF ๐Ÿ’–

okay bestie, so this is the manual page for ranonymize.conf in section 5 (File Formats Manual) of the manual. it's a config file page. it's giving โœจsystem administrationโœจ but make it cute. let's get into it ๐Ÿซถ


โœจ NAME โœจ

ranonymize.conf โ€” the configuration file for ranonymize(1). that's it, that's the name, slay ๐Ÿ’…


๐ŸŒธ SYNOPSIS ๐ŸŒธ

ranonymize.conf

๐Ÿฆ‹ DESCRIPTION ๐Ÿฆ‹

so this config file is where you go to set options for argus data anonymization. that's the whole vibe. it's the lil settings file that lets you control how your argus data gets scrubbed before you let it out into the world ๐ŸŒˆ


๐Ÿ‘‘ OPTIONS ๐Ÿ‘‘

the anonymization clients have a small number of options for controlling specific aspects of the anonymization function and its output. small but mighty, fr fr.

โฐ Timestamps, Reference and Sequence Numbers โฐ

ranonymize anonymizes a bunch of fields in Argus records, like:

  • the network addresses
  • protocol specific port numbers
  • timestamps
  • transaction reference numbers
  • the sequence numbers

so for some of these โ€” specifically the timestamps, the transaction reference numbers and the sequence numbers, which are generally monotonically increasing counters โ€” the good anonymization technique is to shift the values by a constant, so the sequential relationships between values stay intact. the vibes of the ordering? preserved. iconic.

the config gives you some flexibility here so you can control that fixed offset shifting anonymization. the constant value can be generated by the anonymization client at "random" โ€” that's the default behavior, no cap โ€” or you can provide a "fixed:x", where x is the fixed offset. and of course, the keyword "none" turns off the default anonymization for these values. your call, bestie.

RANON_TRANSREFNUM_OFFSET=random
RANON_SEQNUM_OFFSET=random
RANON_TIME_SEC_OFFSET=random
RANON_TIME_USEC_OFFSET=random

๐Ÿงš Ethernet Address Vendor Codes ๐Ÿงš

when it's anonymizing ethernet addresses, ranonymize has the option to preserve the vendor portion, if you want that. this lets analytical programs still differentiate anonymized data by vendor type. lowkey genius. this feature is turned off by default tho.

RANON_PRESERVE_ETHERNET_VENDOR=no

๐Ÿ“ก Broadcast Addresses ๐Ÿ“ก

ranonymize has the option to preserve the semantic that an address is a broadcast address. and this is very important when you're doing flow analysis for either operational or performance management tasks, using anonymized data. don't skip this one, i'm serious ๐Ÿ˜ญ

RANON_PRESERVE_BROADCAST_ADDRESS=yes

๐ŸŒ IPv4 Address Anonymization ๐ŸŒ

okay so IPv4 addresses are composed of two parts: a network part and a host part. because a site's addressing strategy might have integrated semantics that you'd want retained in the anonymized addresses, IPv4 address anonymization involves specifying a one-to-one translation table for both the network and host address spaces in an IPv4 address.

once a new network address has been allocated, every occurence of that network address gets substituted in the anonymizer's output stream. and the host address space is anonymized in an independent but similar fashion. two separate lil worlds, same energy โœจ

ranonymize lets you specify the type of anonymization method used in a number of categories. for network and host address conversion, ranonymize can support "sequential", "random" or "no" anonymization. here's the breakdown:

  • Sequential anonymization โ€” allocating new addresses in a monotonically increasing fashion on a first come first serve basis.
  • Random anonymization โ€” allocates random addresses from the working pool of addresses.
  • "no" anonymization โ€” preserves the address type, whether it's network, host, or both.

the default working pool of network addresses contains only non-routable addresses, and starts with 10.0.0.0. and all anonymized addresses are treated as Class C network addresses, in order to conserve the anonymization allocation demands.

now the example, because examples ate ๐Ÿ’… โ€” if the first Argus record contained the addresses 128.64.2.4 and 132.243.2.87 as the source and destination, sequential anonymization would generate the addresses 10.0.0.1 and 10.0.1.1 as the new source and destination addresses. why? because the two addresses have differing network parts, 128.64.2 and 132.243.2, so these would be allocated 10.0.0 and 10.0.1 respectively (sequential allocation). and because these are the first hosts to be allocated, the host parts are both 1. math is math ๐Ÿงฎ

random anonymization could generate 10.24.31.203 and 10.1.34.18 as possible addresses, since both the Class C network address would be allocated randomly from the 10 network space, and the host address part would be allocated randomly from the possible host addresses.

sequential randomization uses the least amount of memory and minimizes anonymization processing time, while random provides better address scrambling. tradeoffs, bestie, tradeoffs.

Implemenation note: currently only supporting sequential
RANON_NET_ANONYMIZATION=sequential
RANON_HOST_ANONYMIZATION=sequential

๐Ÿชœ Address Hierarchy ๐Ÿชœ

ranonymize has the option to preserve the network address hierarchy at various levels of granularity. this lets you preserve the addressing relationships between addresses. the options are "cidr", "class", "subnet" and "no".

Class network adddress heirarchy preservation causes ranonymize() to allocate new network addresses base on the address class. all CLASSA network addresses will be allocated new addresses from the Class A network pool. network addresses will be allocated as 24 bit CIDR addresses, in that the first 24 bits will map to a unique 24 network address, and host addresses will be allocated from the 254 address pool (0 and 255 can be preserved, see below).

RANON_PRESERVE_NET_ADDRESS_HIERARCHY=cidr

๐ŸŽฏ Specific Network Address Aliasing ๐ŸŽฏ

ranonymize can be configured to perform specific network address translation. these must be specified as 24 bit CIDR addresses. and RANON_PRESERVE_NET_ADDRESS_HIERARCHY must be set to "cidr" for this feature to work. no cidr, no feature, that's the rule ๐Ÿซถ

examples would be:

RANON_SPECIFY_NET_TRANSLATION=192.168.0.0::128.2.134.0
RANON_SPECIFY_NET_TRANSLATION=64.12.0.0::134.5.0.0
RANON_SPECIFY_NET_TRANSLATION=128.2.0.0::200.200.0.0

๐Ÿ  Specific Host Address Aliasing ๐Ÿ 

ranonymize can be configured to perform specific host address translation. these addresses are allocated prior to reading any data, and are removed from the potential network address pool, regardless of the anonymization strategy. feel free to list as many addresses that you would like. go off, list them all ๐Ÿ’…

examples would be:

RANON_SPECIFY_HOST_TRANSLATION=192.168.0.64::128.2.34.5

๐Ÿšช Transport SAP Aliasing ๐Ÿšช

ranonymize can be configured to preserve specific ranges of port numbers. for convenience, ranonymize() can be configured to preserve:

  • the IANA well known port allocation range (0-1023)
  • the registered ports (1024-49151)
  • and/or the private port range (49152 - 65535)

also, ranonymize() can be configured to preserve specific port numbers. these numbers are independent of protocol type, so if port 23461 is to be preserved, it will be preserved for both tcp and udp based flows. equal treatment for all protocols, periodt โœจ

RANON_PRESERVE_WELLKNOWN_PORT_NUMS=yes
RANON_PRESERVE_REGISTERED_PORT_NUMS=no
RANON_PRESERVE_PRIVATE_PORT_NUMS=no

Copyright (c) 2000-2024 QoSient. All rights reserved.


๐Ÿ‘€ SEE ALSO ๐Ÿ‘€


okay that's the whole page bestie, you're officially certified in ranonymize.conf ๐Ÿ’– this was ranonymize.conf version 5.0.3, dated 14 September 2016, and it's giving classic manual-page realness. go anonymize something responsibly, mwah ๐ŸŽ€๐Ÿฆ‹โœจ

๐Ÿ“ฆ where this page comes from