Quote:
Originally Posted by unclesamcrazy
Lots of things are installed on it like openfire, webmin, ftp, ssh, mailserver(smtp), svn, apache, mysql etc
It shows them like an open book, anyone can know list of installed programs through ports and try to break them.
|
Learn that scans will happen and since you do not control remote end points you can not
prevent them from happening. Having a router in front of the machine may restrict access using isolation (DMZ) and limit access by carefully choosing the ports to be forwarded (also see
reverse proxy).
So. What you should do
first is harden your machine according to your Linux distributions (security) documentation. That step should include anything from using separate unprivileged user accounts, strong passwords, no root access but pubkey-only SSH access via unprivileged users, setting up regular auditing and reporting etc, etc. and testing your setup from remote, to make the machine more resilient. This step should never be skipped for networked machines.
Building on top of that
next determine which services need to be exposed (publicly for all, limited access or not at all) and
then set access restrictions accordingly. For example you should not expose certain services until they're actually used from remote like MySQL (make it use a UNIX socket) and there is no valid reason (at all) to expose certain services like Webmin and OpenFires web-based administration panels publicly (firewall IP address range white listing, .htaccess).
Also be aware a web server may provide multiple points of entry due to what services it provides: statistics, shopping carts, photo galleries, bulletin boards, web logs, any (third party!) themes and plug-ins all should be secured according to 0) system, 1) web servers
and 2) product documentation, next to general recommendations or Best Practices.
If you need to provide certain services to the world then see if you can get away with providing only the SSL-ized version (IMAPS, HTTPS, FTPS) or providing access via a SSH tunnel. Make them use rate limiting, have fail2ban or an equivalent and Logwatch watch logs for anomalies and attacks.
If and when you have done all of that,
then you can concentrate on probes and scans that successfully penetrated your setup. Not the other way around, that's simply not an effective admin approach.