Note: this is not official, check http://www.ca-efnet.org to be sure you
have the latest app.
---------------------------------------------------------------------
Canadian EFnet Server Link Application
Written 11/14/01 zodiack/kurious1 :: irc.arcti.ca
Updated 01/23/02 shi :: irc.torix.ca
Updated 10/03/03 nistor :: irc.torix.ca
Updated 01/08/03 Kurious1/Hardy :: irc.avalonworks.ca/irc.arcti.ca
Updated 29/08/03 Ca-Admins :: irc.avalonworks.ca/irc.arcti.ca/irc.dks.ca
Updated 03/15/04 Hardy :: irc.avalonworks.ca
Updated 04/09/04 kurious1 :: irc.arcti.ca
Updated 04/09/04 cv - Section c :: irc.arcti.ca
Updated 06/20/04 Kurious1 - Gline :: irc.arcti.ca
Updated 08/03/09 Hardy :: irc.igs.ca
<=====================================================================>
Please fill out this form in as much detail as possible to be considered for a trial server link to CA-EFnet.
Below are the agreed-upon guidelines for linking new servers to the Canadian portion of the EFnet.
If, after reading these guidelines, you feel that the Canadian routing committee should consider linking
your server, cut out the application at the bottom, respond to each of the questions and email it to the
Canadian Routing Secretary at hardy@underworld.no
If the site you want to link a server from is in Europe or the US, please contact the admins for your
region of the world. What the Canadian routing board 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.
b) The server administrators must be reasonably knowledgable about IRC and the rules of EFNET(voting.efnet.net)
They should be willing and able to answer most user questions that they encounter
regarding IRC. Additionally, server administrators should be familiar with general
internet topology. At the minimum, they should know how they normally reach each
of the major backbones.
c) The IRCD machine should be dedicated and provide enough resources to:
* Sustain large ICMP, SYN, DDoS and DoS attacks.
* Handle at least a few thousand clients.
A recommended configuration would be 1GHz, 1GB of memory, 2GB in
swap, a NIC card that provides TCP checksum offloading (any server
grade NIC card should do, Intel PRO100 or 1000's are great). At least
100FDX to the network connected to a switch and router that can
handle forwarding a large amount of packets. (this is to cover SYN
attacks which is a lot of packets, but low bandwidth)
The absolute minimum would be a 700MHz, 512MB of memory, 1024MB in
swap, the NIC and switch/routers should be the same as stated above.
To keep time in sync with the rest of EFNet it is required to
synchronize with various Step Time servers using NTP. Rather than
cron ntpdate, you should run NTPD. This provides a smoother
transition of time by slowly skewing the clock by small amounts to
keep in sync. You should use a minimum of 3 Step Time servers to
synchronize. The NTP port on your IRC server should be firewalled to
only allow UDP from the Step Time servers you choose.
The Name Server used by the IRC server itself must be running a
recent (does not need to be the latest) version of Bind or DJB DNS,
no other NS Software will be accepted. This ensures that various DNS
attacks will be kept to a minimum if a client were to attempt a
"spoof" of a hostname to an IRC server, via a DNS Flood method or
older exploits.
ICMP unreachable, redirects and timestamp should be filtered on
either the server's firewall, router or upstream providers.
(recommended)
Server administrators should be versed in common methods for handling
various DoS attacks, whether it's a direct flood, DoS, DDoS, SYN
attack or Drone connects to the IRCD itself. Each method can greatly
effect the operation of the system hosting the IRCD. Keeping versed
in the various methods ensures a timely diagnosis when attempting to
locate an issue.
A working compiler *must* be installed in order to compile the IRCD
within a timely manner, in the event of emergency upgrades.
The machine should be accessible by the admin (remotely and
physically) at all times of the day. Physical access can simply
amount to someone being available to pull the plug, in the event of
an intrusion which locks other admin's out of the system.
Remote access is required for emergency patches to the system OS, or
IRCD.
Proper and methodical security practices should be applied.
Random IP ID's should be employed to ensure remote users will not be
able to predict the rate of packet generation.
Keep in mind, that EFNet servers *have* been compromised in the past,
and you will get a lot of attempts by users trying to compromise your
IRC machine directly, or machines owned by opers / other machines on
the network the server is located.
It's a good idea to make sure the segment your IRC server sits on
isn't on the same one as shell servers, or co-located machines.
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 a history of not acting in the best interests
of the IRC networks will typically be denied server links.
e) These days, a large EFnet client server can utilize a few hundred kbits/s, which is a large
amount of bandwidth for most small ISPs. Given that we need a few large client servers and fewer
small 'local' servers, this should definitely be taken into consideration when a site is deciding
whether they even want an EFnet server. EFnet IRC Servers should be on a network that is multihomed
to with a minimum of two underutilized OC3s (or STM-1s) to at least two networks. Cooperation from
the uplink providers is an absolute necessity as EFnet IRC Servers tend to attract frequent Denial
of Service attacks. Some of these attacks can cripple even the most robust and diverse networks.
[Note: I think the record is 700Mbits against secsup]
Routing on the network on which the IRC Server resides should allow the server to fully utilize the
multiple links and must not sit in an address space which would prevent the server from failing over
in the event of circuit problems.
f) The server must have their bots/abuse policies clearly stated in the motd and contact information
must be stated in the A:lines. The server administration should be willing to take measures to minimize
clonebotting by the use of connection limits in the I/Y lines and/or the use of tcms (monitor bots) or
live operators.
g) All new servers must run an ircd approved by the EFnet routing committee. The three most popular versions
are maintained by Chris Behrens ("CS") ,Hybrid team ("hybrid") and Raboxt Team ("Ratbox").
Official sites for the above versions are:
h) Closed I:line servers must have an I:line contact. There are *very* few sites on the net that can
justify their own private EFnet server. Chances are your site is not one of them. As a result, you will
be expected to offer service to sites that are close to you netwise. This is only necessary if you are
limiting your I:lines and intend to run a fairly closed server. The I:line contact will be someone
who has the ability to modify the ircd.conf to add I:lines.
i) During the TRIAL period the server/staff will NOT be allowed to:
- New servers may not be compiled in debug mode.
- New servers will be L:lined - meaning that they cannot link in other servers until such a
time as it is deemed that the server and its administration are ready for such a load and the
server's network location would provide a well-placed hub server.
- Participate in votes or admin-level tasks on EFnet.
- Add spoofed I-lines for non-operators (operators on other EFnet servers excluded).
- Route/connect servers other than relinking their own to the network.
- Connect to any none .ca hub servers. (We encourage the exchange of C/Ns with other HUBs)
j) During the initail 30 days of their trial period, the new staff members will not be able to:
- /kill clients on remote servers.
- Participate in GLINE votes (i.e. staff isn't permitted to hold the G O-line flag).
- Utilize Operspy
After this period the admin can change any opers to Global at their descretion.
Existing EFnet operators who are given O-lines on the new server are excepted from the above.
k) Last, but not least, there must be a need for a server in your network location. All new servers
will be on a 60 day period during which time the server and administration will be watched closely.
For the first 30 days, the server should be monitored VERY closely and any bugs/configuration
changes should be made at this point. Addionally, I:lines should be somewhat restricted. At the
end of the initial 30 day period, the admin should open up the server a bit. The server will be
re-evaluated at the end of the 60 day probational period. Note that denied applicants will not have
the privilege of reapplying for 6 months. As such, it is in the applicant's best interest to do
some homework on what applications have been approved in the past and which ones haven't and,
more importantly, why they were approved or denied.
l) Canadian servers are required to resolve to a name with a working .ca TLD. In other words, you
may only use .ca as server tld, not .net/.com/.info/.org or any other tld`s
These guidelines have been agreed upon by all of the current Canadian server admins.
Currently, the public Canadian servers are:
server contact address
================== =======================
irc.arcti.ca irc@arcti.ca
irc.dks.ca irc@dks.ca
irc.avalonworks.ca hardy@efnet.org
======= SNIP HERE ======= SNIP HERE ======= SNIP HERE ======= SNIP HERE ======= SNIP HERE ==============
For multiple choice questions, please mark the appropriate box with an "x|X if not applicable, simple put "NA".
Server Information:
===================
1A. Server DNS name :
B. Server IP address :
C. Does IP reverse to server DNS name? : [ ] Yes [ ] No
D. Server CPU(s) :
E. Memory :
F. Operating system / version :
G. Services running :
H. Open ports :
I. Who has access to the server? :
J. Who will be responsible for compiling the ircd? :
K. Version of Hybrid/CS/Ratbox initially running on the server? :
L. How many clients will the server be compiled to handle? :
M. What date will the server be ready to link (MM/DD/YYYY) : 00/00/2003
N. Who is the server administrator? :
- Real name :
- Phone number :
- Emergency 24 hour contact number :
- Email address :
O. What other machines are on the local network? :
- Who has access to those machines? :
- Will those machines firewalled from the server? :
P. How is ARP handled on the switches/routers? : [ ] Static
[ ] Dynamic
[ ] No idea
[ ] Our network guy does that
Q. Firewall : [ ] Hardware
[ ] Software
[ ] None
- How will firewall handle denial of service? [short answer] :
Networking / Connectivity:
==========================
2A. Network topology to border router :
B. Does server administrator (1I) have access to router(s)? : [ ] Yes [ ] No
C. Connection speed(s) to upstream provider(s) [list] :
:
D. Is server multihomed? : [ ] Yes [ ] No
- If so, with which providers? :
:
E. Network peering points (eg SIX/RISQ/TORIX/OTTIX) :
F. Hosting networks ASN :
G. Is server IP block portable? : [ ] Yes [ ] No
H. Will IP block be advertised/removed via BGP? : [ ] Yes [ ] No
H. If the adverstisement is removed what are the thresholds? : [ ] Yes [ ] No
I. Do you think RIPv2 is pretty? : [ ] Yes [ ] No
J. Do you believe in World Peace? : [ ] Yes [ ] No [ ] Wtf?
Server Policies:
================
3A. Will the server allow bots? : [ ] Yes [ ] No
B. Will server allow non-CA clients after probation period? : [ ] Yes [ ] No
C. Will an OOMON/TCM/BOPM run on the server? : [ ] Yes [ ] No
- If so, Who will be running/configuring it? :
D. Will this server be a "closed" server (via I:lines, network
announcements, etc.) after the completion of the trial period? :
- Be adviced that NO on the above question, Should you decide
to not keep the server open then the CA-Admin community will
vote on this as a new application.
E. Who will be the initial server operators? Nick : / Name :
Nick : / Name :
Nick : / Name :
Traceroutes:
============
4. Please include the output of traceroutes to the following servers.
Note that many EFnet servers filter ICMP/UDP packets. Run the traceroutes
as far as you can and paste them in the space provided. An alternative would
be to use LFT2.0 to do traceroutes with TCP on port 6667 as well.
< http://www.MainNerve.com/lft/ >
[Note: some of these traces may not be accurate due to routing policies; and
therefore will have to be run the opposite way around]
A. irc.arcti.ca
B. irc.igs.ca
C. irc.servercentral.net
D. irc.nac.net
E. irc.choopa.net