Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
Icecast-Server
Icecast-Server
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 94
    • Issues 94
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 1
    • Merge Requests 1
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Analytics
    • Analytics
    • CI / CD
    • Repository
    • Value Stream
  • External Wiki
    • External Wiki
  • Members
    • Members
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Xiph.Org
  • Icecast-ServerIcecast-Server
  • Issues
  • #2119

Closed
Open
Opened Dec 10, 2014 by Philipp Schafft@ph3-der-loewe🦁Maintainer

Filter based on User Agent

There is <allow-ip> and <deny-ip> already. Someone was asking me for a way to filter clients based on User Agents.

I would suggest to implement this as a role-type. This should allow matching on all headers and maybe on other kinds of client data as well. The module would return NOMATCH on no match or FAILED on match on deny list. Behaviour on pass should maybe be documented. Defaulting to NOMATCH to continue with the processing of other <role>s.

Some technical background: In contrast to the <allow-ip> and <deny-ip> this check can only happen after the client request has been parsed as it depends on data of exactly this client request. This makes it less suitable for (D)DoS protection in general. It should be considered to use some kind of firewalling of fail2ban to protect against such attacks.

Pros of implementing it the way described above:

  • It would match the internal schemata and wouldn't be another alien.
  • It could be extended to universally match any configured attributes of the client object.
  • Integrates well into usage together with other <role>s. E.g. to allow some role access but deny others access depending on this module (admin can always go, listeners only if user agent matches).
  • Rejects the client with a 401 according to the standard. Contra:
  • Is much slower than implementing it in a specific and specific way as it happens in the authentication engine and not in before on rejected clients. Slowdown for passing clients will not be significant.
  • Rejects clients with a standard conforming 401. Does not just drop them.
Edited Nov 10, 2018 by Philipp Schafft
Assignee
Assign to
Icecast 2.5.0
Milestone
Icecast 2.5.0
Assign milestone
Time tracking
None
Due date
None
Reference: xiph/icecast-server#2119