update Changelog

corrected link to the diagram in md file

ChangeLog

@@ -1,6 +1,13 @@
-v2.1.1:
+v2.1.3:
+	Fix Landlock access to /etc/hosts.deny and
+	/etc/hosts.allow.
+
+v2.1.2:
 	Fix inetd mode.
 
+v2.1.1:
+	Various minor fixes.
+
 v2.1.0:
 	Support for the Landlock LSM. After initial setup,
 	sslh gives up all local file access rights.

README.md

@@ -36,18 +36,34 @@ Configuration
 
 Please refer to the [configuration guide](doc/config.md).
 
+Transparent proxying
+--------------------
+
 Transparent proxying allows the target server to see the
 original client IP address, i.e. `sslh` becomes invisible.
-This makes it easier to use the server's logs, and potential
-IP-based banning ability.
 
-Configuration of transparent proxying is highly dependent on
-your network environment and infrastructure setup. There is
-no known generic approach, and if you do not find directions
-for your exact setup, you will probably need an extensive
-knowledge of network management and iptables setup".
+This means services behind `sslh` (Apache, `sshd` and so on)
+will see the external IP and ports as if the external world
+connected directly to them. This simplifies IP-based access
+control (or makes it possible at all), and makes it possible
+to use IP-based banning tools such as `fail2ban`.
+
+There are two methods. One uses additional virtual network
+interfaces. The principle and basic setup is described
+[here](doc/simple_transparent_proxy.md), with further
+scenarios described [there](doc/scenarios-for-simple-transparent-proxy.md).
+
+
+Another method uses iptable packet marking features, and is
+highly dependent on your network environment and
+infrastructure setup. There is no known generic approach,
+and if you do not find directions for your exact setup, you
+will probably need an extensive knowledge of network
+management and iptables setup".
 
 It is described in its own [document](doc/tproxy.md).
+In most cases, you will be better off following the first
+method.
 
 
 Docker image

doc/scenarios-for-simple-transparent-proxy.md

@@ -0,0 +1,49 @@
+# Three Scenarios for the simple transparent proxy setup #
+
+![Simple Transparent Proxy Examples](./sslh-examples-v3.png)
+
+## Introduction ##
+The first example is the configuration, which was described in the previousd document. I omitted the loopback interface "lo" in those diagrams, trying not no overload the picture. 
+The connections have two different endings, showing the direction of the opening connection (SYN flag) and the answer connection (SYN-ACK flags). This is important, as the traffic in the transparent proxy setup flows somewhat unexpected.
+
+## Example 1 ##
+The first example shows the setup, which is described in the [previous document](./simple_transparent_proxy.md). You see the Client connecting to sslh (red connection). When sslh accepts this connection, the SYN-ACK packet is send back to the client, which sends the first data packet(s) together with the ACK for the SYN-ACK. So the bidirectional tcp connection is fully open.
+Sslh opens now the blue connection to sshd and needs for that elevation rights, as it uses the clients IP address as its own address for opening this connection. Now things are becoming complicated: Sshd send back the first packet with SYN-ACK flags (green line), addressed to the clients IP (dotted line). As already described, that would go wrong, so our routing trick makes this packet beeing deflected back to sslh, so this tcp connection is also opened. But we have here now an asymetric behaviour, that the read and write pathes of the tcp connection are going different routes.
+The sslh process shuffles now all the bytes coming from sshd from the green line to the red line, vice versa for the packets from the client.
+
+## Example 2 ##
+In this example sshd is running on another server. No matter, if this is docker, kvm, virtualbox or another physical host, connected with an ethernet cable. Here we need no dummy interface, so we need another way, to configure our routing deflection.  The principle is the same: We need to force packets coming back from sshd going to sslh and not directly back to the client.
+In this case its your decision, where those rules will be tied in, options are:
+
+* the startscript of sslh
+* the docker or kvm configuration
+* the configuration of the outgoing interface
+
+Its two lines you need:
+```
+ip rule add from SSHD_ADDRESS/32 table sslh
+ip route add local 0.0.0.0/0 dev lo table sslh
+```
+On the sshd host, we need no additional rules, as all traffic is coming back to our sslh host, because this is in this setting the default gateway.  The only thing, we need to do: Assign a unique IP address only for sshd and all other services, you wish to hide behind sslh and host on this device.
+
+There are two ways, how you can add multiple ip addresses to one device. The new _**ip addr add**_ supports multiple add statements to one and the same interface name. So you can just duplicate the interface stancas in the _**/etc/network/interfaces**_ configuration. The problem with this method is, that some older managment tools, like ifconfig are unable to show the additional addresses. So when you are used to some older tools, you may configure sub-interfaces like eth0:1.
+However my recommendation is, migrate to new tools, get used to it, as old tools don't show you the whole configuration!
+
+## Example 3 ##
+This is now the extended version of the previous example. The target host has another path back to the client, as there is a default route to another interface. Now we need **TWO** routing deflections, one on the sslh host, like in scenario 2, and one on the sshd target host.
+The routing setup on the target host looks like:
+* Add an routing table name for the deflection table in _**/etc/iproute2/rt_tables**_
+* Find a location, where you will hook the two routing rules in
+```
+ip rule add from SSHD_ADDRESS/32 table sslh_routeback
+ip route add default via SERVER1_ETH1_IP dev eth0 table sslh_routeback
+
+```
+This is setting up a default route for all traffic, originating from the ip address sshd (or any other service) is using, back to the host, hosting sslh. On that host, those packets will be deflected again with the same rule from scenario 2.
+
+## Modifications ##
+Now you can think about many modifications, but the tools will be the same, for all other thinkable scenarios. You must always make sure, that packets from foreign hosts, will find their way back to the sslh host. So if the chain consists of three or four servers, all need the deflection rules. 
+
+## Important Finding On Routing ##
+When I went ahead and wrote in my first drawings the warning, that the kernel in scenario 2 and 3 needs to have forwarding in place, I finally tested, that this is not true. **Both scenarios are working without kernel forwarding beeing activated!**
+The background:  The deflecting routing table cames into the game, before the kernel has to made the decision, that packets with non local ip addresses in source and destination must be forwarded. After the routing rule deliveres the packet to sslh and sslh rewrites the source ip, the packet is treated as local, and can pass the system.

doc/simple_transparent_proxy.md

@@ -0,0 +1,133 @@
+# Transparent Proxy Configuration Using IP Routing#
+This documentation is another explanation of the transparent proxy with the goal, beeing secure and minimalistic. Besides this documentation will explain, how and why this configuration works.
+The explanation will only describe the connection to sshd, so the target sshd can be replace with any other target service, sslh supports.
+
+## Introduction in the data flow ##
+This chapter can be skipped, if you just like to configure things fast.
+This chapter is a little excurse to the dataflow. First point of all is something, which you will unfortunately not see in the nice routing diagrams for iptables or netfilter-tables (nft) like: [Iptables at wikipedia](https://upload.wikimedia.org/wikipedia/commons/thumb/3/37/Netfilter-packet-flow.svg/2560px-Netfilter-packet-flow.svg.png), [Netfilter Flow](https://wiki.nftables.org/wiki-nftables/index.php/Netfilter_hooks#Netfilter_hooks_into_Linux_networking_packet_flows).
+
+Packets from local application talking to other local applications are routed through the loopback-interface. They leave postrouting to lo and reentering from there prerouting, without passing ingress/egress.
+This has nothing to do with the "**route_localnet = 1**" trick, which only makes, that the the local ip range 10.0.0.0/8 gets routed!
+As you can read in many articles, this is nothing you should do, as you may bring your system at risk, because it allows to leak packets from outside to applications, which feel themselves secure, by using those unroutable addresses.
+#### A Simple Simulation ####
+You can prove this behaviour with a simple test:
+```
+# In one terminal start socat as a local echo server
+# this is simulating sshd
+
+socat TCP4-LISTEN:2000,bind=SERVER_IP,fork EXEC:cat
+
+# In the next terminal start another instance of socat,
+# simulating sslh
+
+socat TCP-LISTEN:3000,bind=SERVER_IP,fork TCP:SERVER_IP:2000
+
+# In another terminal you can watch the traffic on lo
+
+tcpdump -i lo port 2000
+
+# In the last terminal talk to the echo server
+telnet SERVER_IP 2000
+```
+You will see your traffic on lo, but not on eth0, if you retry the tcpdump there.
+
+If you setup sslh as non transparent proxy, it will just work, as what we have seen.  
+
+#### Going Transparent ####
+
+In case of transparent proxy however, sslh uses some tricks, to reuse the clients IP on its outgoing interface to sshd. It opens the interface in raw mode, so it either needs to be started as root and drop privileges after binding, or you will need to give some capabilities to the sslh binary (cap_net_bind_service,cap_net_raw+ep), if you will start it as restricted user.
+In this setup we continue, with dropping priviledges.
+
+Doing so, you can send packets to the sshd, listening on another interface, but, the answer packets from sshd will get routed back to the client. This however will not work, as the client would refuse those packets, because they don't belong to a tcp session, the client opened. In most cases those packets would even not reach the client, as source ip addresses from private address space, will be blocked by most internet routers and connection providers.
+
+So its mandatory, to use some tricks, to get those packets back to sslh. All configurations, I have seen so far, are using two components for that. They bind sshd to lo, and than they introduce some firewall rules, to mark packets, originating from the sshd port on lo, so that those packets can be routed in a next step -based on that marking- back to sslh.
+
+##### Drawbacks From Using loopback #####
+This idea has some serious drawbacks: First, you need to allow routing of the local address space, 127.0.0.0/8, with kernel configurations. Search for the string "net.ipv4.conf.default.route_localnet" and you will find lot of articles, why you should not do this.
+By allowing this, you need additional firewall rules, dropping martian packets, which otherwise would get routed to the internet from other applications, running on lo, not aware, that their traffic could be routed.  You need further firewall rules, blocking incoming packets to loopback addresses, as otherwise some applications (especially udp) could be the goal of some bad traffic.
+
+##### Using A Dedicated Interface #####
+So this configuration makes use of a own interface, just for the services, where sslh should hide the traffic for. We use a interface of the dummy kernel module, which was designed just for this case.  It is an interface, beeing there, having no cable connection or whatsever, but applications can bind to it. We assign to this interface just a /32 private address, as this interface is not part of any network.
+
+Doing so, we can avoid all the hassle with marking certain packets, coming from the single applications, sslh has to hide, as we now just route ALL traffic from this specific interface by its ip to sslh.
+We need one routing rule and one routing table, this covers as many targets sslh will serve on this interface, without adding additional rules for adding apache, openvpn and others.
+
+We need no firewall rules, preventing martians, as this single routing rule will deadroute all traffic from this interface, if sslh is not catching it up.
+
+We only need firewall protection for this specific ip address, when we have activated ip forwarding on that system.  If the system is no router and needs no forwarding, there is no protection needed.
+
+## Finally The Configuration ##
+
+As described, we need as a first step a dedicated interface, just for the services, sslh should hide. Its possible, to generate individual interfaces for different configurations, however, that makes things again more complex and has no advantages seen so far.
+
+### Named Routing Table ###
+As we configure the needed routing rules in the interface configuration, we need to define a name for the sslh routing table first.
+Using named routing tables helps, understanding the routing configuration, as a name indicates, why this routing table is configured.
+To do so go to  _**/etc/iproute2/rt_tables**_ and add a line
+
+```
+ 111     sslh
+```
+
+### Dummy Interface ###
+Now we configure our dedicatet interface.
+In the file _**/etc/network/interfaces**_, we place this entry:
+```
+auto dummy0
+iface dummy0 inet static
+    address 192.168.255.254/32
+    pre-up modprobe dummy
+    ## Attention! with kernels, not automatically creating a dummy0
+    ## interface after module loading the following line should be:
+    ## pre-up modprobe dummy; if [ ! -e /sys/class/net/dummy0 ]; then ip link add dummy0 type dummy ; fi
+    post-up ip rule add from 192.168.255.254 table sslh
+    post-up ip route add local 0.0.0.0/0 dev dummy0 table sslh
+    pre-down ip route del local 0.0.0.0/0 dev dummy0 table sslh
+    pre-down ip rule del from 192.168.255.254 table sslh
+```
+As long, as your system has no other interfaces with private address-space, or is routing such addresses, you can continue with the given example. Otherwise you need to select a conflict free address.
+If you are updating a older current configuration, make sure, that you have no longer insecure localnet routing in place:
+```
+ sysctl  net.ipv4.conf.default.route_localnet  
+ sysctl net.ipv4.conf.all.route_localnet
+```
+should both report "0"!
+
+
+### Explanation Of The Routing Rules ###
+The two routing rules in the dummy0 interface configuration are the key for this configuration.
+
+The first line is an routing rule entry, routing everything coming from the dummy0 ip source address to a special routing table _**sslh**_. 
+
+The next line generates this table implicitly, by inserting a single rule, routing everything from that ip address to dummy0.
+
+Opposite to other firewall based configurations, we have those rules now tied to the dummy0 device, dedicated to the hidden services.
+When this interface comes up, the routing rules are making sure, that no martian packets can leave the system, by some processes using this IP address. When the interface goes down, we delete those rules.
+Also the startup script needs lo longer special treatment for the transparent mode.
+
+
+#### SSLH Default Configuration ####
+And finally you need to configute _**/etc/default/sslh**_ with the right settings for all the services, sslh should work for.
+```
+DAEMON_OPTS="--user sslh --listen SERVER_IP:443 --transparent  \
+             --ssh 192.168.255.254:22 --tls 192.168.255.254:443 \
+             --pidfile /var/run/sslh/sslh.pid"
+```
+
+#### Systemd #### 
+This setup is now startup agnostic. As we don't need special treatment in the startup script, the sysV based init scripts will just work, like the systemd scripts. Nothing needs to be modified, when going transparent.
+
+#### Remote Setups ####
+This concept can also be adapted for several setups, where the sshd (or any other target service) is running in a container, kvm-virtual machine, etc.
+Precondition is, that the target system is the next hop and uses the sslh-hosting system as default gateway. In addition you need to bind an additional ip-address, solely used for sshd on the corresponding interface.
+Than you can adapt the routing rule, routing traffic coming back from this ip to the sslh-routing-table.
+Its also possible, to forward to an next hop system, which has its own default gateway back, bypassing the sslh-host.
+In this case, you need to add a special route back to the sslh host, for all traffic with the sshd source ip address. This can be done similar to the two rules described above:
+```
+  # first define a name for the table in /etc/iproute2/rt_tables e.g. sslh-routeback
+  ip rule add from IPADRESS-OF-SERVIE table sslh-routeback
+  ip route add default via IPADDRESS-OF_SSLH-HOST dev eth0 table sslh-routeback
+```
+The details are depending on your network settings. Als long, as the forward chain to the hidden service passes systems under your control, you can add backroutes on each system in that route. Precondition: The used ip address produces no conflict on those systems.
+
+[I added a second document](./scenarios-for-simple-transparent-proxy.md), describing three possible scenarios in detail. Those three scenarios should cover all setups related to transparent proxying. 

doc/tproxy.md

@@ -1,15 +1,11 @@
-# Transparent proxy
+# Transparent proxy using packet marking
 
-On Linux and FreeBSD you can use the `--transparent` option to
-request transparent proxying. This means services behind `sslh`
-(Apache, `sshd` and so on) will see the external IP and ports
-as if the external world connected directly to them. This
-simplifies IP-based access control (or makes it possible at
-all).
+Before reading further, make sure you try to set up
+transparent proxying using [IP routing](doc/simple_transparent_proxy.md).
+It is conceptually easier to understand, cleaner, and more
+portable.
 
-This document shows recipes that may help to do that.
-
-Note that getting this to work is very tricky and
+Using this method is very tricky and
 detail-dependant: depending on whether the target server and
 sslh are on the same machine, different machines, or
 different dockers, and tool versions, all seem to change the

echosrv.c

@@ -163,7 +163,7 @@ void udp_echo(struct listen_endpoint* listen_socket)
             perror("recvfrom");
         }
         *(data + prefix_len + len) = 0;
-        fprintf(stderr, "%ld: %s\n", len, data + prefix_len);
+        fprintf(stderr, "%zd %s\n", len, data + prefix_len);
 
         print_udp_xchange(listen_socket->socketfd, &src_addr, addrlen);
 

landlock.c

@@ -94,6 +94,37 @@ static int add_path_ro(int ruleset_fd, ll_obj_type otype, const char* path)
 }
 
 
+static int add_libs(int ruleset_fd)
+{
+    /* Access to libraries, to be able to fork */
+    add_path_ro(ruleset_fd, LL_TREE, "/lib");
+    add_path_ro(ruleset_fd, LL_TREE, "/usr/lib");
+    add_path_ro(ruleset_fd, LL_FILE, "/etc/ld.so.cache");  /* To avoid searching all libs... */
+    return 0;
+}
+
+static int add_resolv(int ruleset_fd)
+{
+    /* Files to resolve names (required when dynamic resolution is used) */
+    add_path_ro(ruleset_fd, LL_FILE, "/etc/hosts");
+    add_path_ro(ruleset_fd, LL_FILE, "/etc/resolv.conf");
+    add_path_ro(ruleset_fd, LL_FILE, "/etc/nsswitch.conf");
+    return 0;
+}
+
+static int add_libwrap(int ruleset_fd)
+{
+    /* Files for libwrap */
+#ifdef LIBWRAP
+    add_path_ro(ruleset_fd, LL_FILE, "/etc/hosts.allow");
+    add_path_ro(ruleset_fd, LL_FILE, "/etc/hosts.deny");
+#endif
+
+    return 0;
+}
+
+
+
 void setup_landlock(void)
 {
     __u64 restrict_rules = 
@@ -124,15 +155,11 @@ void setup_landlock(void)
         return;
     }
 
-    /* Access to libraries, to be able to fork */
-    add_path_ro(ruleset_fd, LL_TREE, "/lib");
-    add_path_ro(ruleset_fd, LL_TREE, "/usr/lib");
-    add_path_ro(ruleset_fd, LL_FILE, "/etc/ld.so.cache");  /* To avoid searching all libs... */
 
-    /* Files to resolve names (required when dynamic resolution is used) */
-    add_path_ro(ruleset_fd, LL_FILE, "/etc/hosts");
-    add_path_ro(ruleset_fd, LL_FILE, "/etc/resolv.conf");
-    add_path_ro(ruleset_fd, LL_FILE, "/etc/nsswitch.conf");
+    /* Add all the paths we need */
+    add_libs(ruleset_fd);
+    add_resolv(ruleset_fd);
+    add_libwrap(ruleset_fd);
 
     if (prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0)) {
         print_message(msg_config_error, "Landlock: Failed to restrict privileges");