Page 1 of 2 12 LastLast
Results 1 to 10 of 11

Thread: Covered all basics?

  1. #1
    Member
    Join Date
    Nov 2007
    Posts
    220

    Default Covered all basics?

    I know this isn't BT related, and even though there are a lot of hacking/security forums out there there are also a lot of gobby idiots that post without knowing the first thing.

    A friend of mine has just rented a server and asked me to configure it for him, I have done and was wondering if anyone would mind reading what I have done, and either suggest an improvement on how to make it more secure, or comment on what I have done and try to find any flaws, kind of like grading me lol.

    Not saying I will do what people suggest, but would love to a) hear peoples opinions, and b) give some people an idea of things to do with doing something like this.

    -----

    From a list of OS's I asked him to pick Fedora, I was given the ssh IP, username,
    password.

    First thing was lock down services, stopped them listening on 0.0.0.0, all now listening on 127.0.0.1 (except ssh)

    Then installed apache, mysql, php, each time giving the root/admin a very strong password

    Then improved SSH to use rsa instead of password, this is now implemented (although still accepting root access and password access I am testing current config before disabling these, however I will force users to login then su/sudo)

    The private rsa key also has a passphrase associated, I have also encrypted this (with the same password as the passphrase) and emailed to him

    I sent him a txt msg with the password in...

    ...and a forum pm with config options, IP address, etc etc

    So all three bits of medium over different methods

    So the way I see it... only port open is ssh, this is (will be) using rsa, the private key is emailed to a seperate destination than the encryption password (stopping anyone hacking into email and getting the key (even though no IP to use it against))... the id_rsa uses a passphrase stopping anyone who can steal files from local drive through a trojan etc

    This means file sent is encrypted, decrypted file still needs passphrase, this file is needed to create a SSH tunnel to to the local IP and port 80... resulting in the servers web service only being accessible to anyone who can do the above?

    I have removed the server hosts access from SSH (more pride/one up man ship than security lol)

    When I upgrade/update firewall it will only listen for SSH from the IP block of my ISP

    For this post I want to avoid the point of holes in software.... any software can have bug, or hole, but this is not point of this thread.

    For the sake of this all permissions on the web site are 770 with chown of root:apache



    I think this is it... however I reserve the right to add other precautions I have already performed lol



    Any thoughts opinions ideas concepts more than welcome

    PS - Merry Xmas lol
    wtf?

  2. #2
    Jenkem Addict imported_wyze's Avatar
    Join Date
    Jul 2007
    Posts
    1,543

    Default

    I'd say you're on the right path (although not knowing what the _actual_ config's look like).

    Also, I see no mention of active / proactive monitoring software <search/>.

    Backups?


    My list might appear to be short and slim, but the rabbit's hole gets deep.

    Merry Scientoligistichristmahakwanzasatanadon!
    dd if=/dev/swc666 of=/dev/wyze

  3. #3
    Member
    Join Date
    Nov 2007
    Posts
    220

    Default

    Yes next is to look at the config files and try and harden them a little

    Monitoring as in IDS? I have thought about automatic emails when anyone logs in through ssh (only service open).... so even if someone logs in and turns them of I knew they got in... though Im sure this is more security through obscurity than proper security

    Yes when all done I will write a bash script or something to backup crit files, mostly config files

    Thanks for input
    &#119;&#116;&#102;&#63;

  4. #4
    Developer
    Join Date
    Mar 2007
    Posts
    6,126

    Default

    Nagious is used for this sort of thing as well.

  5. #5
    Member
    Join Date
    Nov 2007
    Posts
    220

    Default

    OMG not nagios, I love it, but HATE trying to configure, wrote a few new plugins where I work, checking swap and AV def file age... and getting them to work with NRPE was a nightmare !! lol

    Are you meaning using Nagios to report intrusion or availability?
    &#119;&#116;&#102;&#63;

  6. #6
    Just burned his ISO
    Join Date
    Jul 2006
    Posts
    18

    Default

    Nagios is good once you get some decent templates set up. Then it's not such a nightmare.

  7. #7
    Jenkem Addict imported_wyze's Avatar
    Join Date
    Jul 2007
    Posts
    1,543

    Default

    Nagios is _ok_. Also look into Cacti, OSSEC, PSAD, monit, etc etc
    dd if=/dev/swc666 of=/dev/wyze

  8. #8
    Member
    Join Date
    Nov 2007
    Posts
    220

    Default

    As much as I love Nagios and its uses (as said, the company I work use it extensively) I am not trying to monitor the server uptime or availability (yes it can monitor whatever you want, uptime, service availability, ssh logins, scans that are lgged in files etc etc etc etc) its not what I am aiming at here, more after general ways of securing a server, dont mean to come accross as rude, just steer thread in right conversation x
    &#119;&#116;&#102;&#63;

  9. #9
    Jenkem Addict imported_wyze's Avatar
    Join Date
    Jul 2007
    Posts
    1,543

    Default

    Quote Originally Posted by Andy90 View Post
    I am not trying to monitor the server uptime or availability
    (yes it can monitor whatever you want, uptime, service availability, ssh logins, scans that are lgged in files etc etc etc etc) its not what I am aiming at here, more after general ways of securing a server, dont mean to come accross as rude, just steer thread in right conversation x
    No offense, but you obviously need a lesson in defense in depth if you think that building a trump tight server doesn't require monitoring of some sort. Securing a server does take a bit of proactiveness and situational awareness, especially in the professional world.

    Bottom line, don't run what doesn't need to be run, tighten up the conf's, keep the box up to date, and use appropriate tools to monitor the server / services / logs / essential files (and changes to them)... are some very crucial elements.

    There are also many other tricks that one can deploy for boobytrapping, which I won't get into without a service agreement and a bucket of hours prepaid
    dd if=/dev/swc666 of=/dev/wyze

  10. #10
    Member
    Join Date
    Nov 2007
    Posts
    220

    Default

    Quote Originally Posted by wyze View Post
    ...which I won't get into without a service agreement and a bucket of hours prepaid
    lol

    Quote Originally Posted by wyze View Post
    Bottom line, don't run what doesn't need to be run, tighten up the conf's, keep the box up to date, and use appropriate tools to monitor the server / services / logs / essential files (and changes to them)... are some very crucial elements.
    All services I dont use (DNS, mail, ftp, etc), services I do run (httpd, mysql) are only listening on 127.0.0.1 (instead of ssh that is listening on the real IP)

    Up to date, done

    Tighten conf's.. something I am doing albeit a little unexperienced at

    Monitor logs - I do, and will write my own script (if I were to use Nagios I would still prob have to write my own custom script for it)

    Monitor conf files - not covered this, will look into something

    From what I read you are saying that I am missing a huge chunk not wanting to use Nagios.... but If I am to write something to do my stuff, then what use it Nagios? I dont care about remaining swap space, ping speed, qmail queue size etc.

    I am set to configure the firewall to log any hits to specific ports and will write a script for that, also tie that down to source block of my ISP (I dont hav a static )
    &#119;&#116;&#102;&#63;

Page 1 of 2 12 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •