Greenlight: Feature request: Limit room scanning

[MarcelWaldvogel]

Right now, I am not aware of any efforts by GL/BBB to limit the efforts of an eavesdropper/B⁴omber scanning the name of rooms (see the discussion with @farhatahmad and @lkiesow in #1450).

I suggest that this should be documented and/or implemented:

1. Explain in the configuration documentation, that room names can be guessed brute-force.
2. Provide a means to make scanning ineffective:
   
   
   
   • Increase the entropy of room names (#1450)
   
   
   • Have BBB limit the scanning of room names
   
   
   • Have some external tool (e.g. fail2ban) limit the scanning of room names or document how to do this.
   
   

A fail2ban filter rule to be applied against /var/log/bigbluebutton.access.log might be:

failregex = ^<HOST> \- \S+ \[\] \"(GET|POST|HEAD) \S+ \S+\" 404 .+$
ignoreregex =
datepattern = {^LN-BEG}%%ExY(?P<_sep>[-/.])%%m(?P=_sep)%%d[T ]%%H:%%M:%%S(?:[.,]%%f)?(?:\s*%%z)?
              ^[^\[]*\[({DATE})
              {^LN-BEG}

(adapted from filter.d/nginx-botsearch.conf).

It will require a fairly high threshold of 404 requests before blocking, so it will not be effective against a large botnet or a slow scan, given the current low room name entropy. But at least it would be one step forward.

This could be included in the .deb packages and/or bbb-install.sh.

[ffdixon]

Good suggestion (and we are talking internally about the entropy of room names).

[lkiesow]

My suggestion would rather be to increase the entropy than to rely on yet another external service which needs to be set up properly and which does have side-effects (fasil2ban can easily lead to accidentally banning users – not that I don't use it in some situations anyway ;-)

As @MarcelWaldvogel pointed out in #1450, for most users it really doesn't matter how long the invitation links are since no one really types them anyway. Looking at other systems you will actually see a lot of invitation links which are extremely long…

Wouldn't it make sense to just put security first, increase the room name length by default but make this configurable so that anyone who wants to have this shorter can easily do that?

Documenting that you should do something is something I always think is a bit weird since no one really reads all of the documentation (I'm including myself of course) and that means by just installing it, I deliberately get a sub-optimal result. The other way around, by just installing things, I get a result I can safely work with but may tune in case I want to trade security for convenience, …

[farhatahmad]

We've had some more talks internally and we are continuously running into the issue of making every single feature configurable. This leads to a ridiculous amount of settings that need to be configured in order to get the application working correctly.

For the room entropy, we've decided on keeping the current format but adding an additional triplet to the end. By default this will apply to only newly created rooms, with a rake task that can be run to update all other rooms (if wanted).

As for the fail2ban, I'd have to agree with @lkiesow. Adding more components means that there is an increased complexity, which leads to more support being required. We're going to leave things like that up to the system administrator who is installing BigBlueButton/Greenlight

[MarcelWaldvogel]

I completely agree to keep the number of options minimal, especially those exposed to users.

The four triplets with the first helping in auto-completion is a good step forward and probably the best in compromise we can currently achieve. So, please do go for it wrt to #1450.

Regarding fail2ban and the possible false positives, how about going the standard fail2ban way:
Provide all the configuration settings, but it remains the sysadmin's duty to actually activate the banning?

[farhatahmad]

Still not sure that shipping fail2ban with BigBlueButton + Greenlight is the way to go. From the support perspective, it presents challenges that I don't believe we have the time/capacity to support.

As is standard practice with many other open source web applications that I've seen, I'd argue that it's a sysadmins due to:

• Research different ways to secure the application
• Implement the method they believe best suits their needs with the correct configuration
• Actively monitor, tweak and maintain the method used

Packaging it ourselves means that we have to do the above, not the sys admin

[MarcelWaldvogel]

Ahmad, you convinced me that shipping fail2ban with BBB+GL is not a good option. What I was proposing is that a fail2ban configuration file would be shipped with some BBB/GL setups (not sure yet which ones).

The fail2ban configuration could then easily be enabled, similar to what is done with the built-in f2b configurations, which are also disabled by default.

[cron0mat]

I am with you @MarcelWaldvogel
BBB/GL could provide logging and the fail2ban profile and it is due to admin to set it active.

Is there currently any logging in greenlight providing login information (fail/ok) which we can use for fail2ban ?

I have anonymous user with room code and I would like to block guessing room code.
But in ~/greenlight/log/production.log there is always same logging

INFO: [8964a166-ddb5-462e-badd-75c8d8e90491] method=POST path=/b/xxx-wza-6n9/login format=html controller=RoomsController action=login status=302 duration=13.11 view=0.00 db=2.12 location=https://xxx.xx/b/xxx-wza-6n9 host=greenlight

There is also no timestamp ?

[farhatahmad]

Fixed in 2.7