Initial wiki page for ebtables

I asked GPT4 to write an initial page for the package. This is a preliminary version.

Please if/when you learn how to use the tool, come back to this thread and suggest or implement modifications to the text so we can incorporate it in the wiki. Actually, can someone with the ability to do so (@jon maybe) move this message to a properly titled, separate thread?

ebtables - IPFire Plugin

ebtables is a useful tool for network administrators, serving as an Ethernet bridge frame table administration tool. This IPFire plugin provides a straightforward method of managing and controlling the network traffic at the link layer (Layer 2) of the OSI model.

Functionality

ebtables operates by inspecting Ethernet frames as they pass through your Linux bridge, enabling you to define what type of traffic is permitted or forbidden based on MAC addresses and Ethernet frame fields.

This tool allows for the application of filter rules, offering functionality similar to iptables, but operating at a lower level in the network stack. While iptables operates at the Network Layer (Layer 3), ebtables operates at the Data Link Layer (Layer 2), enabling a more granular level of traffic control.

Use Cases

There are various applications where ebtables proves to be useful:

  • MAC Address Filtering: By using ebtables, it is possible to filter traffic based on the MAC address of the sender or receiver. This can be particularly helpful for ensuring specific devices have (or do not have) network access.

  • Virtual LAN (VLAN) Tagging: ebtables can be used to allow or block specific VLANs, providing control over which frames are allowed to pass through certain ports.

  • Bridge Loop Prevention: In some instances, network bridges can cause loops, which create broadcast storms that slow the network. ebtables can be used to prevent this issue by blocking specific MAC addresses from communicating.

  • Traffic Control Between Virtual Machines: When using virtual machines, ebtables can be used to filter traffic between different VMs based on their MAC addresses.

Example Configuration

Below is a basic example of how to utilize ebtables:

# Drop all traffic from MAC address 00:00:00:00:00:01
ebtables -A FORWARD -s 00:00:00:00:00:01 -j DROP
1 Like

Thank you, I do not know how better)… can put this message in a separate thread, if someone else is interested in it, except me)))

1 Like

And this is Claude version of the page, using the same prompt.

ebtables

‘‘ebtables’’ is a Linux kernel module that provides Ethernet bridging frame filtering capabilities. It operates at layer 2 of the OSI model - Wikipedia allowing filtering rules to be applied to Ethernet frames passing through a Linux bridging firewall.

Usage

ebtables allows defining filtering rules that get applied to frames passing through a bridge interface. Common uses include:

  • Blocking or allowing frames based on layer 2 header fields like source/destination MAC address, VLAN ID, etc.
  • Filtering based on layer 3 protocol information.
  • Limiting ARP broadcasts.

Rules get defined in an ebtables chain, which is then referenced from a bridging hook point.

Example rules

# Block all frames with a source MAC of 00:11:22:33:44:55 on the input interface (replace with your actual interface)
ebtables -A INPUT -i green0 -s 00:11:22:33:44:55 -j DROP

# Allow only VLAN 100 on the bridge interface (replace with your actual bridge interface)
ebtables -A FORWARD -i br0 --vlan-id 100 -j ACCEPT
ebtables -A FORWARD -i br0 -j DROP

## Limit ARP broadcasts on the internal (GREEN) interface, only allowing ARP requests and replies, 
## and dropping all other types of ARP packets.
ebtables -A FORWARD -i green0 -p ARP --arp-opcode Request -j ACCEPT 
ebtables -A FORWARD -i green0 -p ARP --arp-opcode Reply -j ACCEPT
ebtables -A FORWARD -i green0 -p ARP -j DROP

References

1 Like

I created a blank page…

2 Likes

This is the content I propose to add to the wiki stub prepared by @jon . I read the documentation and merged few sentences inspired by the official website with the text produced by both the AI models.

@jon @bonnietwin @bbitsch What do you think? Should I remove the deeper explanation of the layer two vs layer 3 (brouting) part of the text?

+++ text starts here +++

Package description

ebtables is a transparent network-traffic filtering tool for Linux-based systems functioning as bridges of two or more networks.

Primarily, ebtables operates at the Data Link Layer (Layer 2 bridging) of the OSI model, which is a standardized framework that describes how network protocols communicate and interact. At this level, ebtables primarily inspects and takes actions based on MAC addresses, which are unique identifiers assigned to each network device. While the primary function of ebtables is to filter based on the layer 2 information, it can also inspect the IP packet within the Ethernet frame payload, enabling it to perform certain Layer 3 operations.

Let’s consider an Ethernet frame as an example:

|-----------------------------------------------------------------------------------|
| Ethernet Frame                                                                    |
|-----------------------------------------------------------------------------------|
| Preamble | SFD | Destination MAC | Source MAC | Type | Payload | Frame Check      |
| 7 bytes  | 1 byte | 6 bytes      | 6 bytes   | 2 bytes | 46-1500 bytes | 4 bytes  |
|-----------------------------------------------------------------------------------|

The ‘Payload’ of the Ethernet frame carries an IP packet:

|---------------------------------------------------------------------------|
| IP Packet (Ethernet Frame Payload)                                        |
|---------------------------------------------------------------------------|
| Version | IHL | TOS | Total Length | ID  | Flags | Frag Offset | TTL      |
| 4 bits  | 4 bits | 8 bits | 16 bits | 16 bits | 3 bits | 13 bits | 8 bits |
|---------------------------------------------------------------------------|
| Protocol | Header Checksum | Source IP Address | Destination IP Address   |
| 8 bits   | 16 bits         | 32 bits           | 32 bits                  |
|---------------------------------------------------------------------------|
| Options (if IHL > 5) | Padding  | Data                                    |
| Variable             | Variable | Up to 65535 bytes (usually less)        |
|---------------------------------------------------------------------------|

The IP packet includes both the ‘Source IP Address’ and ‘Destination IP Address’ among other information which can all be used by ebtales.

Beyond filtering, ebtables offers advanced logging to monitor network activity, the ability to modify MAC addresses in data traffic (a process known as MAC DNAT/SNAT), and ‘brouter’ capabilities, enabling the system to operate both as a bridge and a router.

One of the key advantages of ebtables is its ability to integrate with other Linux filtering tools including iptables, ip6tables, and arptables. This allows the realization of a comprehensive firewall that filters network traffic at multiple OSI model layers.

The ebtables and arptables tools are maintained by the same developers who contribute to the netfilter project, the same framework that facilitates network traffic filtering used by IPFire. They continue to ensure these tools are updated and effective. The original website remains primarily for documentation reference purposes (see references).

Usage

ebtables allows defining filtering rules that get applied to frames passing through a bridge interface.

As for iptables, in the Linux kernel ebtables uses tables (in this case they are three) that contain built-in chains for organizing its rules. These tables allow us to separate the functionality into different groups of rules.

  1. A ‘chain’ is just a set of rules arranged in a specific order. Each rule in the chain checks if it matches a particular Ethernet frame (a unit of data sent over a network).
  2. If a rule matches the frame, it then uses a ‘target’, or an instruction, to determine what to do with that frame (i.e. ACCEPT, DROP, CONTINUE, RETURN).
  3. If a rule does not match the frame, the system moves on to the next rule in the chain, and so on, until a match is found or all rules have been checked.

For better performance and organization, users can create their own custom chains.

Example rules

# Block all frames with a source MAC of 00:11:22:33:44:55 on the input interface (replace with your actual interface)
ebtables -A INPUT -i green0 -s 00:11:22:33:44:55 -j DROP

# Allow only VLAN 100 on the bridge interface (replace with your actual bridge interface)
ebtables -A FORWARD -i br0 --vlan-id 100 -j ACCEPT
ebtables -A FORWARD -i br0 -j DROP

## Limit ARP broadcasts on the internal (GREEN) interface, only allowing ARP requests and replies, 
## and dropping all other types of ARP packets.
ebtables -A FORWARD -i green0 -p ARP --arp-opcode Request -j ACCEPT 
ebtables -A FORWARD -i green0 -p ARP --arp-opcode Reply -j ACCEPT
ebtables -A FORWARD -i green0 -p ARP -j DROP

References

Acknowledgments

This page was created with the assistance of OpenAI’s ChatGPT-4, a language model developed by OpenAI, and Claude, a language model developed by Anthropic.

As far as I understand, the full implementation of DHCP snooping is made in the ebtables version v2.0.10-5.

The latest version as I understand it ebtables 2.0.11 - 2019-12-02 16:31. Ipfire contains a very old version of the package ebtables v2.0.10-4 (December 2011)

https://www.netfilter.org/pub/ebtables/

Maybe still delete this package and use arptables + iptables?

for example something like that:

  1. Create an iptables rule to block unwanted DHCP traffic:
arptables -A INPUT --opcode Request --in-interface eth0 -j DROP
  1. Create an iptables rule to allow only trusted DHCP traffic:
iptables -A INPUT -p udp --dport 67:68 --in-interface eth0 -j ACCEPT
  1. Disable all other DHCP packets using iptables rules:
iptables -A INPUT -p udp --dport 67:68 -j DROP
  1. Save the iptables and iptables rules so that they load when the system restarts:
arptables-save > /etc/arptables.conf
iptables-save > /etc/iptables/rules.v4
  1. Make sure that the iptables and iptables rules are loaded at system startup. To do this, add the following lines to the /etc/rc.local file (if a SysV initialized system is used):
/sbin/arptables-restore < /etc/arptables.conf
/sbin/iptables-restore < /etc/iptables/rules.v4

If you are using a system with systemd, create a new unit file, for example /etc/systemd/system/iptables.service, with the following contents:

[Unit]
Description=Arptables Firewall Rules
After=network.target

[Service]
Type=oneshot
ExecStart=/sbin/arptables-restore < /etc/arptables.conf
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

and

systemctl enable arptables.service
systemctl start arptables.service

ebtables-2.0.11 has just finished building on my system and will be submitted into the ipfire dev mailing list and patchwork later this evening.

It should end up in Core Update 177.

3 Likes

I suggest “yes”. It should be enough info to give people an idea of what ebtables is. And then let them dig for the deeper explanation on Linked pages.

I’d mention briefly ebtables does this Layer and iptables does that Layer. and then link to the in-depth.

1 Like

Hi,

i use Core Update 178 and still ebtables v2.0.10-4 (December 2011) addon is available.
When does v2.0.11 come?

And where is the default ebtables.conf location on IpFire? Currently i use /etc/ebtables.conf. Saving does work but restore not.

The Fire throws the message:

  1. Multiple ebtables programs were executing simultaneously. The ebtables
    userspace tool doesn’t by default support multiple ebtables programs running
    concurrently. The ebtables option --concurrent or a tool like flock can be
    used to support concurrent scripts that update the ebtables kernel tables.
  2. The kernel doesn’t support a certain ebtables extension, consider
    recompiling your kernel or insmod the extension.

even with --concurrent toggle no way to load the tables.

Best Regards
Daniel

I see it in CU 179 (testing):

1 Like

Ah thx. Is is it a problem to load it from testing an switch pack to stable?

To me it is not difficult. Please remember you are loading up a testing branch and things may or may not work. I usually test on a separated IPFire box and not on my Production ipfire box.

yeah, i see, was a silly question from me. Forgot the Branches. I will set up a Test VM and use the testing Branch there.

Thank you Jon.

1 Like

As far as I can see there is no ebtables.conf. It is not mentioned at all in the ebtables man page nor in the ebtables documentation.

There was no ebtables.conf in version 2.0.10 and that is the same for version 2.0.11

The execute, save and restore commands for version 2.0.10 were

usr/sbin/ebtables
usr/sbin/ebtables-restore
usr/sbin/ebtables-save

In version 2.0.11 these are changed to

usr/sbin/ebtables-legacy
usr/sbin/ebtables-legacy-restore
usr/sbin/ebtables-legacy-save

This is because this addon package is now the legacy version. The main version is integrated into iptables as ebtables-nft but that is probably not installed because the configure is done with --disable-nftables as IPFire2.x works with iptables and not with nftables.

http://git.netfilter.org/ebtables/commit/?h=ebtables-2.0.11&id=826faffa38de8ce55bb32cd1549fb732229fd80f

I have found the following man pages for ebtables-save-legacy and ebtables-restore-legacy
https://manpages.ubuntu.com/manpages/lunar/en/man8/ebtables-legacy-save.8.html
https://manpages.ubuntu.com/manpages/lunar/en/man8/ebtables-legacy-restore.8.html

2 Likes