*NIX SSH based "BBS" (Free Shell Server)
Posted 20 June 2010 - 05:08 PM
in another Forum Frog asked how to go about creating a "BBS"
(This first Post is an Overview)
Well a modern similar related concept of this is a modern shell server deployment.
( You may have encountered various free shell sites such as metawire (now defunct) and SDF, (Still going )
Both of which have/had their own enclosed communities within the realm of a live server offering up terms .
While of course a classic BBS is telephony only with a community encapsulated off the net, these days its a bit pricy
to run telephone lines etc .
The closest thing to text only shell content that comes to mind is a Free shell service. Want community isolation ?
Use localhost only text based services. (ie for example a web server that only listens and serves content on the localhost)
With internet laws becoming even more draconian , one could even encourage the use of such a shell server with ssh over TOR
anonymity apps .
(Keep in mind however, TOR isn't always safe either )
So with only a modest sign up web page facing the internet and ssh only public login access,
One could grant access to user accounts with a custom written menu driven shell script set as a system shell that vaguely resembles an old school "BBS"
Thus the "BBS" becomes more of a complete Unix system merged with BBS like shell scripts .
limiting actual shell access is probably a good idea.
With modern day virtualization and segmented OS instances, one can both offer a Freeshell/BBS like service with the added security layer of virtualization.
This is where my favorite *NIX OS comes in . Solaris 10.
So you have a Solaris 10 host (Full blown server)
On the Global zone, you enable resource pools and the Fair Share Scheduler to better control system resources.
Then you have a whole array of public / private facing zones.
The tricky catch being that each zone has multiple network "interfaces" allowing for private
back end communication .
Each zone has hard and soft resource limits set so the system never becomes completely overloaded (in theory)
Verboten. No one can log into it directly from a public IP. (must be accessed via console or some other non public facing secure measure)
The global zone is used solely to monitor system resources and other zones.
(or internal private NFS server for auto_home use on zones )
ssh login zone
Sole purpose is to be the front end portal for ssh logins and front line login available on both public/private facing networks
public/private facing zone that runs as a TOR relay and/or TOR exit node (get a legal department if you run a TOR exit node lol )
private web server zone
Host all web based content with no direct shell access to the general free shell public internally
public web server zone
all public facing web content externally
mysql db zone (private)
mysql server zone
mysql db zone (public)
mysql server zone
IRCD zone (private)
zone that hosts IRC comms internally (not public facing for extra security)
depending on your model, a private or public
Identity management ?
There is a few ways to go about doing this. You could either
run an internal private facing LDAP server zone ( and be extra vigilant on security )
or propagate /etc/passwd , /etc/shadow copies between zones (a bit more secure but prone to error and other problems)
Use RBAC profiles or conversely limit su - to a specific group one must login to . These concepts could be used both on zones and global .
Just a high level overview of how to setup a "BBS" like secure shell server with zones.
- likes this
Posted 20 June 2010 - 10:28 PM
Posted 21 June 2010 - 01:01 AM
Thanks to Aghaster, I'm a big Solaris/Opensolaris fan. I love how powerful zones are, especially when combined with crossbow. In fact, my site, 0xfeedface.org, is running in a non-global zone. I think your setup is a bit complex. Zones make isolating services easy and secure. However, there is such a thing as too much. Administrating all those zones would be cumbersome. Keeping each up-to-date would be next to impossible. (well, okay, it'd go something like this in the global zone: zoneadm detach zoneName1...N && pkg image-update && reboot -f && zoneadm attach -u zoneName1...N).
A Complex design ?
Yes, but not unlike your common corporate production deployments , and not very hard to admin . (Especially with centralized Identity management and Global Zone tools )
Yes, some of the zone deployments I mentioned could be consolidated , but the fact that you could set it all up that way adds layers of increased customization + security.
- likes this
BinRev is hosted by the great people at Lunarpages!