IMHO something like this is best done by hiring professionals, as some random person may or may not have the experience and skills they may or may not suggest, giving you a false sense of security in their findings.
Anyway, having said that, having a poke around yourself is always fun and interesting and can also mean you can evaluate the results from an external audit yourself. It looks like you've run an nmap over your external IP address, which is a good enough start, however you might also be interested in running a nessus scan. http://www.nessus.org/download/ You should be careful though as some attacks this generates can crash your services, so don't run it at popular user times. Generally though, these should be referred to as 'Active scan' whilst a 'Passive scan' won't try to inject code etc, but enumerates services versions etc and can point you to information on known vulnerabilities. It's been a very long time since I've played with this, but it used to be very much user contributed scan codes so you couldn't trust a passive scan was not going to do something nasty, this may have changed. Anyway this is really recommended to try, although it looks commercialized since I used it, but it looks like you can still download and try it. Also, if you are not using PPTP and port 20,000 turn them off. PPTP may have a weakness that will put an attacker on your network, by passing some firewall rules. PPTP is generally not considered secure anymore anyway, although I don't have any details at hand, and again, my info is all very old. A quick google for port 20,000 show up a possibility that this is Usermin, some derivative of Webmin, and if so you should really block access to this. I should say this again - if you are not using these extra services turn them off! It will not look good if some pen tester breaks in here and is then able to say the setup is insecure, despite this having no relation to Moodle itself. The department wont want to understand this difference and any attempts to justify that this is not necessarily insecure but is related to your network security, not your application security will fall on deaf ears since they have a report with a lot of jargon and the words insecure on it, especially if the whole thing is politically charged as you say it is. Anyway, that's my 2c, good luck! On Sun, Nov 1, 2009 at 8:58 AM, Rick Phillips <r...@greyheads.net> wrote: > > Just of out of interest, what kind of server are you talking about ? > > > > It's a CentOS 5.4 box. Briefly, we have been running this server for 5 > years principally to serve learning materials to students. Initially, > the server was sanctioned by the Education Department and it has grown > in usefulness and reliability and contrary to the official LMS run by > the department, is very easy to use. We run Moodle which is free, they > run Blackboard, which is not. The success of our Moodle is proving to > be of some embarrassment to them now as other schools are pushing for a > similar situation as our own and now they want our service closed down. > They claim that our server is a security risk because it connects to the > inside network as well as the outside network. Each connected network > uses a different range of addresses which are unbridged. A firewall > allowing only one way traffic protects the inside network to the server. > ie. the Moodle server cannot initiate any call on the inside network - > it is blocked. Only calls coming the other way can be serviced. Only > the following ports are open to the world plus one secret non standard > one for administration via ssh: > > 80/tcp open http > 443/tcp open https > 1723/tcp open pptp > 2000/tcp open callbook > > Ports 1723 and 2000 are not specifically opened by myself but seem to be > factory set open in the firewall device and out of my control. Only 80 > and 443 point to the server which sends but does not receive mail. > Using hosts allow and deny, connection is restricted to my private IP > address for external admin purposes via ssh. Both passwords are complex > and root logon is not allowed. > > I believe that we are well locked down but that does not mean that some > form of code injection might not be possible. The system is religiously > patched as soon as patches are available and I read the detailed logs > daily. I run a rootkit detection program from time to time. > > The department is employing a "white hat" to do a penetration test at > the end of this month and we thought it would be better to be fore > armed. This LMS is very important to us and has significantly helped > our student base lift their average results to be near the top for the > state. They have guided learning available to them both at home and at > school. We would hate that one mistake on my part would give the > department the excuse they need to shut us down. > > We know there is money involved and we are looking for a trustworthy > company or individual to do the job without destroying our server and > who will advise us where our weaknesses, if any, lie. > > Perhaps I am being naive and simplistic in my approach. > > This is a serious matter for us and I certainly didn't appreciate last > night's reply to the list. > > Rick > > -- > SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ > Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html > -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
