Results 1 to 18 of 18
  1. #1

    * Help To Prevent From Iframe virus

    I need to know so idea,how to prevent iframe virus injection into the server,also is there is any mod which help in protection for iframe virus.

  2. #2
    Join Date
    Sep 2002
    Location
    Canada
    Posts
    452
    - Install mod_security 2.5 on apache 2 and get rules from gotroot.com
    - Enable open_basedir protection in WHM security
    - Use suPHP if you can
    - Run /script/upcp to stay with the latest cPanel stable
    - constantly update mod_security
    Reliability Performance Integrity

  3. #3
    Join Date
    Sep 2002
    Location
    Top Secret
    Posts
    11,686
    It's almost amusing the number of people that just blindly recommend mod_security and "updating rules" any more, without understanding what these rules actually do.

    Mod Security is not advised at all, unless you have your own ruleset that WORKS. The rules from gotroot are crap, complete and utter garbage. They will break any number of things in your website, in your client's website, in anything. Do NOT use them.

    Especially, do NOT use them if you're running apache 1, or even 2.0. 2.2 is a bit more stable and can handle them, but apache1 can't, and 2.0 has a few issues with them itself.

    How to prevent this? Keep your website updated. Don't use old versions of code (including php). Keep your server updated. Go through your server logs.

    If you have to ask "Howw do I keep myself safe", you need an admin to proactively monitor and update your server, because, you will eventually get hit.

  4. #4
    Thnaks linux-tech it given some more idea for this issue.any more suggestion welcomed

  5. #5
    Join Date
    Sep 2002
    Location
    Canada
    Posts
    452
    Mod Security is not advised at all, unless you have your own ruleset that WORKS. The rules from gotroot are crap, complete and utter garbage. They will break any number of things in your website, in your client's website, in anything. Do NOT use them.
    I think you're missing the point. Mod_Security by itself will not protect you. In fact, no single item will prevent iframe.

    We've found mod_security helpful and the gotroot rules great on several occasions. There are some false positives, but you can quickly identify these and remove the rules associated with them.

    Mod_security will help you secure your server against vulnerable PHP application like the time phpbb was being hacked, it will also prevent certain shell scripts from being executed properly (personally, I tested it with c99 shell script which mod_security disallowed running most of the commands).

    Additionally, we're talking about how to prevent iframe, and not how to resolve iframe infections. Prevention is much harder step than detection.

    The only 100% way of protecting against iframe attacks is by ensuring every single PHP code on your server will not allow an anonymous user to upload a file to your server.

    We all know in a shared hosting environment this is nearly impossible to achieve. So we take steps like mod_security to MINIMIZE the risk.

    I also disagree that an admin will PREVENT iframe. Having a competent admin will reduce the chance of being infected, but doesn't necessarily mean he/she will prevent it. Unless the admin is going to spend all his time scanning application on the server and updating forums/blogs for clients.
    Reliability Performance Integrity

  6. #6
    Join Date
    Mar 2006
    Posts
    241
    Have you changed your site passwords? Is your server up to date with security patches?
    Have you checked any log files?
    Could your own computer be compromised? Checked for trojans/rootkits recently?


    Secure your binaries like gcc, wget, yacc, perlcc etc.

    Functions like exec() and system() are used for executing external programs.
    Disable insecure functions using disable_functions in php.ini.
    You can use like ,

    disable_functions = system,exec

    Update Apache/Php and kernel regularly.

    Besides all these you should take your own security measures while writing php scripts.
    LiquidSupport - A subsidiary of I-Fort Technologies (Pvt.) Ltd
    Server Administration | Technical Support | Web Development

  7. #7
    Join Date
    Sep 2002
    Location
    Top Secret
    Posts
    11,686
    There are some false positives, but you can quickly identify these and remove the rules associated with them.
    Some? Try a majority of them are false positives, and they're NOT all 'quickly identified'. Hell, I gave up trying to figure out which was trying to "protect" me from someone passing http in a livehelp script. I don't have time to spend debugging crap like that, I'm too busy fixing problems to play with rules that don't work for anything.

    If you run any sort of 'livehelp', forget using those rules, they're garbage.

    If you run apache 1.x, forget those rules, they're garbage.

    If you run any sort of forum, forget those rules, they're garbage.

    Hell, if you run any sort of forum at all, don't even bother with mod_security.

    There are plenty of less intrusive and more effective ways to handle security than mod_security. It starts with keeping your application up to date.

    As far as having an admin being an end all to the problem? Where, please tell me , did I say that? I said the man needed an admin if he had to ask, and he does. If you don't know what you're doing behind a server, then get help (and no, asking for 'free help' on WHT doesn't count as getting help), or leave the administration to the professionals.

  8. #8
    ya,i have some issue in mod_sec it blockeing normal members also,where i can find best rule rule for mod_security

  9. #9
    Join Date
    Sep 2002
    Location
    Canada
    Posts
    452
    There are plenty of less intrusive and more effective ways to handle security than mod_security. It starts with keeping your application up to date.
    That is your experience. We run mod_sec on Apache 1.3x and Apache 2.2x without issues nor complaints and we have large number of rules there. We don't just copy and paste gotroot, we selectively choose the ones that best fit our needs and have been successfull at it.
    Reliability Performance Integrity

  10. #10
    Join Date
    Dec 2006
    Posts
    477
    The only 100% way of protecting against iframe attacks is by ensuring every single PHP code on your server will not allow an anonymous user to upload a file to your server.
    That's not a 100% safe way of protecting against them either. Apart from all the other attack vectors to a server, a php page that read simply:

    Code:
    <?php print $_GET["x"]; ?>
    Would be vulnerable if hit with the URL blah.php?x=<iframe...

    You need to sanitize all input received from the user - query string, cookies, http headers and form fields, not just uploaded files.

  11. #11
    Join Date
    Sep 2002
    Location
    Top Secret
    Posts
    11,686
    Quote Originally Posted by tamouh View Post
    We don't just copy and paste gotroot, we selectively choose the ones that best fit our needs and have been successfull at it.
    But you recommend others to do what you DON'T do. Got it, do as I say, not as I do.

    mod_security really isn't the end all and be all for security. Sure, it can HELP, but it can cause FAR more damage than it can relieve.



    You need to sanitize all input received from the user - query string, cookies, http headers and form fields, not just uploaded files.
    Well said, and of course the OP was wrong in that statement. Now, you're just talking sentiments here. PHP, Perl, CGi, it's all the same.


    You want to protect your server 100% from an iframe virus? Turn it off, unplug the network cable. Yup, just remove everything. That'll do it.

    Of course, that's unreasonable to expect , but that is the only way to do it 100%, and even THEN, it's not fully 100% (anyone can replace a network cable, or even a power cable).

    The point is KNOW what you're dealing with, and KNOW what's going on with your server. DO NOT listen to people that blindly recommend you just "download X rules" without knowing your specific environment, because that will ONLY lead you into more and more problems.

    Find yourself a good admin, someone to take care of this stuff for you. A GOOD admin will keep you updated (proactively) and have their own setup for security that may (or may not) include this kind of a workaround. A GOOD admin will be able to find and resolve this.

  12. #12
    Join Date
    Sep 2002
    Location
    Canada
    Posts
    452
    But you recommend others to do what you DON'T do. Got it, do as I say, not as I do.

    mod_security really isn't the end all and be all for security. Sure, it can HELP, but it can cause FAR more damage than it can relieve.
    He was asking for an advise on what things he can do to help protect again iframe. Obviously, you seem more interested in pushing your sys admin services to him than sticking to the subject.

    Mod_security works well if you use it properly, again, you're entitled to your own opinion on whether it causes more harm than good. Our experience has been good with mod_sec and I'd not hesitate to recommend it along with gotroot rules to anyone.

    The point is KNOW what you're dealing with, and KNOW what's going on with your server. DO NOT listen to people that blindly recommend you just "download X rules" without knowing your specific environment, because that will ONLY lead you into more and more problems.
    duhh...there is no fix all solution in security. It is a process of customizing things to your own env. Even with modsec, different servers in our env. have different rules depending on the apps running.

    You need to sanitize all input received from the user - query string, cookies, http headers and form fields, not just uploaded files.
    Correct, but the majority of iframe (if not all) are done through mass scripts. They upload a c99 or r57 to a server, then hack all other sites on the same server.
    Reliability Performance Integrity

  13. #13
    Join Date
    Sep 2002
    Location
    Top Secret
    Posts
    11,686
    Obviously, you seem more interested in pushing your sys admin services to him than sticking to the subject.
    Really? Thanks for reading my mind. Please, tell me, what am I going to have for dinner?

    Ohhh yeah, that's right, you don't KNOW, because you don't have any idea WHAT my "interests" or "intentions" are. Stop trying to accuse people of something that they're NOT intending to do, and for the love of god, STOP telling people to do something you don't even do yourself.

    Blindly relying on mod_security is wrong. Blindly accepting rules from a website such as gotroot, again, wrong. Their rules are GREAT if you have a static website with no content refresh, no real user interaction, and nothing at all for user input.

    Of course, taking advice from someone who doesn't even get php security is about as silly as it gets as well. People like that are the reason that posts and "advice" from forums like this should be taken with a grain of salt and used sporadically.

  14. #14
    Join Date
    Sep 2002
    Location
    Canada
    Posts
    452
    Their rules are GREAT if you have a static website with no content refresh, no real user interaction, and nothing at all for user input.
    They work fine with most php sites, forums, photo galleries, blogs, e-comm, comments spams....etc. As long as you review/select the right rules.
    Reliability Performance Integrity

  15. #15
    Join Date
    Sep 2004
    Posts
    1,904
    Can I just inject my 2 pennies. I tend to agree with Linux-Tech that blindly submitting information to someone looking for help - especially when it is server related and you don't have a clue what their current setup is - can and often times will become a mind field for disaster to happen at the first wrong step.

    All I suggest is next time - offer up something like - "One Method is to .... " but "the risk that are involved could be ....".

    2 pennies worth which these days might buy you the smell of gas.


  16. #16
    Join Date
    Jun 2002
    Location
    Waco, TX
    Posts
    5,292
    iframe/script SQL Injections have been happening a lot in the last days, simply answer fix your code to prevent SQL Injections in ASP/ASP.NET Code

    Not sure if your issue is PHP or ASP/ASP.NET

  17. #17
    Join Date
    Oct 2007
    Location
    Kochi,INDIA
    Posts
    331
    The source of these attacks are poorly crafted vulnerable code..
    If you are in a shared environment (i believe most people coming over to this forum are!) its hard to upgrade /patch all the accounts and the all the million types of programs that are in there

    So a simple solution is to install a app-level firewall like mod_security and get the rules updated for commonly occurring attack patterns (most aatcks come from script kiddies who target known vulnerabilities)

    BE WARNED!!- mod_security like all technology is not fool proof..and protection comes always with a price- here it is in the form cpu and memory resources. If you have plenty of them both give it a shot.
    Also you can enable/disable this on a per account basis

    Just my 2 cents
    http://xtendweb.gnusys.net/
    Plug in Nginx & Plug in performance on cPanel systems
    WebOps on cPanel . Deploy webapps to multiple servers and scale horizontally

  18. #18
    Quote Originally Posted by rathin View Post
    I need to know so idea,how to prevent iframe virus injection into the server,also is there is any mod which help in protection for iframe virus.
    1. Always keep all your applications up to date: WordPress, forums, etc. Subscribe to the upgrade announcement mailing list for every app you use, or subscribe to a forum thread where they announce upgrades. When an upgrade comes out, install it immediately.

    iframes are often put on pages by drive-by Remote File Inclusion (RFI) attacks that target vulnerable pages. Guard against RFI:

    2. In php.ini (or .htaccess), turn off register_globals. In php.ini, turn off allow_url_fopen (you can't turn that one off in .htaccess). You can also disable functions that you don't use, especially the most powerful ones (listed by a previous poster).

    3. In .htaccess block requests that have http, https, or ftp in the query string.

Posting Permissions

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