in reply to Re: Matt's scripts strike again
in thread Matt's scripts strike again

Anyway, it's good to see your ISP has some clue.
I'd say, the ISP doesn't have a clue. They only outlawed Matt Wright *after* they relayed for a while. And they are still not getting it. The problem isn't Matt Wright, the problem is installing any random junk and praying it works fine. Today it was formmail, tomorrow it's something else. The fact that one buggy program installed on one host can "severely effect several of our servers", and consume almost all bandwidth is a serious design problem of ISP's setup.

I'd be mighty pissed if I was using the ISP's hosting service, and connection to my site was seriously disrupted because of what happened with some other site.

Abigail

Replies are listed 'Best First'.
Re: Matt's scripts strike again
by b10m (Vicar) on Dec 09, 2003 at 16:37 UTC
    I didn't say they had much clue, but some ;) But yes, you are right. They should have looked at the issue before they implemented it. Especially since is known for ages that these scripts can be exploited by evil spammers.
    --
    B10m
      I really don't want to put words in Abigail-II's mouth, so I'll add my own. ;) I think that the point is that an ISP who allows its users to install CGI scripts from any source (including self-developed / written) without first reviewing the script is exposing themselves (and their clients) to security risks.

      Today it may have been Matt's script. But how many times have we seen security-hole ridden code posted here along with questions, by folks other than Matt Wright? It happens all the time, and one can only assume that such code eventually finds its way onto some unsuspecting ISP's system. And for every example we see here, there are thousands that never are seen by anyone aside from the script-kiddie (or sub-par professional) who wrote them, until the damage is done.

      Any ISP who allows user-written and user-installed scripts onto its servers without prior review (a time-consuming and costly process), or without operating it in an environment that prohibits it from bad behavior, probably has serious breeches lurking, that may be found eventually.

      This is an unfortunate situation; a few bad apples ruin it for everyone. A substantial portion of ISP's have stopped allowing just anybody to post CGI scripts. This is a step in the right direction for security, and a step backward for the hobbiest, even if he/she produces secure code.


      Dave

        I really don't want to put words in Abigail-II's mouth, so I'll add my own. ;) I think that the point is that an ISP who allows its users to install CGI scripts from any source (including self-developed / written) without first reviewing the script is exposing themselves (and their clients) to security risks.
        Reviewing would be nice, but costly, and I don't think many people want to pay for it. The alternative is to put any site that wants to install their own CGI programs on either a dedicated box (which will cost more than $10/month of course), or you're put on a box with only sites that put their own CGI programs on box, and are told about the risks the others can do to you. Such boxes should have their bandwidth limited by a router (to prevent other hosts from becoming unreachable). SMTP traffic will only be allowed to at most a few other boxes (local to the ISP), in order to limit the number of outgoing messages per time unit.

        It won't prevent the box being used as a relay, but it will prevent it from becoming a big problem.

        Abigail

        But then you get into colos, where people are paying good money so they can run whatever they want on the servers they own, but are housed elsewhere. In some cases, the colo also offers a test server for their customers, which may be shared with many other customers. I doubt a customer would intentinally upload a malicious CGI since the colo will undoubtably have a large paper trail leading back to them, but there is plenty of room for ignorance.

        The best solution here is to make sure each customer has a firewall covering all their equiptment. However, this may not be economical.

        Beware that colos seem prone to great stupidity. In our move to our current colo, they told us we couldn't use SSH on their provided test server because it's "insecure" and we should use FTP instead. (We ended up buying a little more rackspace and a second server for testing so we could at least insulate ourselves from such madness).

        ----
        I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
        -- Schemer

        : () { :|:& };:

        Note: All code is untested, unless otherwise stated