Security risk through Co-Domains

Discussion in 'Installation/Configuration' started by hastlaug, Apr 17, 2006.

  1. hastlaug

    hastlaug New Member

    "Normal" customers are able to add, edit and delete their domains.

    This leads to a security risk:

    Let's assume you have a malicious user.

    This user simply adds a new Co-Domain, e.g. to his account. If his account is limited to one domain, he could delete it and add instead, or just change the domainname.

    Let's further assume that he doesn't own ;)

    He sets mail processing to "local mailserver" and sets up a catch all mail address.
    From now on he can catch all mails that users of this server are trying to send to [email protected]

    Of course this doesn't affect anything outside the server, but it's bad enough that someone could be able to steal all outgoing mail. And as the average administrator doesn't check all the domains daily there isn't even a chance to detect such malicious behaviour in time.

    Possible solutions:

    a) Don't allow regular users to add/modify/delete their domains. I think resellers should be trusted, but maybe an option to enable/disable this feature would be even better.

    b) When setting up a new domain, check the official domain name server responsible for this domain. Check the ips of the MX hosts. If none is the same than the domain's ip on the local server, automatically disable local mail delivery and force use of external mail server. It would even make sense to perform this check in a regular term every 24h, if a dns entry changes. The latter is not such important, but if you want perfection...

    By the way: Something similar to b) is used by big dedicated server providers. When you setup your reverse DNS name, then first it's checked if the domain name really points to the server and rejected if it doesn't. This check is repeated every 24h to prevent abuse.

    If you ask me: a) is sufficient as hot fix, but b) should be a much better solution. I already implemented such a patch (like b) for VHCS, which had (and I guess still has) the same issue, and it's not really much work. I just don't have enough experience with ispconfig yet to do same thing here. But as it's not that hard to do, I look forward till and falko will get this managed ;)
  2. falko

    falko Super Moderator Howtoforge Staff

    Thanks for the hint. We will check how we can fix this.
  3. oliver.blaha

    oliver.blaha New Member

    Any news here?
  4. falko

    falko Super Moderator Howtoforge Staff

    Not yet. We're very busy... :(
  5. oliver.blaha

    oliver.blaha New Member

    Okay, maybe I'll try to get it done - but as I'm also very busy it will take some time ;)
    In the meanwhile you could give me some hints what you consider as the best solution... i think the mentioned solution b) makes sense, and that's what I would implement. Suggestions?
  6. till

    till Super Moderator Staff Member ISPConfig Developer

    I agree, solution b) seems to be the best.

Share This Page