DWIRC:Staff Training/IRC Operator Fundamentals

DarkWorld IRC Staff Training
Module 9: IRC Operator Fundamentals

Program	DarkWorld IRC Staff Training Program
Module	9 of 10
Difficulty	Advanced
Estimated study time	5–7 hours
Assessment	Knowledge check, command simulations, and incident exercises
Prerequisite	Module 8 — Abuse and Incident Handling

Module Overview

An IRC operator, commonly called an IRCOp, is a trusted network staff member with elevated privileges for protecting and operating the IRC network.

IRC operator privileges may allow a staff member to:

• View operational information.
• Receive server notices.
• Investigate network abuse.
• Disconnect users.
• Apply network-level restrictions.
• Assist during floods and attacks.
• Coordinate across multiple IRC servers.
• Use approved override capabilities.
• Support network recovery.

These powers can also disconnect innocent users, block shared networks, expose sensitive connection information, or disrupt IRC services if used incorrectly.

Important: This lesson does not grant IRC operator access. Operator access requires a defined operational role, management approval, secure credentials, appropriate permissions, and successful probation.

Learning Objectives

After completing this module, the candidate should be able to:

1. Explain the purpose and responsibilities of an IRC operator.
2. Distinguish channel moderation from network enforcement.
3. Protect operator credentials.
4. Recognize common operational notices.
5. Collect relevant user and connection information lawfully.
6. Explain kills and network-ban types.
7. Select the smallest appropriate network response.
8. Recognize the risks of host and IP-based restrictions.
9. Understand OperOverride and forced mode operations.
10. Respond safely to netsplits, floods, and Services failures.
11. Record operator actions.
12. Recognize commands reserved for senior administrators.
13. Escalate high-risk network incidents.

1. Purpose of an IRC Operator

The purpose of an IRC operator is to:

• Protect the IRC network.
• Respond to network-wide abuse.
• Assist users and channel staff.
• Maintain operational stability.
• Enforce network policies.
• Coordinate incident response.
• Protect Services and servers.
• Apply network restrictions when justified.
• Document significant actions.
• Support recovery after incidents.

IRC operator status is not a reward, status symbol, or entitlement.

It is an operational responsibility.

2. Channel Operator vs IRC Operator

Role	Scope	Example responsibilities
Channel operator	One or more channels	Topics, voice, kicks, channel bans, channel rules
IRC operator	IRC network	Network abuse, user disconnections, network bans, server notices
Services staff	Anope Services	Account and registered-channel administration
IRCd administrator	IRC server infrastructure	Configuration, modules, server links, upgrades

An IRC operator is not automatically:

• A channel founder.
• A Services Administrator.
• An IRCd administrator.
• A DWShells administrator.
• A DWBouncers administrator.
• Authorized to interfere in every channel dispute.

3. Least-Privilege Operator Access

Operator permissions should match the staff member’s assigned role.

Possible permission groups may include:

• Local operator.
• Global operator.
• Help operator.
• Services operator.
• Network administrator.
• Root administrator.
• Specialized abuse or security role.

A local operator may have authority limited to one server.

A global operator may have authority across connected servers.

Actual permissions depend on the current UnrealIRCd configuration and security groups.

Staff must not assume that a title grants every available command.

4. Operator Authentication

IRC operator authentication commonly uses the `/OPER` command or an approved automatic authentication method.

General form:

/OPER operator-name password

Exact credentials and authentication requirements are defined by the current UnrealIRCd configuration.

Operator authentication should occur only:

• Over verified TLS.
• From an approved device.
• Through an approved connection.
• Using a unique operator credential.
• After authenticating the normal Services account where required.
• Without exposing the command in a channel.

Operator Credential Rules

An operator must:

• Use a strong and unique password.
• Never reuse the NickServ password.
• Never share the operator password.
• Never send it through IRC messages or email.
• Avoid storing it in plaintext.
• Protect client configuration files.
• Lock or disconnect unattended devices.
• Report suspected exposure immediately.
• Follow any certificate or authentication requirements.
• Remove credentials from retired devices.

5. Failed Operator Authentication

Repeated `/OPER` failures may indicate:

• Incorrect credentials.
• Wrong operator name.
• An unauthorized host.
• Missing Services authentication.
• Incorrect TLS or certificate state.
• Outdated client configuration.
• A compromised or guessed credential.
• A configuration problem.

Staff must not repeatedly try passwords or ask another operator to share credentials.

The correct response is:

1. Stop repeated attempts.
2. Record the exact error.
3. Confirm the correct operator identity privately.
4. Confirm the approved connection requirements.
5. Notify authorized administration if unexpected.
6. Treat unexplained repeated failures as a possible security event.

6. Operator Session Security

Before using operator access:

• Confirm the device is trusted.
• Confirm the IRC client is updated and securely configured.
• Confirm TLS certificate verification.
• Close unnecessary scripts or plugins.
• Verify the active network and server.
• Confirm the nickname and Services account.
• Know how to remove operator status or disconnect safely.
• Ensure logs are protected.

Do not remain opered unnecessarily on an insecure or unattended device.

7. Server Notices

IRC operators may subscribe to or receive server notices, commonly called snotices.

These may report:

• New connections.
• Disconnections.
• Failed operator attempts.
• Kills.
• Network bans.
• Flood activity.
• Server links.
• Server disconnections.
• Services activity.
• Security events.
• Override use.
• Configuration or routing problems.

Notice categories and user modes depend on the UnrealIRCd configuration.

Operators should configure only the notices relevant to their role. Excessive notices may hide important events.

8. Operational Information Commands

Common informational commands may include:

Command	General purpose
`/WHOIS nickname`	View user information
`/WHOIS nickname nickname`	Request additional WHOIS information where available
`/WHO #channel`	View channel users
`/USERHOST nickname`	View basic connection identity
`/WHOWAS nickname`	View limited information about a disconnected nickname
`/LINKS`	View linked IRC servers
`/MAP`	View a network map where supported
`/LUSERS`	View network statistics
`/STATS letter`	Request a specific server statistics category
`/VERSION`	View server software information
`/TIME`	View server time
`/ADMIN`	View server administration information
`/MOTD`	View the Message of the Day

Some information is restricted.

Operator-only information must not be copied into public channels without an operational reason and authorization.

9. User Investigation Principles

An operator may need to examine:

• Nickname.
• Ident.
• Displayed host or cloak.
• Registered account.
• Connected server.
• Secure connection status.
• User modes.
• Channel presence.
• Idle time.
• Connection timing.
• Relevant authorized logs.
• Previous related enforcement.

Operators must not investigate users:

• Out of curiosity.
• Because of a personal disagreement.
• To discover private information for a friend.
• To track someone without an operational reason.
• To expose hidden information publicly.
• Outside their assigned authority.

Every investigation should have a legitimate network purpose.

10. Identification Is Not Certainty

The following do not independently prove that two connections belong to the same person:

• Matching host.
• Matching VPN exit.
• Matching bouncer server.
• Similar nickname.
• Similar writing style.
• Shared channel membership.
• Same country.
• Similar connection time.

Evidence may be combined, but staff must distinguish strong evidence from assumptions.

Shared systems may include:

• VPNs.
• IRC bouncers.
• Shell providers.
• Webchat gateways.
• Mobile carriers.
• Universities.
• Workplaces.
• Residential networks.
• Relays.

11. User Kills

A KILL forcibly disconnects a user from the IRC network.

General syntax:

/KILL nickname reason

Example:

/KILL ExampleNick Active multi-channel flooding

Exact syntax and permissions must be verified through current server help.

A kill:

• Ends the current connection.
• Does not necessarily prevent reconnection.
• May affect a bouncer or automated client.
• Should include a clear operational reason.
• Must be recorded when significant.

A kill may be appropriate when:

• Active abuse must stop immediately.
• A user is flooding multiple channels.
• A malicious client is attacking users.
• A phishing identity is actively collecting credentials.
• A compromised bot is spreading harmful content.
• A user must be disconnected before a restriction is applied.

A kill must not be used:

• As a joke.
• To remove someone from only one channel.
• To win a personal disagreement.
• To punish criticism.
• When a channel kick is sufficient.
• Without checking the correct nickname.

12. Network Bans

A network ban prevents matching connections from using the IRC network.

UnrealIRCd may provide several restriction types. Exact syntax and behavior must be verified with the current server configuration and `/HELPOP`.

Possible types include:

Restriction	General purpose	Main risk
K-line	Restricts a user or host, often on one server	Scope may differ by server
G-line	Network-wide user or host restriction	May affect many users
Z-line	IP-based restriction, often processed early	Can block shared addresses
Global Z-line	Network-wide IP-based restriction	Very broad operational effect
Shun	Silently restricts many user commands	User may remain connected without understanding why
Temporary shun	Temporary command restriction	Must be reviewed and documented

Terminology, propagation, matching, and duration syntax depend on the deployed UnrealIRCd version.

Before using any network restriction, verify the current syntax with `/HELPOP`, confirm the target and duration, and check how many legitimate users may match.

13. Choosing a Network Restriction

Before applying a restriction, determine:

1. What behavior must be stopped?
2. Is the behavior still active?
3. Is disconnecting the current user sufficient?
4. Is a channel restriction sufficient?
5. What identity information is reliable?
6. Is the IP or host shared?
7. Is an account-based response available?
8. Should the action be local or network-wide?
9. What duration is proportionate?
10. Could legitimate DWShells, DWBouncers, VPN, or gateway users be affected?
11. Do you have authority?
12. Is senior approval required?
13. What is the rollback procedure?

The smallest effective restriction is usually preferred.

14. Ban Duration

A restriction may be:

• Very short for immediate containment.
• Temporary pending investigation.
• Time-limited for a confirmed violation.
• Extended after repeated evasion.
• Indefinite or permanent with appropriate senior approval.

The duration should reflect:

• Severity.
• Intent.
• Previous relevant behavior.
• Impact.
• Likelihood of recurrence.
• Risk to innocent users.
• Whether the identity is reliable.
• Whether appeal or review is pending.

Operators must understand the current time format used by UnrealIRCd before entering a duration.

15. Ban Reasons

A network-ban reason should be:

• Factual.
• Concise.
• Professional.
• Related to policy or conduct.
• Useful to other staff.
• Free from unnecessary private information.

Good examples:

Active multi-channel flooding
Repeated unsolicited network recruitment after warning
Credential phishing through Services impersonation
Ban evasion during active abuse incident
Malicious bot distributing harmful links

Avoid:

Bad user
Annoying
Go away
You know why
Staff decision
Personal dispute

Where an internal case reference exists, it may be included according to policy without exposing confidential details.

16. Confirming a Restriction

After applying a network restriction:

1. Confirm that the command succeeded.
2. Confirm the intended target matched.
3. Confirm the restriction propagated as expected.
4. Check whether innocent users were disconnected.
5. Record the exact entry.
6. Record the time and duration.
7. Record the reason.
8. Set a review time.
9. Notify the incident lead.
10. Correct errors immediately.

Never assume a restriction worked simply because the command was entered.

17. Removing a Network Restriction

Before removal:

• Confirm the exact restriction type.
• Confirm the exact mask or target.
• Review the original reason.
• Check whether the incident remains active.
• Confirm authorization.
• Determine whether another protection is required.
• Record the removal and reason.

Do not remove a restriction merely because the affected user is a friend or complains persistently.

Do not leave incorrect restrictions active to avoid admitting a mistake.

18. Shuns

A shun may leave a user connected while preventing many commands or messages.

Because the user may receive limited feedback, shuns require careful use.

A shun may be considered for:

• Certain active flooding behavior.
• Automated malicious commands.
• Temporary containment during investigation.
• Situations where immediate disconnection is less useful.

Risks include:

• Confusing affected users.
• Hiding the action from ordinary channel staff.
• Leaving legitimate users unable to communicate.
• Forgetting a temporary restriction.
• Applying it to a shared identity.

Shuns must be documented and reviewed.

19. OperOverride

OperOverride allows an authorized IRC operator to bypass certain normal channel restrictions.

It may permit actions such as:

• Joining a restricted channel.
• Acting despite channel access limitations.
• Performing authorized emergency intervention.
• Investigating a serious network incident.

OperOverride must be used only when:

• There is a valid network-level purpose.
• Normal procedures are insufficient.
• The operator has authority.
• The action is proportionate.
• The use is documented.
• Confidentiality is maintained.

It must not be used:

• To enter private channels out of curiosity.
• To monitor personal conversations.
• To bypass a channel founder during an argument.
• To obtain channel operator status for convenience.
• To assist a friend in a private dispute.
• To avoid the Services ownership process.

20. SAMODE and Forced Channel Actions

`SAMODE` or equivalent administrative capabilities may force user or channel mode changes.

These are elevated powers.

Possible legitimate uses include:

• Emergency network protection.
• Correcting a severe mode-lock situation.
• Containing active abuse.
• Restoring a network-managed channel.
• Carrying out an authorized administrative decision.

Risks include:

• Overriding legitimate channel ownership.
• Removing critical protection.
• Affecting many users.
• Concealing who initiated the change.
• Creating conflict with Services.
• Using the wrong target or parameter.

Trainees should learn the concept but must not execute forced mode commands in production.

21. Server Routing and Topology

DarkWorld IRC consists of linked servers.

Operators should understand:

• Users connect through individual servers.
• Channels and messages are shared across the network.
• Services may connect through a dedicated server.
• A server link can fail.
• A server may reconnect and synchronize.
• Round-robin DNS may direct users to different servers.
• A local problem may affect only one server.
• A split may affect a portion of the network.

Useful commands may include:

/LINKS
/MAP
/LUSERS
/WHOIS nickname

Availability depends on permissions and current configuration.

22. Netsplits

A netsplit occurs when linked IRC servers lose communication.

Signs include:

• Many users quitting together.
• Server names appearing in quit reasons.
• One region or server becoming unreachable.
• Channels temporarily separating.
• Users returning together after reconnection.
• Server-link notices.

Operators should:

1. Identify the affected server or link.
2. Record the time.
3. Check authorized server notices.
4. Avoid unnecessary user bans.
5. Avoid treating returning users as a raid without evidence.
6. Notify network operations.
7. Allow synchronization after reconnection.
8. Verify Services and channel state.
9. Provide an approved status update.
10. Document persistent instability.

23. Server-Link Commands

Commands that disconnect, reconnect, restart, or terminate IRC servers are dangerous.

Examples may include:

• Server-connect commands.
• Server-disconnect commands.
• SQUIT.
• REHASH.
• RESTART.
• DIE.

These commands can affect hundreds of users and the entire network.

They belong to the IRCd Administration specialist program and must not be used by general trainees.

24. Rehashing

A rehash reloads IRCd configuration.

An incorrect or unauthorized rehash may:

• Activate a broken configuration.
• Remove required settings.
• Change security controls.
• Affect server links.
• Load unintended modules.
• Produce partial configuration behavior.
• Disrupt users.

General IRC operators should report configuration issues to authorized IRCd administrators.

Knowing that `/REHASH` exists does not authorize its use.

25. Flood and Raid Response

When an attack affects several channels or servers:

1. Confirm the scope.
2. Assign an incident lead.
3. Protect affected channels.
4. Collect connection and timing information.
5. Apply authorized targeted restrictions.
6. Coordinate with IRCd operations.
7. Avoid independently applying overlapping broad bans.
8. Monitor for changing sources.
9. Communicate approved updates.
10. Record every emergency action.
11. Review and remove temporary controls.

A flood may move between:

• Nicknames.
• Accounts.
• IP addresses.
• IPv4 and IPv6.
• VPN services.
• Proxies.
• Bouncers.
• Servers.
• Channels.

Operators should focus on behavior and verified technical evidence, not nationality or unsupported assumptions.

26. Connection Floods and IRCd Protection

Network connection floods may require IRCd-level controls such as:

• Connection throttling.
• Reputation-based restrictions.
• Server-level flood protection.
• Temporary configuration includes.
• Proxy scanning.
• Firewall or upstream mitigation.

These controls belong to authorized IRCd, security, or infrastructure staff.

An IRC operator should:

• Record the connection pattern.
• Identify affected servers.
• Provide accurate counts where possible.
• Preserve server notices.
• Apply only authorized operator-level containment.
• Escalate infrastructure changes.

27. Services Failures

When Services are unavailable:

• NickServ identification may fail.
• SASL may fail.
• ChanServ may disappear.
• Channel status may not be restored.
• HostServ vhosts may not be applied.
• Registered nickname protection may be unavailable.

Operators should:

1. Confirm whether Services are connected.
2. Record the start time.
3. Notify Services administrators.
4. Avoid unnecessary founder or access changes.
5. Protect official channels temporarily where needed.
6. Allow synchronization after Services return.
7. Verify important channel modes and access.
8. Communicate accurately.

28. Server Notice Privacy

Operator notices may reveal:

• IP addresses.
• Hidden host information.
• Connection details.
• Authentication events.
• Ban reasons.
• Staff actions.
• Server topology.
• Security controls.

This information must remain within the authorized operational context.

Do not paste raw server notices into:

• Public channels.
• Public websites.
• Unrestricted project channels.
• External communities.
• Personal social-media accounts.

29. Operator Action Logging

Significant operator actions should be logged.

Use a format such as:

Date and time:
Operator:
Incident reference:
Target nickname:
Registered account:
Visible mask:
Affected server:
Command category:
Action:
Scope:
Duration:
Reason:
Evidence:
Authorization:
Users affected:
Result:
Review time:
Follow-up:

Do not store operator passwords or authentication commands in action records.

30. High-Risk Command Checklist

Before using a high-impact operator command:

1. Am I connected to the correct network?
2. Am I targeting the correct nickname, host, IP, or server?
3. Is the evidence sufficient?
4. Is the incident still active?
5. Is a channel-level response sufficient?
6. What is the narrowest effective scope?
7. Could the target be shared?
8. Is the duration correct?
9. Do I have authority?
10. Is senior approval required?
11. Is another operator already acting?
12. How will I verify success?
13. How will I reverse the action?
14. Where will I record it?

If the action is not urgent, pause and verify before sending it.

31. Command Coordination

During an active incident, multiple operators may otherwise:

• Apply duplicate bans.
• Use conflicting masks.
• Repeatedly kill the same reconnecting user.
• Remove each other’s restrictions.
• Apply overlapping broad actions.
• Confuse channel staff.
• Lose track of temporary controls.

The incident lead should coordinate:

• Who investigates.
• Who applies restrictions.
• Who records actions.
• Who communicates publicly.
• Who reviews the results.

32. Operator Mistakes

If an operator:

• Kills the wrong user.
• Applies the wrong mask.
• Blocks a shared provider.
• Sets the wrong duration.
• Uses the wrong restriction type.
• Exposes private information.
• Applies an unauthorized override.

They must:

1. Stop continuing harm.
2. Correct or remove the action.
3. Restore affected access where possible.
4. Notify the incident lead or senior staff.
5. Preserve the original log.
6. Record the correction.
7. Inform affected users appropriately.
8. Participate in review.
9. Complete additional training if required.

Concealing an operator mistake is more serious than honestly reporting and correcting it.

33. Operator Conduct

IRC operators must:

• Remain professional.
• Be visibly accountable for actions.
• Avoid threats and intimidation.
• Follow policy.
• Respect channel autonomy.
• Protect confidential data.
• Cooperate with other staff.
• Accept review.
• Avoid public staff arguments.
• Declare conflicts of interest.
• Step back when personally involved.

Operator status does not place a person above DarkWorld rules.

34. Temporary Removal of Operator Access

Operator access may need to be suspended when:

• Credentials are exposed.
• A device is compromised.
• The operator repeatedly acts unsafely.
• A serious misconduct investigation is active.
• The operator is inactive for an extended period.
• Their role no longer requires access.
• Management determines that network safety requires suspension.

Temporary suspension is a protective measure and does not by itself establish misconduct.

35. Practical Exercises

These exercises must use simulations, a training environment, or trainer-approved test identities. Candidates must not apply production network bans.

Exercise 1: Operator Security Review

Prepare a checklist covering:

• TLS.
• Device security.
• Password storage.
• Client scripts.
• Automatic `/OPER`.
• Logs.
• Session locking.
• Credential rotation.
• Compromise reporting.

Exercise 2: User Investigation

Using trainer-provided simulated WHOIS and notice data:

• Identify confirmed account information.
• Identify the connected server.
• Identify displayed connection information.
• Separate facts from assumptions.
• Recommend whether further investigation is justified.

Exercise 3: Kill Decision

For each simulated case, decide whether a kill is appropriate:

• Minor off-topic discussion.
• Active phishing.
• Single-channel flooding.
• Multi-channel automated flooding.
• Respectful criticism of staff.
• Malicious bot distribution.

Explain whether a kick, kill, ban, or no action is most appropriate.

Exercise 4: Network-Ban Selection

Given several simulated masks:

• Choose local or global scope.
• Identify shared-host risks.
• Select a duration.
• Write a professional reason.
• Explain how the restriction would be reviewed.
• Do not execute the command.

Exercise 5: Netsplit

The trainer simulates a server split.

The candidate must:

• Identify the likely split.
• Record the affected server and time.
• Avoid treating returning users as attackers.
• Notify operations.
• Prepare a public status update.
• Verify recovery.

Exercise 6: Wrong Restriction

The trainer simulates a global restriction affecting innocent bouncer users.

The candidate must:

• Identify the excessive scope.
• Recommend immediate correction.
• Preserve the original record.
• Notify senior staff.
• Prepare an affected-user explanation.
• Propose a narrower replacement.

Exercise 7: Coordinated Flood

During a simulated multi-channel flood, the candidate must:

• Report to the incident lead.
• Identify affected channels and servers.
• Recommend operator-level containment.
• Avoid duplicate actions.
• Record all proposed restrictions.
• Define recovery and review steps.

36. Practical Scenarios

Scenario 1: Channel Argument

A user insults a channel operator once. The channel operator asks an IRCOp to permanently ban the user from the network.

Recommended response:

A normal channel-level response is likely sufficient. Network authority should not be used merely because a channel operator requests disproportionate punishment.

Scenario 2: Active Phishing

A fake Services nickname is sending credential requests in several channels.

Recommended response:

Immediate network-level containment may be justified. Disconnect or restrict the malicious connection through authorized procedures, preserve evidence, warn users, and escalate compromised accounts.

Scenario 3: Shared Shell Provider

One abusive user connects through a host also used by many legitimate DWShells users.

Recommended response:

Avoid a broad host restriction where a more precise account, ident, or supported security-based restriction is available. Coordinate with DWShells staff if their infrastructure is relevant.

Scenario 4: OperOverride Request

A friend asks an operator to override an invite-only private channel so they can see what is being discussed.

Recommended response:

Refuse. This is not a valid network purpose and would misuse elevated access.

Scenario 5: Persistent Link Failure

One server disconnects and reconnects repeatedly.

Recommended response:

Record the link events, identify affected users, notify IRCd administration, avoid unnecessary user enforcement, and provide an approved operational update.

Scenario 6: Wrong Global Ban

An operator accidentally applies a network-wide ban to a large shared VPN provider.

Recommended response:

Remove or correct the restriction immediately where authorized, notify the incident lead, identify affected legitimate users, preserve the action record, and complete a formal review.

Scenario 7: Compromised Operator

An operator account begins issuing unexpected kills while its owner says they are offline.

Recommended response:

Treat the account as compromised. Notify senior management immediately, restrict its access through authorized procedures, preserve logs, rotate credentials, and review all actions performed during the suspected compromise.

37. Knowledge Check

Answer the following questions in your own words:

1. What is the purpose of an IRC operator?
2. Why is operator access not a reward?
3. What is the difference between an IRC operator and an IRCd administrator?
4. What is least-privilege operator access?
5. Under what conditions should operator authentication occur?
6. Why must the NickServ and operator passwords be different?
7. What should happen after unexpected `/OPER` failures?
8. What are server notices?
9. Why should operators subscribe only to relevant notice categories?
10. What user information may be relevant to an abuse investigation?
11. When is an operator investigation improper?
12. Why does a matching host not prove common identity?
13. What does a KILL do?
14. When is a KILL inappropriate?
15. What is the general difference between local and global restrictions?
16. Why are IP-based restrictions risky?
17. What factors determine a network-ban duration?
18. What makes a professional ban reason?
19. What must be verified after applying a restriction?
20. What should be checked before removing a restriction?
21. What is a shun?
22. Why must shuns be documented carefully?
23. What is OperOverride?
24. When must OperOverride not be used?
25. What is the risk of forced mode commands?
26. What information can `/LINKS` or `/MAP` provide?
27. How should an operator respond to a netsplit?
28. Why are SQUIT, REHASH, RESTART, and DIE considered high risk?
29. Who should handle IRCd configuration changes?
30. What is the operator’s role during a connection flood?
31. How should Services failure be handled?
32. Why must server notices remain confidential?
33. What should an operator-action record contain?
34. Why is command coordination important?
35. What should happen after an operator mistake?
36. When might operator access be suspended?
37. Why must an operator disclose a personal conflict?
38. Does completing this module authorize production operator access?

38. Written Assignment

Write approximately 900–1,200 words analyzing this incident:

During a coordinated attack, several accounts flood `#DarkWorld`, `#Help`, and `#Support`. Two attackers connect through a VPN also used by twenty legitimate users. A new IRC operator globally bans the entire VPN hostname without checking its scope. Twenty-two users disconnect, including the attackers. Another operator removes the ban without informing anyone, and the attack resumes. A third operator begins issuing repeated KILL commands while no incident lead has been assigned.

Your analysis must explain:

• Why network-level intervention was justified.
• Why the global hostname ban was risky.
• What narrower responses should have been considered.
• Why removing protection without coordination caused a problem.
• Why repeated KILL commands were insufficient.
• How an incident lead should coordinate operators.
• What evidence should be preserved.
• How innocent users should be restored.
• What public message may be appropriate.
• What operator actions must be recorded.
• How the restrictions should be reviewed.
• What training or access review may be necessary afterward.

39. Module Completion Requirements

To complete this module, the candidate must:

• Read the complete lesson.
• Complete all seven practical exercises.
• Correctly answer at least 29 of the 38 knowledge-check questions.
• Complete the written assignment.
• Demonstrate operator credential-security awareness.
• Correctly distinguish channel and network responses.
• Select proportionate simulated restrictions.
• Complete the netsplit and flood simulations.
• Demonstrate accurate action logging.
• Receive trainer approval.

Completion does not guarantee IRC operator appointment.

40. Trainer Evaluation

Evaluation area	Maximum points
Operator role and authority boundaries	15
Credential and session security	15
User investigation and privacy	15
Kill and network-restriction judgment	20
Netsplit, flood, and Services response	15
Coordination and logging	10
Accountability and correction	10
Total	100

Recommended passing score: 80 points.

A higher passing score is recommended because operator actions can affect the entire network.

A candidate should not pass if they:

• Share or mishandle operator credentials.
• Use elevated access for personal purposes.
• Repeatedly choose dangerously broad restrictions.
• Publicly expose restricted user information.
• Ignore command scope or duration.
• Conceal operator actions.
• Refuse incident coordination.
• Use dangerous server commands without authorization.
• Retaliate against users or staff.
• Treat training completion as automatic authorization.

41. Operator Readiness Checklist

Before a candidate can be considered for operator probation, they should demonstrate:

[ ] Completed Modules 1–9
[ ] Passed operator knowledge assessment
[ ] Passed incident-response simulation
[ ] Accepted the Staff Code of Conduct
[ ] Uses secure TLS and SASL
[ ] Uses unique operator credentials
[ ] Understands least privilege
[ ] Can identify shared-host risks
[ ] Can distinguish channel and network enforcement
[ ] Can document operator actions
[ ] Can correct and report mistakes
[ ] Understands escalation paths
[ ] Has an assigned mentor
[ ] Has management approval
[ ] Has a defined operational role

42. Next Module

After passing this module, continue to:

Module 10 — Staff Ethics and Security

---

Previous: Module 8 — Abuse and Incident Handling Program: DarkWorld IRC Staff Training Program Next: Module 10 — Staff Ethics and Security