DO NOT ALLOW PUBLIC ACCESS TO THIS PROGRAMME
BACKGROUND
DBMA does not require any special permissions and should run with the HTTP server's
user and group credentials. (i.e.: www:www or nobody:www or whatever you are using
-- see your httpd.conf file or ask your Senior Sys Admin or team lead).
Who says, 'We're secured.'?
Perfect intranet admin system security is a worthy but an unattainable goal.
Every circumstance has its own unique advantages and deficiencies
including public physical plant access, ex-or-disgruntled employees, pranksters and
penetration from outside.
Securing any system is a living, dynamic process -- checking for and applying operating
system updates, program fixes and patches, scanning programme revisions for desirable
feature additions, reviewing user security and permissions, and generally applying common sense.
Whatever secure environment you use for your enterprise or network management,
using your own privileged user and permission sets, would be a good place to
use DbMail Administrator (DBMA).
If you do not yet have such resources and are installing DBMA into a new or
existing Apache Server on your workstation, the following notes might be helpful.
Think about your database security.
Security of your MySQL or PostgreSQL database is outside the
scope of this article but it should be noted that the username and password
are set in a small flat-file database which is NOT world readable.
Make sure there is no unauthorized access to the namespace in which DBMA resides.
Also, the credentials you use should only have access to the dbmail database
and should not have GRANT permissions, in fact should only have minimal
read/write permissions for the DbMail Db. That's all that is needed.
Some simple "How To's"
1) Configure your HTTP server to listen on localhost or its
non-routable LAN IP address, preferrably on a non-standard port. If you run
your system administration and enterprise management on a VPN, see
your Enterprise Manager and get the needed approvals and configuration details
before installing this product.
example:
Listen 192.168.1.10:80
Bare Essentials
2) This discussion will assume that:
i. LAN is secure; firewalled; your admin workstation in a controlled environment.
ii. The operating system has been secured and unnecessary services disabled.
iii. The Apache user and group directives are correctly set, appropriate permissions assigned.
iv. The ServerRoot and log directories are protected.
v. User overrides are disabled.
vi. You are using the latest release of your HTTP daemon software (i.e.:Apache]
To Alias or Not To Alias? That is the question.
3) CGI access is a somewhat contentious security topic.
Arguably, the isolated (ScriptAlias directive) cgi-bin in Apache is deprecated because of the
demand for dynamic content throughout the modern site.
Many public sites offer dynamic content these days and most admin intranet sites are
entirely dynamic. You can run CGIs from the web root or any directory you may wish to use, with care.
Ideally you would assign the ExecCGI Option to subdirectories of your document tree on an as-needed basis.
This offers a strong measure of security inasmuch as no one but the creator has knowledge of where
scripts will run and where they won't.
Why not "cgi-bin"? There is little reason why, for one thing.
For another, the ubiquitous script directory is easily found.
The default location of Apache server's CGI scripts is an aliased '/cgi-bin/'.
There is no valid reason to use cgi-bin as a script location and many reasons to remove this
and the "/script" directory from your web space so that html
GETS and POSTS from automated web script malware are issued a "Not Found"
error message and thus are stopped dead in their tracks.
Surely this is not going to be an issue on your LAN IP workstation server, you might think.
It could be in the event of an inadvertency whereby someone makes a mistake on a
firewall IP forward NAT. OK, so that is improbable but lets just say that it is good practice
to make as secure as possible any information or information technology you are entrusted
with. That includes people's emails and email access credentials.
To accomplish this, delete or comment out (with #)the CGI-BIN ScriptAlias in httpd.conf.
example:
#ScriptAlias /cgi-bin/ "C:/apache2/Apache2/cgi-bin/"
#<Directory "C:/apache2/Apache2/cgi-bin>
# AllowOverride None
# Options None
# Order allow,deny
# Allow from all
#</Directory>
Add ExecCGI on an as-needed basis.
Sample DBMA Directory Config in httpd.conf file
===============================================
<Directory "/usr/local/www/dbmailadministrator">
Options MultiViews ExecCGI
AllowOverride None
Order allow,deny
Allow from 192.168.100 10.10.10 localhost mydomain.net
</Directory>
Don't be hum drum. Get creative with your CGI file extensions
4) Extensions are dead giveaways.
Although this is an unlikely concern on your LAN workstation, you might
enjoy knowing you have taken one, extra, clever step toward providing
enhanced security for your administrative GUIs.
I could easily argue that .cgi is a deprecated extension by using
widespread common practise as a case in point.
Public site webmasters avoid it like the plague. And why not? Every
'script-kiddie-wannabe-thug' on the planet has tried to exploit
something.cgi at one time or another and there are now a gazillion
computers infected with any one or more of a gazillion malware types
scanning net blocks for something dot pl or dot cgi.
CGI files are most often PERL or C. The more information you give up about your server,
the more vulnerable it becomes.
You don't need to use .cgi as an extension. You can use any non-standard
extension your heart desires as long as you tell your HTTPD daemon how to
handle the file when a request is received. You can also use as many different
extensions as you like. Just tell the server what they are with AddHandler instructs.
Once the HTTP Daemon reads its correctly configured AddHandler instructions,
it will handle files with your non-standard extension accordingly.
The Common Gateway Interface (CGI) was a Noah's Arc standard for communication
between a program or script, written in any one of several languages, and a
Web server. The CGI specification is very simple: input from a client is passed to
the program or script on STDIN (standard input). The program then takes that information,
processes it, and returns the result on STDOUT (standard output) to the Web server.
The Web server combines this output with the requested page and returns it to the
client as HTML. CGI applications do not force the server to parse every requested page;
only pages containing CGI-recognized arguments involve further processing. As long
as your server knows which files to process as CGI, it will.
You are not going to be exposed to atackers inside your LAN, you may think.
And you most certainly are not allowing DBMA or any Admin application to be
run on a public-access server. So it's a best practises thing if you can find
no other reason. Well, you know your situation best and will take the security
measures commensurate with your circumstance.
This is certainly not a "must do" scenario.
To change the file extension of your DBMA CGI executeable scripts , use the following or
something like it in your httpd.conf file
AddHandler cgi-script .dbma #or whatever extension you wish to use.
Next rename all cgi scripts in your package to have a dbma
(or whatever you choose) extension.
>mv *.cgi *.dbma
Password Protection Is Important; A "Must Do"
5) Password protection has considerable value.
I suggest that you do password protect DBMA. The inconvenience is inconsequential
and the professionalism of doing so is good for your image among your
peers, and more importantly, the boss. You can password protect your entire
intranet web space or selectively
protect different name spaces with different authentication levels.
Sample htaccess config in Apache's httpd.conf file
===============================================
<Directory "/usr/local/www/dbmailadministrator"> # change for your system
AllowOverride None
Options ExecCGI MultiViews
Order allow,deny
Allow from all
AuthUserFile /usr/local/www/dbmailadministrator/.htpasswd # change for your system
AuthGroupFile "www"
AuthType Basic
AuthName "Administration Only. Enter username and password."
require valid-user
order allow,deny
</Directory>
Change the namespaces to the correct location on your system.
TO CREATE A PASSWORD FILE
===============================================
>cd /usr/local/www/dbmailadministrator
>/usr/local/bin/htpasswd -cb .htpasswd user secret
Produces .htaccess containing something like this:
dbmail:xW52d90QZt5ig
(password is dbmail)
SUMMARY:
You may have some additional thoughts.
There certainly are additional dimensions.
For example, Apache comes bundled with its own security CGI wrapper
application called suEXEC. suEXEC allows users to run CGI and SSI
programs as the owner of the site as opposed to the owner of the httpd process.
This is not needed for DBMA V2.0 as it can run as the site's user:group with read
permissions on all but the scripts which need executeable access.
If you are using DBMA V1.1 you may wish to build it into a CGI wrapper.
You can read more about suEXEC at http://httpd.apache.org/docs/suexec.html.
Feel free to ask for help or make your comments.
M. J. [Mike] O'Brien ~ Email
|