/usr/share/doc/tinymux/ATTACK is in tinymux 2.6.5.28-1ubuntu2.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 | TinyMUX 2.6: ATTACK
Last Update: December 2006
You should familiarize yourself with defensive procedures that serve to thwart
the effects of attacks. Don't wait until an attack is mounted against your
game to begin learning how to defend it against an attacker. Practice for
this eventuality now.
Player Creation:
----------------
If you are running an open game, it is possible for an automated script to
create players faster than you can can destroy them. Even if a group of
people are doing it manually, the odds are they can create player objects
faster than you can destroy them.
As a WIZARD, there are a few remedies available to you:
@disable logins
As #1, there are some additional remedies available to you:
@admin register_site=0/0
@aahear attack:
---------------
With TinyMUX 2.2 and later, the @aahear exploit is no longer as useful to
attackers as it once was. This attack was usually mixed with other forms of
attack to obscure it.
@pemit/page attack:
-------------------
The combination of lwho() and @pemit can be used for spamming.
As a player, WIZARD, or #1, you can prevent being spammed by:
&CANPAGEME me=0
@lock/page me=CANPAGEME/1
@admin pemit_far_players=0 (the default)
Attack on the queue:
--------------------
Usually, putting lots of commands on the queue will drain an attackers
store of coins. However, if they happen to obtain the free_money power
(or WIZARD permissions...by which time you're toast anyway), then they
can attack the queue.
As a WIZARD or #1, there are a few remedies available to you:
@disable dequeueing
Attribute attack:
-----------------
The server will not allow more than a few thousand attributes per object.
This attack is no longer feasible.
Attribute Name Attack:
----------------------
Attribute names are different than the attribute values they name. By
default, mortals are not allowed to create more than 5000 new names per
hour. See 'wizhelp user_attrib_per_hour'. However, the site admin
still needs to keep an eye on attribute names as described below in
'General Server Hygiene'.
@Mail Attack:
-------------
Mortals are not allowed to send more than 50 @mails per hour. However, the
site admin still needs to keep an eye on the size of @mail. See
'wizhelp mail_per_hour'.
CPU Slaming:
------------
There are ways of consuming hours and days of CPU time with carefully
chosen softcode. The lag_limit configuration option controls the point
at which the server abbreviates its efforts. In some ways, this is
like hitting a Function Invocation Limit. One additional thing that
hitting a lag_limit does is @halt the offending code.
General server hygiene:
-----------------------
There are a few things you should do on a regular basis:
- Backups. Off-line backups. Don't expect much sympathy if you
can't put your hands on a good backup.
- Good backups. Manually verify that your backups are valid and
complete. Don't expect much sympathy if you can't put your hands
on a good backup. Did you put your backup on a ZIP disk? Can
you still read it? Do you smoke?
- Backup often. How much work are you willing to lose?
- Keep an eye on how much CPU and memory your server process is
consuming. Your memory usage will gradual increase and slowly
approach some number. If your memory usage suddenly goes above
this, something is wrong. If your CPU usage is not usually 0% or
on a busy game, less than 5% for awhile, Look for an attack in
progress. Get a 'feel' for what is normal for you game and be
sensitive to what might be abnormal.
ps ux -A
- Keep an eye on attribute names (Vattr names) with the following
command:
@list hashstats
The column you care about is the 'entries' column. This number will
always increase, however, stale names can be removed by #1 using the
@dbclean command. Run @dbclean approximately every 3 months.
|