View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0004924 | unreal | ircd | public | 2017-04-04 02:34 | 2018-12-09 09:47 |
| Reporter | acidvegas | Assigned To | syzop | ||
| Priority | high | Severity | trivial | Reproducibility | sometimes |
| Status | resolved | Resolution | fixed | ||
| Product Version | 4.0.11 | ||||
| Fixed in Version | 4.0.12 | ||||
| Summary | 0004924: Remote MOTD requests causing netsplits | ||||
| Description | Any server with a few links set up that have the default sendq listed on the documentation wiki (sendq 5M;) is vulnerable to an attack. Just about 20 clones all making multiple remote motd requests at such a speed (there is NO motd request throttle btw) can cause a netsplit on all of the links easily. One could increase the sendq but it never needs to be that high. I think the option to disable/enable remote motd and rules requests should a part of the config. I managed to fix the problem temp by increasing the sendq and adding the following into my config: tld { mask *@*; motd remote.motd; rules remote.motd; options { remote; }; }; remote.motd is a single line file that says that remote requests have been disabled. | ||||
| Steps To Reproduce | Most people follow the Link Tutorial guide on the documentation page and have only 5m sendq for link servers. Create a hub with a few links and use a bunch of clones to spam /motd <link server name> over and over across all the links | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
We could (and should) lag users up when they request a remote MOTD. This so they can only request a remote MOTD once per 8 seconds or so. I'll check in something for that. Another option would be to disable remote MOTD requests by default. Depends on how serious it is. We did this approach for remote-server support for /CREDITS and /INFO because the feature was rarely used and this output is not useful for users. I'm surprised you are saying it only takes 20 clones to beat a 5M server sendq, though. If your MOTD is 4kb then with 20 clones it would mean the server links can't sustain 2*40 = 80kb/s. Though with burst you can have tenfold at start (but only the first second), so 800kb/s, but the sendq would absorb that. Clones can reconnect to keep the burst speed but throttling would kick in after they do it 3 times in default configuration. So I wonder if I'm missing something: Is your MOTD a lot bigger? Or do you have slow uplinks? All possible.. |
|
|
Yeah I have quite a large motd, and a lot of servers sometimes do aswell, I forgot to mention that. |
|
|
Sounds like lagging up the user should suffice. Then they can do only one request per 10 seconds. So a tenfold decrease. Even with a 10k motd and 100 clones that will only give a peak of 1MB -- from which it has 10 seconds to recover, so 100KB/s. I could also have a look at just refusing MOTD responses when the sendq is at a certain percentage. That may be useful for other commands as well. |
|
|
I've done the former, since that's pretty much a one liner (the rest was just re-indenting): https://github.com/unrealircd/unrealircd/commit/ee9f8441bc6cda5d277b4913ec07e8abeb3ffa2b |
|
|
I'm marking it as fixed in 4.0.12, the version containing the (first) fix. With a "normal motd" and sufficient sendq I would expect this to be sufficient, although I must admit that I did not test. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2017-04-04 02:34 | acidvegas | New Issue | |
| 2017-04-04 07:23 | syzop | Note Added: 0019732 | |
| 2017-04-04 07:24 | syzop | Note Edited: 0019732 | |
| 2017-04-04 07:24 | syzop | View Status | public => private |
| 2017-04-04 07:26 | syzop | Assigned To | => syzop |
| 2017-04-04 07:26 | syzop | Status | new => feedback |
| 2017-04-04 08:10 | acidvegas | Note Added: 0019734 | |
| 2017-04-07 20:05 | syzop | Note Added: 0019735 | |
| 2017-04-07 20:07 | syzop | Note Added: 0019736 | |
| 2017-04-07 20:07 | syzop | Status | feedback => acknowledged |
| 2018-12-09 09:45 | syzop | View Status | private => public |
| 2018-12-09 09:47 | syzop | Status | acknowledged => resolved |
| 2018-12-09 09:47 | syzop | Resolution | open => fixed |
| 2018-12-09 09:47 | syzop | Fixed in Version | => 4.0.12 |
| 2018-12-09 09:47 | syzop | Note Added: 0020397 |
