I had a long beef with these « experts » that basically want to control everything you do while being totally pedantic idiots. They are often Ivy leagues student with a degree in Computer Security that define themselves as white hat.
One of their claim is to be embedded in design decision early to make sure new products are secured. Let's prove this claim is utter bullshit by « over securing » (one way that is a tad trollesque) a clear text protocol which server is in bash.
To wrap up :
- First we made a pubsub server in bash served with djb tcpserver
- Then we were able to migrate it to socat
- Then to rejoice the FreeBSD 15.0 to come, we installed it in a freebsd thin jails based on openZFS run on qemu
- and we fougth our way againts network manager to brige nicely (without a VLAN, sorry) the linux host and the freebsd guest
Define « securing », pliz
In the head of the software architect securing is :
- confidentiality (making sure evedropping is tough)
- AAA
- Authentication : people must be identified to use the service
- Authorization (also called Role Based Accounting) : you must be able to have distinct users that don't see each others
- Accounting : login/logout must be logged in a « standard way » that can be consolidated on an external computer
- containerisation : if your service is broken, you should ensure your whole infrastructure is not compromised
- it should avoid ressource exhaustion
- you should provide safe API to the users
Thus, now, let's secure it.
SSL tunneling : I love socat bis, terse documentation, but SO ... GOOD
We EXACTLY Follow the certificate generation such as written here : http://www.dest-unreach.org/socat/doc/socat-openssltunnel.html.
It of course REQUIRES you have a DNS with a local zone resolving the A and PTR (reverse operation giving the name for the IP address locally). I have an unbound server already set for adblocking thanks to a ... bash script of my own I can add it a small zone with both hostname that will be THE only required information to have valid self signed certificate based on the common name (common name = host name).
I could argue that authentication per SSL certificate is strong and my job is done. But, it does not handle Authorization and accounting. What would be nice ... Would be ... groups, login/pass and accounting.
Exactly what /bin/login provides for the authentifcation and accounting and what unix groups/home dir provides :D. No new tools required.
All this is condensed in THIS
The client side
socat READLINE OPENSSL-CONNECT:pubsub.home.:2023,cert=./client.pem,cafile=./server.crtWe politely let socat do the job after we set the DNS virtual address address of pubsub.home (the jail) in the local zone.
The server side
Since the jail is setup we just need a simple rc.d script :
#!/bin/sh . /etc/rc.subr name=pubsub rcvar=pubsub_enable desc="pubsub server" start_cmd=pubsub_start stop_cmd=pubsub_stop : ${pubsub_enable:=no} load_rc_config $name command=start_cmd pubsub_start() { echo "pubsub started." su -m serve -c '/usr/local/bin/socat \ OPENSSL-LISTEN:2023,cert=/home/serve/server.pem,cafile=/home/serve/client.crt,fork,reuseaddr \ EXEC:"/usr/libexec/getty Pc",ctty,pty,stderr' & } pubsub_stop() { echo "pubsub stopped." killall socat } echo hello run_rc_command "$1"The socat invocation will listen on port 2023 and use the client certificate in conjonction with its key to secure the connection and fork a new pseudo login tty for each connection.
Hence, given that /etc/bash_profile is :
while [ 1 ]; do /home/pubsub/pubsub.sh exit doneYou add in the jail
sysrc pubsub_enable="YES"And restart the jail and the job is finished.
New account are added with user sharing the same group, /home/pubsub path, and umask at the beginning of the script thanks a sticky bit on the group will ensure that rights are without conflict.
And you can create new users sharing different channels, thus having distinct users possible on a mutualized platform.
All login access will be logged in /var/log/auth.log giving us accounting.
It's basically a pseudo telnet protocol over ssl and a pattern to develop fast when manipulating sockets bores you to death, whereas using stdin/stdout is darn simple.
But ???!!!!
Of course, it's half baked, it lacks the rotation of the channel and reeks of ressource exhaustion, but ... if I would be a company I would devote time later to this, I would probably freeze the pubsub with a SIGHUP trap handler and ask them to kill all their files they follow, sleep, rotate the file, and resume following them (which require an additionnal associative array). Else, we have everything by using a layered design where every layer does it's part of the job : TCP does the transport, SSL the ciphering and one authentication, login+unix groups provides AAA (Authentication, Authorization, Accounting) and the jails a container that can be further hardened thanks to pf.Security, does not need to be a first thought, security engineers give us very nice tools that can be composed at the best level possible which is the Operating System and its base.
I find the devops hype tiring because abstractions are leaky and each level are coupled in insane ways for the sake of not knowing where your money goes and funnel a lot of money out of both their companies and customers, but we actually can work with 300Mb of memory on small instances of mutualized iron. So I think I proved securing a prototype in a decent way as a second thought can be done fairly easily.
But the joke is not over, a protocol is not over ... until you provide a python library for the protocol. And believe me, it holds in 85 lines of code.
No comments:
Post a Comment