Skip to content

Instantly share code, notes, and snippets.

@con-f-use
Last active September 25, 2021 13:13
Show Gist options
  • Save con-f-use/9981a87d7829423475b315865512068a to your computer and use it in GitHub Desktop.
Save con-f-use/9981a87d7829423475b315865512068a to your computer and use it in GitHub Desktop.

LDAP behind the WALL

Let's preface this by saying, that I'm indeed a very, very evil man, and the following does not correspond in any way shape or form to a real setup in the acutal realm of living breathing things. Nor should it. Ever.

The Premise

So, we want a service on a machine - let's call it smelldap, for no particular reason - to be accessible. Only problem is, the machine sits behind a(ll the) firewall(s). It is, so to speak, inside a gated community, and our poor client is not allowed in. Particular cruelty has it, that this pitiful abandonee can't even see inside, can never meeting any of the elecronic denizins within that it so wants to authenticate. Such curelty cannot stand! Let us help the pitiful fella...

Meet sebastion the bastion host paragon of virtue in our stinky smelldap network. Heroically, sebastion will ssh to our client, who in turn, somewhat paradoxally learns a new trick and becomes a server. A server of the secure-shell variety. Ssh! Quiet!

On sebastion's way there, he will bring a gift, a remote port forward from smelldap, and thus the poor client will smell the free air of our oppressive community, not so gated anymore. Isn't that delightful!

Users

To give that a measure of secuirty (Lipstick on a pig, I know), we will configure service users, no shell, no login, no password, no home, mind you, on both sebastion and the client. I lovingly call these users "hobos".

me@sebastion~$ useradd --no-create-home --system --shell /bin/false shobo  # usermod -L shobo
me@client~$ useradd --no-create-home --system --shell /bin/false chobo

Network Isolation

All packets from the hobos that don't go to either sebastion or the client or smelldap will be dropped as if underpayed UPS goons handled them. Mistreating the packages will be iptables "job", though - probably with comparable pay.

iptables --append OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# create a new chain
iptables --new-chain chk_hobo_user

# use new chain to process packets generated by the hobo user
iptables -A OUTPUT -m owner --uid-owner chobo -j chk_hobo_user  # or --uid-owner shobo if you are on sebastion
iptables -A chk_hobo_user -p tcp --syn -d <smelldap_ip> --dport <allowed_port> -j RETURN
iptables -A chk_hobo_user -p tcp --syn -d <sebastion_ip> --dport <allowed_port> -j RETURN
iptables -A chk_hobo_user -p tcp --syn -d <client_ip> --dport <allowed_port> -j RETURN

# reject everything 
iptables -A chk_hobo_user -j DROP  # it like it's hot or delivered by UPS
# or ... REJECT like our poor client was 

SSHD config

The client needs sshd running with options:

AllowTcpForwarding yes
GatewayPorts yes
PasswordAuthentication no

# Need /etc/ssh/authkeys_by_user/%u for authentication of service users that have no home directory
# The first two path are the defaults
AuthorizedKeysFile  .ssh/authorized_keys .ssh/authorized_keys2 /etc/ssh/authkeys_by_user/%u

and be accessible from sebastion only via well kept, secured ssh-key-pairs, used exclusively for that purpose. None of that password rubbish.

me@sebastion~$ ssh-keygen -t rsa -b 4096 -o -a 100

...or something, paste the public (!) key to chobo's authorized_keys file at client /etc/ssh/authkeys_by_user/chobo. These keygen options are sensible defaults at the time of writing. They offer a good balance of portability and security. Future people might rather want to use elliptic curve ciphers. You should look up what is secure when you do this.

Bastion Host

And now for the grand (grant) finally, sebastion is up granting access to smelldap:

me@sebastion~$ sudo -u shobo \
   ssh -i id_rsa -o UserKnownHostsFile=client_only -o StrictHostKeyChecking=yes -R '*:9999:smelldap:3269' chobo@client

You could bind it to 3269 as well, instead of 9999 on the client but that would require privileges and we don't want hobos to have them.

Now, not without a measure of communism, smalldap's 3269 (nice!) can now be accessed from any of client's IPs over the port 9999. You might want to restrict that to a specific IP and use iptables for further restrictions from outside IPs in the client network. Autossh can help you keep that port forwad stable. Enjoy!

And yes, 3269 is really an LDAP default port.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment