Omphalos

From dankwiki
Jump to: navigation, search
Omphalos.png
Three omphalos processes, 2011-12-01

A tool for network enumeration, protection, observation and domination. Omphalos makes use of passive and active portscanning, DNS/DHCP/Zeroconf server interrogation, portknock detection, covert channel detection and establishment, ARP scanning, automatic WEP cracking, man-in-the-middling, and a whole host of other tricks. GPS integration? Oh yes. Coordination across multiple interfaces? Of course. Use of Linux's MMAP_RX_SOCKET and MMAP_TX_SOCKET? Wouldn't have it any other way. Userspace networking is made visible to the host via a TUN/TAP device. While designed as an offensive tool, omphalos has proven useful for network debugging and troubleshooting, as well as experimentation.

  • The latest release is 0.99.7-rc1, released 2013-01-30.
  • Debian-compatible .deb files are available via the SprezzOS APT repository

Omphalos is not a "point-and-click" tool so much as "pull the pin" or perhaps "spray the area". Default behavior is to redirect and seize all traffic, attack weak cryptosystems, archive authentication materials, and learn everything that can be learned. Ideally, a tiny microprocessor would be paired with power and a network device, stealthily physically inserted into a network, and left there; omphalos and liburine would then combine to provide complete network dominance. I hope to combine network programming and the techniques of high-performance computing to create a tool capable of much havoc.

Omphalos: Because one layer is never enough. Code is hosted on GitHub. Bugtracking is hosted on qemfd-bugzilla. There's a mailing list at Google Groups.

Contents

Similar Tools

Countertools

We want to defeat systems like:

  • ArpON by Andrea Di Pasquale et al

Subsumed Tools

Omphalos implements all or portions of the functionality of the following tools:

Versions/Milestones/Releases

Version Release date Features
0.98 (initial alpha) 2011-10-07 (actual)

2011-09-23 (planned)

  • Detection of network entities at layers 2 and 3.
  • Dynamic handling of devices, routes, neighbors and addresses
  • Full netlink, ethtool, nl80211 and wireless extensions support
  • TTY and ncurses-based UI's
  • ARP- and DNS-based probing
0.99.0β (initial beta) 2011-12-01 (actual)

2011-11-11 (planned)

  • Routing/iptables configuration capabilities
  • Hostapd and AP-spoofing support
  • Spoofing support at layers 2 and 3
  • Zeroconf- and WINS-based probing
1.0 2011-12-25 (planned)
  • Automated selection and execution of previous capabilities
  • GPS support
  • Logging support
  • LLTD and some NetBIOS support

General Features

Some planned, some implemented...

  • Modes of operation governing automatic behavior, from "Silent" to "Hostile":
Mode Summary Operating characteristics
Silent Take no actions, only watch.
  • TX ringbuffers/sockets are not automatically created
  • No packets will be issued by omphalos unless requested
  • No automatic modifications to host networking state
Stealthy Take only the actions of a normally-configured host.
  • ARP queries will be automatically issued
  • DNS and Zeroconf queries will be issued, but only as the host is configured
  • No automatic modifications to host networking state
Active Learn what we can, possibly standing out from the crowd.
  • Make free use of detected information for further recon
  • No automatic modifications to host networking state
Aggressive Learn things quickly, in ways that will be noticed.
  • "Active", plus...
  • Periodic and triggered wide-spectrum active scanning
  • Omphalos will freely manipulate host networking state
Forceful Actively disrupt the network, rerouting traffic through us.
  • Continuous scanning of the network
  • MitM automatically effected wherever possible
  • DoS will be employed to make MitM more effective
  • Omphalos will freely manipulate host networking state
Hostile Attempt to make the network unusable.
  • Same as "Forceful", but don't pass traffic along once MitM'd.
  • Actively employ null routing.
  • DoS employed upon network infrastructure, carrier, and and egress.
  • GPS coordination and tagging
  • Fully dynamic behavior viz the networking stack. Add and remove cards, routes, addresses...
  • Audiovisual plugins (FIXME detail! lots of good ideas here)
  • Event/scripting engine
    • Fine-grained MitM packet manipulation, filtering and generation via Parvenu and domain-specific languages
    • Fine-grained, one-click identity theft at any desired layer(s) (assumption of MAC, IP, cookies, etc)
  • Full integration with POSIX capabilities for fine-grained security (nothing runs as the superuser)
  • Covert channel detection at all layers via Zetetic
  • Opportunistic, secure remote control via liburine

Network Analysis

  • Network analysis and debugging ought be spun out into Dr. Benway
Layer Subdivisions What's tracked Notes
Layer 2 From both packets and netlink:
  • VLANs
  • ESSs
  • Nodes from packets:
    • All source hardware addresses seen in packets
    • All destination hardware multicast addresses
  • Nodes from netlink:
    • All hardware addresses in the kernel neighbor cache
    • Our hardware addresses
    • Hardware broadcast addresses
  • Node allocation is backed by a mainly-static VLHU
    • At the point an attacker can overwhelm our VLHU, there's effectively nothing on the network but junk packets.
  • If something's a source, it's being claimed as present here on the network. A destination means nothing, except in the case of multicast.
  • Someone else sending with our MAC address ought be noted, unless we stole their MAC address
  • We can't generally differentiate between two other physical hosts using the same MAC
    • Multiple interfaces might actually be sharing a MAC intentionally for low-latency failover
    • Upshot: we don't/can't care. We only care if someone else uses *our* MAC (unless told it's ok).
  • We can't detect a spoofed MAC, but we can send our own ARP probes and at least determine whether the MAC's being serviced
Layer 3 From both packets and netlink:
  • Networks

We don't want to track network addresses beyond our broadcast domain. That's difficult to determine, however, without a working routing configuration (ie, an address). We'll thus assume that RFC1918 membership or service of an L2-restricted service (like DHCP or Zeroconf) indicates local presence (if it doesn't, it indicates misconfiguration). This means that

  • Hosts from netlink:
    • All network addresses in the kernel neighbor cache
    • Configured router addresses
    • Our configured network addresses
    • Configured broadcast addresses
  • Hosts from packets:
    • All source network addresses from the RFC1918 networks
    • All source network addresses to which we have a configured route
    • All source network addresses observed offering L2-restricted services
      • All routers and nameservers named in a DHCP packet
    • All destination network multicast addresses
  • Host allocation is backed by a dynamic VLHU.
  • More dynamic and larger VLHU than that for layer 2, since we can have more hosts than nodes -- imagine a /0 route configuration sitting on an internet backbone. Small implementations of ARP tables and CAMs in nodes/switches means, say, 4k nodes ought almost always be sufficient for any interface.
  • Multiple nodes can share a host address, but it can also indicate a problem
  • Other nodes using *our* host addresses is a problem unless told otherwise
  • Seeing an L3 address on a MAC means either:
    • There's another network present locally (if we have no route to the L3, and the MAC responds to an ARP query for the L3), or
    • That MAC is routing to that address (if the MAC is associated with a route to the L3), or
    • That MAC serves that address (if we have a local route to the address)
      • Perhaps only temporarily, and perhaps without service provision (eg DHCP requests), or
    • There's any variety of misconfiguration/failure/adversary at work (le sigh)
  • Upshot: we can discover the local network(s) without relying on any configuration, even those which don't advertise (ie with DHCP)
Layer 4 From packets:
  • DNS and DHCP servers
We don't use the local configuration because there's no unified API to access it, nor track changes to it. We'll detect DNS quickly enough if anything's actually using the network, and can partially detect host DNS servers simply by kicking off a query through the standard resolver library (even if we don't use the provided result).

Analysis and Attack Capabilities

Physical Layer Support

Protocol Standard libpcap linktype Linux ARP type Analyzed?
BSD Loopback  ? DLT_NULL N/A No
Linux Cooked Capture packet(7) DLT_LINUX_SLL N/A Yes
Ethernet
  • Ethernet II/DIX
  • Novell 802.3
  • IEEE 802.2 LLC
  • SNAP
  • 802.1Q VLAN/802.1p QoS (IEEE 802.3ac)
IEEE 802.3-2008 DLT_EN10MB ARPHRD_ETHER Yes
Token Ring IEEE 802.5 DLT_IEEE802 ARPHRD_IEEE802_TR No
ARCNET ANSI 878.1
  • DLT_ARCNET
  • DLT_ARCNET_LINUX
ARPHRD_ARCNET No
SLIP

(Serial Line Internet Protocol)

DLT_SLIP
  • ARPHRD_SLIP
  • ARPHRD_SLIP6
  • ARPHRD_CSLIP
  • ARPHRD_CSLIP6
No
PPP (Point-to-Point Protocol)
  • BSD/OS PPP
  • PPP over serial
  • PPPoE (PPP over Ethernet)
  • PPPoA (PPP over ATM)
  • Cisco PPP/HDLC
RFC 1661 DLT_PPP
  • DLT_PPP_BSDOS
  • DLT_PPP_SERIAL
  • DLT_PPP_ETHER
  •  ?
  • DLT_C_HDLC
ARPHRD_PPP Partial
  • No
  • No
  • No
  • No
  • Yes
FDDI

(Fiber Distributed Data Interface)

  • MAC: ANSI X3.139-1987 / ISO 9314-2
  • PHY: ANSI X3.148-1988 / ISO 9314-1
DLT_FDDI ARPHRD_FDDI No
Fibre Channel RFC 2625 DLT_IP_OVER_FC
  • ARPHRD_FCPP
  • ARPHRD_FCAL
  • ARPHRD_FCPL
  • ARPHRD_FCFABRIC
No
IrDA

(Infrared Data Association)

  • IrDA PHY Spec v1.5
  • IrDA Link Access Protocol v1.1
DLT_LINUX_IRDA ARPHRD_IRDA Yes
Radiotap De facto DLT_IEEE802_11_RADIO ARPHRD_IEEE80211_RADIOTAP Yes
Firewire IEEE 1394 N/A ARPHRD_IEEE1394 Yes
Frame Relay  ? DLT_FRELAY ARPHRD_FRAD No
Apple LocalTalk  ? DLT_LTALK ARPHRD_APPLETLK No
LAPD

(Link Access Protocol - D Channel)

ITU Q.921 DLT_LINUX_LAPD ARPHRD_LAPB No

Layer 2

Topology Discovery

For more information, see the Topology Discovery page.

Protocol Standard Support
LLTDP Microsoft
  • Extraction of data from HELLO packets
  • Enumeration via DISCOVERY requests
LLDP IEEE 802.1AB-2005
  • None yet
CDP Cisco
  • None yet
STP IEEE 802.1D
  • Minimal analysis of BDPUs

802.3/Ethernet II

  • Detect physical hosts on the network via MAC analysis
    • Classify as locally-generated, multicast, etc
  • Flood a network with spoofed MAC addresses, in the hope of forcing fail-open behavior to facilitate attacks (see macof from dsniff and Hacking Layer 2: Fun with Ethernet Switches from BlackHat 2002)
  • Probe and autodetect CAM sizes and hash functions, allowing for minimal CAM overflows
  • Autodetect host ARP timings and replacement policies, allowing for stealthy man-in-the-middling
  • Reverse and direct man-in-the-middling (answer all queries for an address, from an address, or both)
  • Gratuitous ARP ("enclosure")
  • Controlled SNAT of outgoing traffic at layer 2, to create multiple realistic hosts ("Capgras delusions")
  • Automated ARP jamming and man-in-the-middling
  • Arpwatch-like layer 2 monitoring
  • VLAN hopping

802.11

  • Passively attack weak cryptosystems (especially WEP), or do so actively if configured
  • Channel hopping or locked operation
  • Spectrum and noise analysis plugin
  • Respond as master to probed networks, on a to-order basis
  • Ability to run omphalos in as an AP client via userspace networking atop radiotap (Monitor mode) and WPA/EAPOL support
    • Or, more likely, some kind of hostapd control using Master mode
  • "Hole 196" injection
  • Viehbock's WPS EAP-NACK brute-force attack (US-CERT #723755)

Layer 3

  • ICMP redirects
    • We're closer than the remote server; jam ours in, and let the real one be tossed as duplicate
  • A whole world of IPv6 mischief
  • Rogue DHCP service
  • SNAT for routing enbondaged neighbors
  • ...much more

Layer 4

  • TCP assassination (via RST) / arbitrary corruption
    • Most TCP implementations will (usually) deliver the first bytes received for a given window
  • UDP assassination (via ICMP) / insertion
  • Cryptographic downgrade attacks on HTTPS etc

Layer 5

  • FireSheep- and BEAST-like session hijacking
  • Progressive user identity/demographic discovery aka "maximum creepy" (heuristics on machine name, web pages visited, accounts revealed, mails sent etc)
    • Watch for and aggregate probed wireless networks, DHCP lease renewals, etc
  • Rogue DNS service
  • File-and-signature association for insecure checksums + csums updated-to-order

Portability

Omphalos currently only runs or indeed builds on fairly recent Linux systems, due to extensive use of advanced capabilities of the Linux networking stack (and the small fact that I don't run anything else). I doubt that I would accept patches to add Windows/MacOSX support, but you're certainly welcome to maintain them yourself. Once the main functionality set is complete (0.98 release), I'll add support for falling back to plain old PF_PACKET sockets without ringbuffers; that ought add support for any UNIX-based OS with a basic rtnetlink implementation.

User Interfaces

  • omphalos-tty: line-based console output with readline-based input
  • omphalos-ncurses: screen-based terminal output with ncurses-based input
  • GTK: I'd like to add a GTK UI, but it's not a major priority
    • If you'd like to contribute freely-licensed, original artwork to this effort, please contact me!
  • WxWidgets, QT: Dubious that I'll add one, but I'd take patches.
  • Java: nope

Project documentation

Transcluded from top of my git repository at GitHub.

README

*omphalos* by nick black <nickblack@linux.com>
==============================================

"Gaze into your omphalos." - James Joyce, Ulysses

Omphalos is an integrated tool for network enumeration and domination. It
is designed around Linux's rtnetlink(7) layer and PACKET_MMAP capabilities.
Whereas other tools are geared towards either reconnaissance or directed
attacks, omphalos is designed to "spray the area".

I. Requirements
II. Building and installation
III. Usage
IV. Hacking
V. FAQs
VI. Thanks

===================================================================
I. Requirements
===================================================================

GNU Autotools are used to build the configure script. They are not necessary
when building from a release tarball.

A C compiler is used at buildtime.

libsysfs, libnl3, libpcap, libpciaccess, libz, libiw and libcap are used at
both build and runtime.

Omphalos currently only builds or runs on a Linux kernel with PACKET_MMAP
sockets. Packet transmission requires at least a 2.6.29 kernel.

The TTY UI requires GNU Readline.

The ncurses UI requires libncursesw (ncurses with wide character support),
and libpanelw (distributed with SVR4 curses and ncurses).

The X UI requires libX11 and friends.

arp-scan's 'get-oui' program is used to build the IANA OUI file.

wget is used to download the USB ID file.

GnuPG is used to verify signed tarballs.

Manpages and XHTML documentation require xsltproc and docbook-xsl.

Your TERM and LOCALE/LANG environment variables need be correctly set to make
full use of omphalos-ncurses. Ensure that a UTF-8 locale is being used, and
that your terminal definition supports 256 colors.

===================================================================
II. Building and installation
===================================================================

If compiling from checked-out source, run "autoreconf -fi -Wall,error" to build
the initial configure script (a configure script will be present in release
tarballs).

"./configure && make && sudo make postinstall" ought be sufficient to build and
install Omphalos. Run "./configure --help" to see supported build parameters.

If filesystem-based capabilities are supported, it might be desirable to bestow
CAP_SETUID privileges (this is *not* equivalent to a setuid binary). See
"Usage" regarding switch to the "nobody" user when CAP_SETUID is possessed:
this can help defend users from malicious files, even if they're not allowed to
open packet sockets. If non-root users should be able to use network
capabilities, add CAP_NET_ADMIN and CAP_NET_RAW to the binary. This can be
accomplished by running "make sudobless" or running tools/addcaps.

If MADV_HUGEPAGE is available at compilation time, madvise() will be used to
advise hugepage backing for important, large data structures including the
ringbuffers. This could improve performance.

To restore an omphalos directory to its pristine form, ensure a Makefile has
been generated via ./configure, and run "make maintainer-clean".

===================================================================
III. Usage
===================================================================

Several capabilities are required for omphalos's usage of packet and
netlink sockets. Omphalos *does not* need to run as root, and generally
should not be. See "Building and installation" for details on setting up
the omphalos binary's privileges.

If omphalos possesses the CAP_SETUID capability (as it always will if run
as root), it will by default attempt to become the "nobody" user. This can
be suppressed via an empty argument to the -u option (-u ""), but helps
defend against malicious input.

Some fonts do not support the full range of Unicode glyphs used by omphalos, or
render them in an unexpected way. Fonts known to cause problems include:

 - Terminus (vertical lines don't match up with rounded corners)
 - Computer Modern (lmodern) (numerous problems)
 - Cortoba (numerous problems)
 - Courier (spacing issues)
 - Electron (numerous problems)
 - FreeMono (spacing issues)
 - Nimbus (spacing issues)

Fonts known to work include:

 - Arial
 - Bitstream Vera Sans
 - Comfortaa
 - Consolas
 - DejaVu Sans Mono
 - Droid Sans Mono
 - Inconsolata
 - Junicode
 - Liberation
 - PragmataPro
 - Sansation

===================================================================
IV. Hacking
===================================================================

=======================================
IV.A Networking
=======================================

We cannot assume that we will see all control traffic, due to switched
networks, wireless topography, physical/network-layer encryption and drops.
Packets can be dropped (possibly silently) at the card, in the networking
stack (thus being neither copied nor processed), or due to a full
ringbuffer (thus being processed but not copied). It thus cannot be assumed
that all packets processed by the machine are able to be read, nor that all
packets seen on the wire even generate a statistic.

We cannot transmit with another station's hardware address; this will not
be generally allowed in a switched network.

We cannot assume that we have an IP address on a local network; this
requires configuration, and will never be the case for eg a bridge.

We cannot assume other hosts are not misconfigured, broken, or adversarial.

=======================================
IV.B UIs/clients
=======================================

Callback functions might be called by any number of different threads,
possibly concurrently. No relationship can be assumed between threads and
callbacks.

Callbacks are like interrupt handlers. There is a finite ringbuffer for
incoming packets. Packet handling must proceed at wire rate, or else the
ringbuffer will eventually be filled up. GUI events cannot generally
proceed at wire rate, so packet handlers must generally aggregate events
and dispatch work.

You can associate opaque state with an object passed to a callback by
returning a pointer to that opaque state. Returning NULL will disassociate
any attached opaque state. Don't keep a private store of things like
interface data or network sessions; use the general accessors.

It's fine to create threads in your UI, but do not do it until after
calling omphalos_setup(), since this drops permissions and sets up signal
masking necessary for cancellation to function properly. If there are
signals your UI threads must handle, mask them prior to calling
omphalos_setup(), unmask them in the handling thread, and remask them prior
to calling omphalos_init(). Masking them prior to calling omphalos_setup()
is not currently necessary, but will be should it ever spawn threads.

A diagnostic callback must be defined. omphalos_setup() will provide a
default fprintf(stderr,...) callback; you can change it prior to calling
omphalos_init(), but omphalos_init() will error out if it is set to NULL.
There is not yet any means to manage diagnostic output in omphalos_setup().

A packet callback will only reference an incoming interface for which the
device event callback has been successfully invoked, without an intervening
device removal callback invocation. A device removal callback can be invoked
with no corresponding device event callback. Host callbacks follow the same
rules as packet callbacks with regard to device callbacks.

=======================================
IV.C Porting
=======================================

Omphalos uses several advanced features of the Linux kernel directly, and
many use cases require other functionality. Porting will involve, at
minimum:

 - a means of reading packets from the wire (traditional packet(7) sockets,
    libpcap, etc)
 - a means of transmitting packets on the wire (traditional packet(7)
    sockets)
 - a means of acquiring link, address, route and neighbor information from
    the kernel (we use rtnetlink). this has traditionally been a messy set
    of ioctl()s on linux, which would have to be poll()ed.
 - a means of acquiring physical information from the kernel, especially
    for wireless devices (we use nl80211).
 - a means of dropping general privileges, but retaining those capabilities
    necessary for network activity (perhaps a client/server process pair'
    communicating over PF_UNIX sockets).

=======================================
V. FAQs
=======================================

1. omphalos-ncurses exits immediately after printing "Entering ncurses mode..."
1A. initscr() is probably calling exit() because it couldn't set up your
    terminal. Ensure the TERM environment variable is exported, and correctly
    set for your terminal type.

2. I see hosts with 0 packets sent or transmitted.
2A. Most likely they were present in your system's ARP cache.

3. I see a lot of "protocol 0800 is buggy, dev XXX" messages in dmesg.
3A. This is a diagnostic issued by the kernel's packet socket mechanism. It
    will show up if you run tcpdump, wireshark, or any other user of PF_PACKET
    sockets on the interface. It has nothing to do with omphalos or the packets
    it generates.

=======================================
VI. Thanks
=======================================

* Jeremy Stretch of PacketLife.net, for supplying PCAP-format unit tests.
* Peter Jensen <peter@diff.net>, patch [master f9fee3b]
* Robert Edmonds <edmonds@debian.org>, for Autotools advice and assistance
   interpreting DNS packet captures.

Data Organization

Data Organization and Entry Points
==================================

Our input sources include packet sockets, the operating system's netlink
infrastructure, filesystem events, and UI events.

Actions invoked by the UI and service interrogations performed automatically by
omphalos will most often operate naturally at layer 3 or above: a port scan
cannot be run against a MAC, nor can a DNS request be issued to one. Inputs
from the packet socket, however, are most naturally keyed off of layer 2
(especially since a given layer 3 address can show up on multiple layer 2
networks, which MAC addresses' global uniqueness property makes less common).
The netlink layer, meanwhile, refers almost exclusively to logical interfaces,
and various device properties are associated with physical interfaces.

It must be remembered that misconfigured and adversarial peers can violate the
expected properties at any layer save the physical. Other cases to consider,
with definite effects on network modeling, include:

 - multipath routing
 - line bonding
 - proxy ARP
 - disconnected IP networks (local overload of global IP space)
 - multiple cards on the same medium
 - multihoming
 - fail-over/load-balancing
 - unconfigured local networking
 - movement among physical networks without local networking changes
 - same mac address on different networks
 - overeager dhcp
 - etc. ...

Furthermore, omphalos might run in an environment not meaningfully
supported on a typical networking stack, for instance one where two interfaces
are connected to two distinct media which happen to use the same RFC 1938 or
RFC 4193 addresses (Linux would treat this as the same network, and freely
route from either interface). Since we present an interface-centric UI to the
user, and retain knowledge of routes as implied by observed traffic, we can
meaningfully distinguish across destination network addresses seen on multiple
media or from multiple hardware addresses (using this information, of course,
represents a deviation from configured routing policy).This is an explicit
objective: a fundamental goal of omphalos is to discover routes beyond the
local network, even when no configuration exists. Otherwise, we could simply
make use of the kernel routing and neighbor caches, and be done with it.

Knowledge Forward
=================

Upon receipt of a packet, we know ab initio:

 - the interface on which it was received, *if* we use sockaddr_ll (sll_ifindex
	field), or we're binding a SOCK_RAW socket to each interface. We're
	doing the latter.
 - whether it was ours or not, *if* we use sockaddr_ll (sll_pkttype field).
	we're using SOCK_RAW with our AF_PACKETs, though, since SOCK_DGRAM
	doesn't provide us with the destination address.
 - source hardware address (sll_addr, or look at the physical header) and
	address length *if* we use sockaddr_ll (sll_halen field) or we're
	binding a SOCK_RAW socket to each interface, after discovering its
	hardware address length. Note that this assumed all hardware on a given
	medium have the same hardware length.
 - destination hardware address *iff* we're using SOCK_RAW.
 - physical layer protocol (sll_protocol field, or look at the physical header).
 - length of the frame

Of these, the addresses and protocol are set by the sender. Everything else can
be trusted as objectively "accurate". There's a fine line between an adversarial
deception and reality, however. If an adversary spoofs a MAC address and IP
address, and provides service on it, treating this as another host is not a
problem. If an adversary successfully takes over a router's IP via ARP hijack,
but faithfully forwards all traffic, not knowing the router's true MAC is not a
problem. Real issues we must concern ourselves with include:

 - traffic randomized across the address space in an attempt to starve us of
	resources. a meaningful attack must uniquely exploit our operation, or
	else the attacker is simply DoS'ing the network.
  - we defend against this with algorithms and bounded resource allocation
 - traffic designed to mislead our network analysis. this would include
	advertisement of false routes, hijacking of addresses without
	subsequent forwarding, simulation of dns service from whence it is not
	offered, etc.
  - we defend against this by supporting and testing contradictory information
 - traffic designed to be amplified by our automated actions.
  - we defend against this by ensuring only a finite number (preferably 1) of
	packets (including potential replies) are issued. this is most easily
	done by never automatically transmitting to non-unicast addresses,
	and never automatically triggering stateful reconnaissance. this is by
	no means a complete solution, but it seems the best we can do.

It would be useful if logical interfaces could determine that they share a
medium, but this seems impossible in the general case. Seeing the same hardware
address on multiple interfaces could be the result of generated addresses,
misconfigurations, adversaries, or use of well-known addresses (primarily
multicast and broadcast). Seeing the other card's generated packets could be
the result of misconfiguration, adversarial routing/bridging, adversarial
packet generation (a node with connections to both distinct media could
replicate packets from one to another), etc.

Indexing
========

We need be able to index by logical interface, hardware address, and network
address. Network addresses need be indexed by range, with the ranges organized
by routes. Interfaces contain many hardware addresses; these hardware addresses
may be shared between interfaces, and up to two entities ('ourselves' and
'others') may shared a hardware address on any given interface (this indicates
a misconfiguration, our seizure of another address, or seizure by some other
entity of our own. We cannot generally differentiate between two hosts sharing
a MAC address). Hardware addresses may contain many local network addresses and
many routes. Network addresses are associated with some number of hardware
addresses, potentially on different interfaces. Routes are associated with a
single network address and a single interface. Note that the network address is
not necessary to actually route through the hardware address; routing only
requires the router's network address if the corresponding hardware address is
missing from the neighbor cache.

An l2node is a hardware address. An l3host is an address which some local
machine claims via ARP, an address in which we are interested, or the set of
addresses seen from some local machine which it does *not* claim via ARP. Note
that while routers are specified via network addresses (and discovered thusly
using netlink), their *hardware* addresses are necessary and sufficient to use
them. The union of all interfaces' l3hosts provide complete information
regarding both routes and neighbors as known to omphalos.

Packet Transmission
===================

If targeting a layer 2 address (as in ARP), we can simply construct the packet
and put it on the wire -- no indexing is necessary. Normally, we're targeting a
layer 3 address. This requires a corresponding layer 2 hardware address. If the
transmission is taken in immediate response to some received packet, we have
all this info, and can proceed directly. Otherwise, we find the l3host via
keying into the global l3host table on destination address. This provides us
with a (possibly local) route. The route object knows its associated interface
in O(1), and thus our proper source hardware address (also in O(1)). The route
object also knows the next hop, if one exists; otherwise the destination is
considered the next hop. Routes don't typically specify the destination
hardware address, but we will usually know it. Since we need it to actually
route, whether we know it or not, stash a reference in the route object as soon
as it's learned (and actively try to learn it upon gatewayed route discovery).
This provides us with all necessary destination information.

Packet Receipt
==============

What information can we glean from a packet on the wire? Ignore trust for the
moment. Assume an IPv4 or IPv6 header. This header will have a source and
destination address. We usually ought be able to route to these addresses on
the receiving interface -- if we can't, it's probably due to one of:

 - any number of misconfigurations/failures in any number of places
 - spoofing of source address
 - one-way route
 - our lack of configuration (a special case of misconfiguration)

None of these are particularly interesting, or even necessarily
distinguishable, save the last; if we're lacking configuration, it ought
usually be possible to infer it  -- so far as is necessary to communicate with
entities we've seen -- via active analysis. ARP can be used to determine
whether a hardware address claims a given IP address; a router will not (Proxy
ARP, as mentioned before, can complicate this). An ARP probe requires an IP
address, which we might not have (or might not be in the same network as the
address seen due to misconfiguration etc), but we can spoof someone else's and
gather information that way (indeed, it might be possible to use the target's
own IP address (which we must know) as our source, so long as we supply our
hardware address as a source, and receive the reply). We run the risk in this
case, however, of upsetting other nodes' own ARP caches, and thus ought be
prepared to forward traffic in the case of an unintentional MitM.

Since packet transmission must often be keyed off a layer 3 address, we'd like
full knowledge of the route, interface, and hardware address relations
directly accessible from the l3 objects. Since we're using packet reception to
learn many of these details, that's a natural place to perform the binding.
It further facilitates detection of addresses duplicated across interfaces and
hardware addresses, should that ever prove useful. Finally, this allows
automatic reconfiguration of the routing database based on what we really see
in the network (and thus it can be abused by adversaries if we're not careful).

So, on packet receipt:

 - Ensure a reference to the interface
 - Find the l2 address within the interface's neighbor LRU, or insert it
 - Find the l3 address within the global table
 - If it is found, compare the route info to this data, possibly updating it.
 - If it is not found, and it corresponds to a local route we know, add an
	l3host for the address, and store a reference in our neighbor table.
 - If it is not found, and it corresponds to a non-local route we know, exit.
 - If it is not found, and does not correspond to a route we know, hit the
	source MAC address with an ARP for the network address. A positive
	reply indicates a local address, Proxy ARP, or an adversary. A negative
	reply cannot indicate much, but suggests the possibility of a route at
	the source hardware address to at least the source network address.

One of her sisterhood lugged me squealing into life. Creation from nothing. What has she in the bag? A misbirth with a trailing navelcord, hushed in ruddy wool. The cords of all link back, strandentwining cable of all flesh. That is why mystic monks. Will you be as gods? Gaze in your omphalos. -- James Joyce, Ulysses

See Also

Personal tools
Namespaces
Variants
Actions
Google AdSense
Toolbox