I have an environment where we are intending to authenticate IPoE CPE based on the service ID passed on by the carrier rather than username/password. In our case the BNG routers will receive DHCP requests with option 82 set with the service ID and act as a DHCP/RADIUS gateway. I'm hoping to map option 82 to the NAS-Port attribute and authenticate based on that. Has anyone here done something similar? If so can you share the methods you used and your experience.
Related
We have two Az servers (AS) in our env. for different user base. We are looking to onboard a new API app/ChatBot, which is expecting AS1 to just act as a reverse proxy/RP to get the Access Token from AS2 and present it to them.
How does one go about configuring AS1 as a hub and merely act as a pass thru?
I have the following use case that I would appreciate any input on. I have a Docker Swarm running with Traefik pointed to it for ingress and routing. Currently I have it as a single service that is defined to have 6 replicas of the same image, so works out to be two containers each on three nodes.
The containers basically host a GraphQL server and my requirement is that depending on which client the request is coming from, it always goes to the same specific container (ie replica). So as an example say I have user1 and user2 at client1 and user3 and user4 at client2, if user1 makes a request and it goes to replica1, then if user2 makes a request it MUST go to replica1 as well. So basically, I could take a numeric hash on the client id (client1) and mod 6 it and decide which replica it goes to and in that way make sure any subsequent calls from any user in that client id goes to the same replica. Additionally, that information of what client the call is coming from is coded in a JWT token that the user sends in their request.
Any idea how I would go about changing my Docker Swarm to implement this? My best guess is to change the swarm to not be 6 replicas and instead define each container as a separate service with its own port. Then I could potentially point Traefik to nginx or something similar which would then receive the request, grab the JWT, decode it to find the client id, take a hash and then internally route it to the appropriate node:port combination.
But I feel like there must be a more elegant and simpler way of doing this. Maybe Traefik could facilitate this directly somehow or Docker Swarm has some configuration that I don't know about, that could be used. Any ideas?
Edit: Just to clarify my usecase, not just looking for the same user to always go to the same container but the same type of user to always go to the same container
For this kind of routing you need to setup Traefik for Sticky Sessions
This is a Traefik middleware that adds a cookie to responses that is used in subsequent requests to route to the same service.
I have various routers which connect to my radius system, their IP might change as it's all over the net via NAT networks..
Each router has a unique secret. All known in a local DB
Now I'm looking to set radius up in a way that every router can authenticate with their custom secret, via whatever IP, but freeradius won't let me configure it like this:
client 0.0.0.0/0 {
shortname = test1
secret = AA
}
client 0.0.0.0/0 {
shortname = test2
secret = AB
}
Is there a way so I can either disable the freeradius IP check (and check on secret only?), or to force a client (/ip) to have more than 1 secret ?
Reconfigurating the secret to all the same is unfortunately not possible, as some routers already have been deployed with very limited network access.
I'm using:
freeradius: FreeRADIUS Version 2.2.8, for host x86_64-pc-linux-gnu, built on Apr 5 2016 at 13:40:43
Copyright (C) 1999-2015 The FreeRADIUS server project and contributors.
Why what you want doesn't work with RADIUS/FreeRADIUS alone
FreeRADIUS does the packet to client matching before the packet is decoded. Decoding the packet before performing the matching makes DoS attacks against the server easier, as spurious requests cause the server to use more CPU time.
Ignoring the secret isn't an option either. The secret is used by the Access point to decode protected attributes like the MPPE key attributes for WPA2 Enterprise.
For walled gardens with PAP the shared secret is used to encrypt the cleartext password provided by the user, so if you don't know the shared secret you can't get the plaintext value back for validation.
In v4.0.x the plan is to send packets from unknown IP addresses down to the worker threads for processing. At this point the worker would have full knowledge of all attributes, and could bind a secret to the IP address using that additional information.
It still wouldn't let you map incoming packets using RADIUS attributes, but you're unlikely to see a conflict where two APs swap their WAN IPs... Apart from possibly in a CGN environment with a small public pool.
Available options
Use RADSEC (DTLS/TLS). Clients are validated using a certificate, and the shared secret is fixed.
Establish a tunnel (L2TP/IPSEC/PPP) between the AP and your RADIUS server. Use that to provide consistent local IP addresses.
Run the APs dual stack, hopefully bypassing the NAT. Some ISPs have begun offering IPv6 connectivity with prefix delegation. In these cases, all devices behind the CPE get publicly accessible IPv6 addresses. The prefix may change occasionally, so you'd need to use some sort of 'phone home' system, where the AP could inform your servers of its public address.
Develop your own software, which snoops on incoming RADIUS packets, and checks to see if the IP matches one in your client database. If it doesn't, it tries all the shared secrets to see if any can be used to validate the packet contents, and then updates the IP binding for that client. This might work best with your set of restrictions.
I think there's also some patches out there for v2.x.x which allow dynamic clients to be created using decoded attributes, but v2.x.x was EOL'd a while back, and they're not officially supported.
Since it is possible to link different domain names to the same webserver, is it possible to detect which address [can be the ip address] a client entered to access a website, so it is possible to implement conditions depending on this value?
I'm maybe totally wrong about the multiple domain names. I don't know a lot about dns and domains.
You can see it in the HTTP Host: header. For example, if you're running a PHP script, you can see it in $_SERVER['HTTP_HOST'].
I have a Linux/Apache/Rails stack hosting a data service. The data service is basically a front end for multiple data sources, akin to a federated search.
Queries to the service are authenticated via PKI. When handling each request, the PKI must be forwarded to each data source appropriate for the given request - each data source uses the PKI to control data access.
I know how to access the requestor's DN from Rails, but I haven't the first clue how to access the PKI or pass it along in web requests launched by the controller when handling the request. Any suggestions?
Your description makes it a bit hard to follow the organization, but Ill try to give this a shot.
The nature of PKI makes forwarding (proxying) a connection impossible, since the two endpoints set up a secret session key known only to those parties. It seems like you have 3 parties, a Client, an Intermediate, and an Endpoint. So the client can authenticate to the intermediate, and the intermediate now knows with certainty who the client is. I think your question is how to get the endpoint to know with certainty who the client is. The method I would choose is to have each intermediate have its own certificate, and authenticate to the endpoint itself (so now the endpoint knows who the intermediate is with certainty) then just have the intermediate pass the DN as some extra field that the endpoint will trust from the intermediate.