Log in | Back to darenet.org

Infrastructure

Secretagent (Talk)
(New page: If you are interested in donating/linking an IRC server to DareNET, please join #routing on the network to speak with a Routing Team representative, or e-mail routing[at]darenet.org. == W...)
Newer edit →

Revision as of 12:48, 24 April 2008

If you are interested in donating/linking an IRC server to DareNET, please join #routing on the network to speak with a Routing Team representative, or e-mail routing[at]darenet.org.

What the Routing Team looks for when considering linking a new server


 a) The IRC server must be permitted and supported by the administration of the
    machine and network that it is sitting on.

    If a server is not being linked by the hosting organization, or employees
    of the hosting organization (e.g. it is a colocated server), uplink support
    must be given prior to applying for a DareNET link. In addition, a contact
    address for an individual at the hosting entity should be given to verify
    such support.

 b) The server administrators must be reasonably knowledgable about IRC and
    UNIX. They should be willing and able to answer most user questions that
    they encounter regarding DareNET and IRC. Additionally, they should know
    how their network reaches major internet backbones.

 c) The machine is not required to be dedicated; however, they must adequately
    address any and all security concerns and be sufficient to properly run an
    IRC server. Upon application submission, you agree to consent to a port scan
    and other unobtrusive probes to verify this information. A fully dedicated
    server or a semi-dedicated server (with other forms of access filtered)
    is highly preferred.

    The machine should be reasonably modern and should have at least a 500MHz
    or faster CPU and 256M (512 highly prefered) or more of total RAM.

    (*) xntpd is not a requirement but clock synchronization
        is. ntpdate run on a regular basis should suffice
        (at least once a day).

    All vunerabilities in your irc server's OS should be patched and updated
    as soon as possible. Likewise, if a vunerability arises in any of the
    running daemons such as sshd or ircd, those should be updated as soon as
    possible as well.

    The nameserver that the machine is running should be a current & secure
    version. Information on which version of BIND is current and secure can
    be found at http://www.isc.org/products/BIND/bind-security.html.

 d) Running a server requires that the rest of the IRC network put a lot of
    trust in you. People who are known not to be trustworthy or who have a 
    history of not acting in the best interests of DareNET will typically be 
    denied server links. This includes proposed opers.

 e) New servers MUST be on a multihomed network. We must also be able to
    verify that your server is on a multihomed network, via BGP announcements.

    IRC servers tend to attract their fair share of Denial of Service attacks
    and hack attempts. These attacks can often times be several hundred mbit/sec,
    with several hundred thousand packets per second. Often times these attacks
    are also not directed at irc servers directly, but at neighboring routers
    or machines.

    These attacks can often times cripple even the most robust and diverse
    networks. New applicants must be aware of this, and not only be ready
    to deal with it, but must be versed in methods of combating and protecting
    your server from Denial of Service attacks.

 f) The server MUST be protected from attacks resulting from ARP hijacking.  
    One way to accomplish this is by utilizing static arp addressing on your
    router. Ideally, the server should be on its own IP subnet and VLAN.

 g) All server administrators must grant DareNET's Routing Team access to the
    account running ircd by means of password and ssh public key. The server
    daemon runs as a user program under a vanilla end-user account (frequently 
    called "darenet"), with no setuid or special privilege. Configuration files
    are deployed from a central location using ssh and scp. New servers are
    either staged as binary files or recompiled on the server account, depending
    on architecture and other factors.