https://github.com/rustybird/corridor
Tor traffic whitelisting gateway
https://github.com/rustybird/corridor
firewall tor
Last synced: over 1 year ago
JSON representation
Tor traffic whitelisting gateway
- Host: GitHub
- URL: https://github.com/rustybird/corridor
- Owner: rustybird
- License: isc
- Created: 2014-02-14T13:07:53.000Z (over 12 years ago)
- Default Branch: master
- Last Pushed: 2024-11-27T15:52:50.000Z (over 1 year ago)
- Last Synced: 2024-11-27T16:43:14.421Z (over 1 year ago)
- Topics: firewall, tor
- Language: Shell
- Homepage:
- Size: 181 KB
- Stars: 68
- Watchers: 11
- Forks: 6
- Open Issues: 9
-
Metadata Files:
- Readme: README.md
- License: LICENSE-ISC
Awesome Lists containing this project
README
# corridor, a Tor traffic whitelisting gateway
**Not affiliated with the Tor Project.**
There are several transparently torifying gateways. They suffer from the same problems:
- It's tricky to isolate circuits and issue NEWNYM signals, especially if multiple client computers are involved.
- Any garbage software can pump identifiers into "anonymous" circuits, and get itself exploited by malicious exit nodes.
- Trust is centralized to the gateway, which is bad enough when used by one person, and just inappropriate when shared with strangers.
**corridor takes a different approach. It allows only connections to Tor relays to pass through (no clearnet leaks!), but client computers are themselves responsible for torifying their own traffic.** In other words, it is a filtering gateway, not a proxying gateway.
You can think of it as a fail-safe for your vanilla Tor Browser or Tails, for your beautiful scary experimental Qubes proxying schemes, etc. Or invite the hood to use your WiFi without getting into trouble.
## Principle of operation
1. The corridor-data script opens a Tor control connection and subscribes to NEWCONSENSUS events (announcements listing all public relays), unless you inform it of any bridges to use instead.
2. That data is used to atomically update a Linux ipset (a list of IP-address:TCP-port entries accessible in constant time) named corridor_relays containing either all your bridges or all *acceptable* relays along with their ORPort. Acceptable means the relays have a Valid flag and a Guard or Authority flag.
3. iptables rules refuse to forward packets unless they are going to / coming from one of the relays inside the ipset.
## Pitfalls
- **To be safe, corridor needs two separate network interfaces**, like two Ethernet NICs, or one WiFi radio and one DSL modem. One is to receive incoming traffic from client computers, the other one is to pass the filtered traffic towards the global internet, **and they need to be on different network address spaces**: Clients must not be able to take a shortcut via DHCP, DNS, ICMP Redirect requests, and who knows what else.
- corridor cannot prevent **malware** on a client computer from **finding out your clearnet IP address**, e.g. by sending the `GETINFO address` command to any Tor control port on the network (incl. the one on the client computer itself). **corridor is not a replacement for using a well-designed operating system on your client computers**, like Qubes with TorVM/Whonix.
- The optional **logging of prevented leaks has several limitations**:
- Consider the role of DNS:
- If leaky client software tries connecting to a server by its IP address, you see that in the log.
- If it tries resolving a hostname through a hardcoded DNS server, you see a *failed connection to that DNS server* in the log.
- If it tries resolving a hostname but the client system does not know any DNS server, *there is no connection* that could be logged.
- Clients can spoof their source IP address.
- The kernel shows MAC addresses in the log lines, maybe you don't want that.
- You **probably should not use corridor in combination with other iptables-based firewalls** (like ufw): They can easily clobber some or all of corridor's rules. At the very least, start corridor-init-forwarding and corridor-init-snat *after* your other firewall, e.g. using systemd orderings.
## Installation
*You may also be interested in Patrick Schleizer's [corridor Debian package](https://github.com/adrelanos/corridor), or the [corridor page in the Whonix wiki](https://www.whonix.org/wiki/Corridor)*
```
# Install corridor and its systemd units to the default location in /usr/local.
make install install-systemd
# Edit the configuration.
$EDITOR /etc/corridor.d/*
```
## Manual usage
```
# Set up IP traffic forwarding.
corridor-init-forwarding
# Set up Source NAT with iptables.
corridor-init-snat
# Keep track of acceptable Tor relays.
corridor-data &
# Log attempted leaks from selected clients.
# This command will block until corridor_relays gets populated!
corridor-init-logged
```
## systemd
```
# If you use something other than systemd-networkd to bring up your
# network interfaces (make sure that whatever it is correctly orders
# itself after network-pre.target!), you must add a dependency:
mkdir /etc/systemd/system/some.service.d
cat >/etc/systemd/system/some.service.d/corridor.conf <