Layer switches.

This `switch' terminology that applies to all layers of the OSI model is getting confusing. I needed a clear picture so I went to do a quick search and here's what I found:

Layer 2 switch:

• that's your regular switch. It learns what traffic shows up on what port to direct direct there faster instead of forwarding to all the ports like a hub does. It operates at the MAC address level.
  

Layer 3 switch:

• Layer 3 switches are high performance routers. The switching part of the business is done in hardware instead of being handled by a CPU and packets are switched based on their IP address, by doing routing table comparison entries. The routing tables are of course populated as the result of responding to routine protocols. More on the topic can be found here.
• Layer 3, being switches, are aware of VLAN and can route traffic between VLANs.
  

Layer 4 switch:

• It does policy based switching -- a lot of what a firewall does if the device acts on layers above 4. A L4 switch can also do load balancing by identifying sessions and directing them to a dedicated server. See more here and here too.

Further into blurrying layers, MPLS (Multi Protocol Label Switching) that inserts layer 2 and/or layer 4 information into tags that exists at layer 3 to be handled by specialized equipment (LSR: Labelled Switch Routers) to circumvent congestions, bottlenecks or link failures.

Packet filtering with iptable

Netfilter implementation

Just as a reminder: netfilter provides a way for kernel modules to register callbacks/hooks (there are 5 of them) with the network stacks (IPv4,6 and DecNET.) iptable implements in the kernel a named array of rules. For the purpose of implementing a firewall, tracking connections or doing NAT, packets arriving at the netfilter hooks are sent traversing iptables and might or might not get out of it alive.

About the use of the limit module (found in the Packet Filtering HOWTO, from netfilter.org:)

• By combining the number of packet to accept per unit of time (like a second) and the number of burst packet, one can implement syn-flood protection. For instance: -p tcp --syn -m limit --limit 1/s will make you accept five SYN request in burst, after allowing only one per second and reconstituing the burst buffer by one shot every second.

• With -p tcp --tcp-flags SYN,ACK,FIN,RST RST... and limits, one disable a furtive port scanner.

• With -p icmp -icmp-type echo-request and limits, one deals with the ping of death.

Note that the rules can be injected into the packet filtering infrastructure using the iptables commands, but the libipq API is provided as a way to interact from user space with iptables. For instance, there's a version of snort that receives packets from iptables instead of getting them from libpcap and will inform iptables whether the packet should be dropped, rejected or modified.

Firewalling with netfilter

Existing chains:

• PREROUTING: before the route decision is taken (does mangling and nat)
  
• FORWARD, when the firewall is routing input traffic, goes to post-routing (does mangling and filtering)
  
• INPUT: on the incoming traffic (does mangling and filtering)
  
• OUTPUT: the outgoing traffic, goes to post-routing (does mangling, nat and filtering)
  
• POSTROUTING (mangling and nat)

Each tables (filter, mangle and nat) in a chain can be filtered. Each chain implements rule based filtering on its table, and after consultation, the fate of the packet will be decided upon: ACCEPT or DROP. If no rule matches the packing under scrutiny, then the default chain policy is applied -- usually, you want to DROP the packed if you failed to successfully determine its fate after filtering.

Connection tracking:

Tracking connections at the firewall level is important -- for instance, you want to allow new and established connection to leave your network, and established connection to enter your network. Note that after a connection has been established and a few packets have been sent, the connection is declared assured.

Tracking TCP connections closure is done by recognizing the FIN/ACK or RST sequence, and letting the connection enter a time wait status to give a chance to all packets to traverse the firewall ruleset (thing about out-of-order packets reaching the firewall after the connection reset packet has been received.)

Note that UDP and ICMP traffic is tracked as connection in the sense of monitoring what is being sent to who and back, although the UDP and ICMP protocols aren't establishing connections by themselves. Since ICMP packets can be sent back to connection orignators to indicate of a problem, they should be considered as related to other connection traffic.

Some complex protocols (such as FTP) that are sending related connections requests in the a control connection require the firewall to examine the traffic to mark requested new connection as related.

Further readings that I should indulge in:

• PF stateful packet filter porting
• Design and performance of OpenBSD's pf
  

RAW socket programming.

RAW:

A recent openBSD exploit eventually got me into looking at RAW socket programming. The exploit is fairly recent and can be found here. The checksum routine doesn't work BTW (use any other implementation and it works.)

I took a look at the patch that fixes the exploit, but I don't know enough of openBSD to understand why it crashes some specific kernels -- but it looks like a bogus timestamp can trigger the computation of a TCP retransmit timeout that will eventually crash the system.

packet generation utility:

All this makes me want to write a generic packet generator. netcat (see tutorial here) is nice but I guess what I want is something that can let me craft packets the way I want, for instance

• packet -src=192.168.0.1 -dst=192.168.0.2 -proto=tcp -ttle=255 -tos=0 -fragment=no -sport=1234 -dport=80 -seq=rand -ack=rand -flags=SYN,ACK -window=512
  

Or

• packet -ether-type=arp -ether-src=00:... -ether-dst=broadcast

You get the idea.

Passive OS fingerprinting.

The classic on OS fingerprinting is here. Active OS fingerprinting relies on sending packets (mostly TCP and ICMP) to open or closed ports and observing the answer, but this is rude.

p0f is a passive OS fingerprinting that allows for all sort of interesting application. It works best when it sits waiting for packets to showup for analysis. For instance, it could be installed on a web server to look at incoming TCP packets to find out what is connecting to it.

Here's how it figures certain things:

• the uptime: the timestamp on SYN requests here (but this depends on the OS: Linux seems to be using ctime, Windows is using some HZ increment.)
  
• The link type: with the gathered MSS/MTU (packet -vs- payload size) values
• NAT: analyzing disparities in fingerprinting received for the same IP (link type, OS identification, etc...)

Just a few hints:

• Look at the TTL value in the received packet and do a traceroute to figure the TTL: 64 is common for Linux/BSD, 128 could be a Windows box
• Look at the Window Size: 0x1600/0x2D00 or so and somewhat constant through the connection is common for Linux.
• Changing through the life of the connection is common for Windows.

Mention of p0f fetched here.

NAPI.

These are interesting notes about NAPI. In short, the idea is, as far as receiving packets is concerned:

1. To generate interupts when a first packet arrives
2. To disable interupts for the device
3. To let softirqs poll for remaining packets.
4. Only when the kernel is done with a set of packets are interupts enabled again for the device.

Now packets can be silently droped. Device attribution is on a per CPU basis and mutually exclusive.
Interestingly enough, /proc/sys/net/core/netdev_max_backlog can be set to specify how many packages can be polled in one softirq handler invocation. Default is 300.

The article provides a fair amount of technical details, including a sizing on the number of the thread involved as well as information on some of the call chains.

About SNMP (Simple Network Management Protocol)

I don't remember where I read this from. Here are the notes:

• SNMP: servers on devices, clients query devices. servers reply to SNMP request if the community string in the request matches the one it expects.
  
• SNMP Management Information Base (MIB) defined using ASN.1 format
• SNMP communication defines a UDP message (get, get-next, set, trap) encoded in PDUs (Protocol Data Units.)
• SNMP defines a start set of values (defined by string or a numeric identifier in dot-notation)
• SNMP defines a standard way of adding objects
• SNMP MIBs are arranged in a tree, with ISO internet on top andour main branches
  

internet -+- mgmt           (standard SNMP object)
     |- private        (vendor SNMP object)
     |- experimental   (not really used)
     `- directory      (not really used)

• Tree leaves are either discrete MIB objects (`.0' extention to their name) or table MIB objects (`.' extention to their name)
• MIBS have specific values, defined in SNMP primitive types (text, counter, gauge, integer, enum, etc...) MIB objects have acces values (ro, rw, wo)

I'm adding more to this SNMP stuff:

• The SNMP FAQ is huge, it's here, it points to a good introduction available as a PDF.

About VLANs.

Note gathered during some reading about VLANs. See also the vconfig man page.

• VLAN architecture and frame tagging techniques. 802.1q specifies a tag header following the source MAC address field.
• VLAN tagged frames carry VLAN id and priority information (priority use is defined in 802.1p)
• VLANs can be setup as port based, MAC based or Layer3 protocol and address based.
• CRC (Cyclic Redundancy Check). Remainder of the bit string converted to modulo 2 coefs polynomial, divided by an other pre-defined polynomial (key.) Ethernet uses key 0x04c11db7 (degree-32, 32nd degree coef implicitely 1.)
• The CRC is added to the message polymomial after multiplication by x^32 and sent,upon recomputation, the result should be zero. More info here.