1. Advertising
    y u no do it?

    Advertising (learn more)

    Advertise virtually anything here, with CPM banner ads, CPM email ads and CPC contextual links. You can target relevant areas of the site and show ads based on geographical location of the user if you wish.

    Starts at just $1 per CPM or $0.10 per CPC.

General Security - a MUST Read

Discussion in 'Security' started by DarkMindZ, Dec 23, 2007.

  1. #1

    This is just general security that you should know::


    [-] Shared Hosting?

    if you are on a shared host, means you have other websites on the same server, you can never be too paranoid.

    that's why, if you run a CMS / Forum, anything that needs MySQL access. most probably your password is plaintext in a file.. and all the sites on that server, most likely can have access to that file... sucks eh?


    well, there are some solutions:

    - Move the config file `that contains the pass / user, to the user directory.. example:

    /home/darkmindz/public_html/config.php << thats where it usually is..

    you can move it to:

    /home/darkmindz/config.php

    that makes it really harder on the attacker to get the file, unless he roots the server, or knows exactly what the filename is...

    next solution is:

    encrypt your files,, you can use Zend or IonCube, or some other custom encryption..you can look that up, we are not going deep into it.

    [-] Been Hacked?

    Well, if you have been hacked once, you cant just get your backups up, and move on with your life.. wrong!

    you will need to look for backdoors, if you can delete ALL the files on your site, and get new files from a backup, it would be much better, but if you cant, then you need to check for the files the `hacked` could have edited... in most cases, the `hacker` would be using a c99 PHP-Shell to go over your files and edit them.

    so, lets see what files he could have edited, you can do that by looking in your SSH / FTP for writable. an easier way, is just to look at your files the way the `hacker` saw it..

    you can upload a c99 PHP-Shell to your site, and look for the green perms files, those are editable, then you can either replace those files with new ones, or if you know what to look for, then open them up and look for backdoors left by the hacker..

    Now, I dont really have to say this, but..

    Change all your passwords. FTP, SSH, cPanel, Admin panel. EVERYTHING.

    [-] The best way to secure your self, is to know what the attacker is looking for.

    Yea, Read some webhacking tutorials, we have a bunch of them here, this is what all / most hackers read, and go after your site based on it...

    once you know what they are looking for, you can find a way around it, maybe in another tutorial I will discuss securing your webapps.

    Okay, that was a basics of what you need to know / do, to keep your site secure, we will go more into it with webapps security, comments and suggestions are welcomed :)

    Source: www. darkmindz .com/forum/general_web_security-num219
     
    DarkMindZ, Dec 23, 2007 IP
  2. just-4-teens

    just-4-teens Peon

    Messages:
    3,972
    Likes Received:
    168
    Best Answers:
    0
    Trophy Points:
    0
    #2
    nice post, most of the above is common sense that you learn after a while, but defiantly a food post.
     
    just-4-teens, Dec 23, 2007 IP
  3. bturkay

    bturkay Peon

    Messages:
    75
    Likes Received:
    3
    Best Answers:
    0
    Trophy Points:
    0
    #3
    Nice article..But if you set the correct permissions for your config files there is no need to be afraid..You can use 644 for config files so nobody other than you can access them without accessing your account via FTP or SSH.

    If you use strong passwords and correct permission settings,you will be okay..

    Also dont forget to backup your sites daily or weekly..If you are using cPanel,the backup generator at cPanel will help you so much..

    Also while trying to choose a hosting company ask them how often they backup the sites.There are so many hosting companies that backs up the accounts daily/weekly/monthy basises..
     
    bturkay, Dec 23, 2007 IP
  4. DarkMindZ

    DarkMindZ Guest

    Messages:
    175
    Likes Received:
    6
    Best Answers:
    0
    Trophy Points:
    0
    #4
    I am sorry, but chmodding your file to 644, wont stop all hackers..

    there are tricks, there are exploits, there are alot of methods to get access to that file and read it.. having the file, before /public_html/ or /htdocs/, insures more security for your website against alot of things, first of all, a for-fun-hacker, would just get bored from trying to find that config file, and get lost.. and second, it would take more time for a better hacker, or a targeting hacker, to get access. and hopefully by then your webhost / you would have found out from access_logs etc..

    one more thing that I have noticed, alot of users use the same pass for MySQL and cPanel AND SSH.. which is just making it too easy.. so becarefull, and create a new MySQL user, and use that for your MySQL Usage :)
     
    DarkMindZ, Dec 23, 2007 IP
  5. zebulon

    zebulon Active Member

    Messages:
    196
    Likes Received:
    13
    Best Answers:
    0
    Trophy Points:
    60
    #5
    1) using a basic c99, r57 or another shell via a RFI or LFI, I will not be able to write to the particular config file in question, but I can sure as hell view it to get the SQL information to download all of your tables, user / client information or inject my own values.

    2) On 99% of all resellers, I do see the backups in the home directory, with a simple shell any skiddie can download your back up, and damage your company or site's integrity.

    For host generated backups make sure they are on a remote site, once an attacker gains root, it is just a matter of time before they deposit their evil scripts into all of the backups to ensure easy entry for the next time they need in for example, creation of a botnot, eggdrops, storing malicous files, the list is endless really.

    3) strong passwords are now considered 12+ character's, numbers and symbols in length. but this will not stop an attacker. Brute forcing methods are evolving and becoming ever more clever. As well as social engineering attacks on your provider to gain your information to a) hijack your domain b) gain cpanel or direct admin access or c) will make your life a tad bit more stressful and costly.

    If your web application stores the user information in a sql database, make sure you have an encryption method for those values such as MD5...MD5 encryption is easy to break through but it deters the unknowingly from continuing with an attack. To test your MD5 hash against the numerous and growing online MD5 Hash Crackers/rainbow tables, simply extract your 32-long hash from your userinformation row from your SQL table and submit it online to see if it is cracked or how long it takes for jokes.

    Recommendations:

    1) Security should be seen as value creation instead of what you get in return. Invest a little time into talking with your hosting provider to see what they have in terms of security and how they manage back ups.

    2) Passwords should never be stored on your work station. To keep a long story short, I will simply say --- trojan. Write them down and put it into your desk. Here is a simple example of a good password, jh*#kdGS*#893HR++_#jfr3 keep them long and tricky!

    3) Protect your user information and your own. If you lost your clients information because your SQL database was compromised, you may be faced with a lawsuit and/or lose your business. It is a smart idea to use WhoIs protection on your domains. I have personally witnessed several domains in my lifetime get HiJacked using a simple social engineering attack. To pull this type of an attack off, you just need to know how to talk and have simple relevant information.

    4) If you are using a popular CMS/forums, or web script for your site, remove the copyright!!!! Buy the brandless copy/distribution. Talk to the developers. Be sure that hackers are always searching for new exploits in CMS's which are commonly used, more so the new trend is auditing the modules or addons for these popular systems for new 0-days. Let's say for example, you use phpnuke, and a new exploit hits the web today. Be sure that every script kiddie out there will be google'ing this exact search phrase "intext:phpnuke 2008" or "intext:powered by phpnuke"

    By removing the copyright you have mitigated the risk of being found by a skiddie, and potientally losing your valued site.

    Always stay current with your CMS/forums of choice for new security updates and patches.

    5) Be proactive. Security should be a part of the coding and development stage. If it was, we would not be seeing an increase in web attacks as we are right now for the fiscal 2007 calendar.



    I hope this little blurb could help some of you out with understanding the risks.
     
    zebulon, Dec 24, 2007 IP
  6. DarkMindZ

    DarkMindZ Guest

    Messages:
    175
    Likes Received:
    6
    Best Answers:
    0
    Trophy Points:
    0
    #6
    Nice work there :)..

    1: If it was in a location you dont know about it wont be as easy as that... you see, those defacers / random hackers, will expect to see a config.php in the includes folder of your vB forum.

    but if you edit that, and made it go behind /public_html/ they will just give up and go to another site.. its that simple, unless its a personal hack, you pissed off a hacker, etc, he/she wont bother looking harder / trying to get access..

    2: very true, those backup files contains ALL the info any hacker would want.. keep them away, even if you dont want to store them remotly from cPanel, finish the backup, and then download it to your own PC.. safer

    all good, but most people just download there webapps, most hosting providers are using a public CMS / Hosting Manager, which is not that good, hiding the copyright might stop hackers from getting to you one they find that 0day, but still some files, some directory structure will always be there to get it indexed on a search engine.. a good idea maybe is to not allow search engines into the support software you got..
     
    DarkMindZ, Dec 24, 2007 IP
  7. inogenius

    inogenius Peon

    Messages:
    2
    Likes Received:
    0
    Best Answers:
    0
    Trophy Points:
    0
    #7
    This is an excellent idea. There's so many bots out there that just search google/yahoo/live for those signatures looking for sites to deface. If you have root access, you can also block these defacement attempts using mod_security. Here are the rules that I'm currently using to block them.

    These are no where near complete; I'm always adding to them, but these are ones that I see a lot.
     
    inogenius, Jan 1, 2008 IP
  8. DarkMindZ

    DarkMindZ Guest

    Messages:
    175
    Likes Received:
    6
    Best Answers:
    0
    Trophy Points:
    0
    #8
    And, you should check for

    "libwww-perl*" as a useragent, and block it, most of those scanners are perl, and coders forget to forge the useragent :).
     
    DarkMindZ, Feb 10, 2008 IP