Preventing fraudulent logins across multiple sites

How to track sessions without killing performance

When an ISP has RADIUS servers across multiple sites, new attacks are possible. Users can share account information with their friends, who can then log in separately to each site. If the RADIUS system design does not take this problem into account, users can defraud the ISP of significant revenue.

One solution is to post-process the user sessions. The system can check hourly, or daily, if the same user is logged in at multiple sites. If the user is found to have multiple logins, they can be kicked offline, blocked, or even banned from the network. This solution works, but is not always the best one for every situation.

Another solution is to not only track user sessions at each site, but to do cross-site checks for user logins. In this approach, each site will dynamically check every other site when a user logs in. As one might expect, there are costs and benefits to this approach. This article describes why this approach may be useful, how it is done, and what are the pros and cons.

Session databases should be duplicated and synchronized across all sites

Many of our ISP clients need to ensure that credentials are not being shared with friends and family at multiple locations. Every time a new user session is initiated, the session database needs to be checked for any active sessions for those credentials in a different location.

Multi-site session databases

The diagram above shows how it works

  • Each site runs a session database cluster with three nodes (in this case Redis nodes)
  • Each node at each location contains a primary instance for the local site, as well as secondary instances for the other three nodes at the sister sites.

This design provides each site with replicated versions of the session databases at all the other sites, giving each data center an accurate view of all active sessions at all locations. The decentralized data strategy minimizes the performance impact of checking for active sessions associated with a given credential.

Fraudulent credential sharing can represent significant revenue loss for an ISP or other service providers. A network design that can prevent this problem, without sacrificing stability, scalability or performance is essential to the health of the business.

Need more help?

These design principles are based on best practices developed over the last twenty years at NetworkRADIUS. We have seen pretty much every variation of FreeRADIUS deployments out there. If you have a complex network environment and need expertise from the people who wrote FreeRADIUS, contact us for a consultation.

‚Äč

More about ISP RADIUS design best practices

ISP RADIUS design: a practical guide

How to design RADIUS for multi-site networks

Separating RADIUS Authentication and Accounting functionality