Add client IP address to log messages
Hello, FreeRADIUS has been working well for us but we've started to see an increase in attempts to login to some of our devices from unsavory characters. We have a lot of devices so it would really be useful if FreeRADIUS could log what client the request comes from. Currently, this is what it looks like when we see a failed login attempt. 1. Login incorrect (pap: Crypt digest does not match "known good" digest): [drew] (from client localhost port 0) Does anybody know how I can adjust it so that it says something like 1. Login incorrect (pap: Crypt digest does not match "known good" digest): [drew] (from client localhost port 0) from 192.168.55.2 Where 192.168.55.2 is the IP address that sent the RADIUS auth request? I believe that the information inside of the ( ) is sent from the device itself, I am working with the device MFG to see if they can actually fix their implementation so that it makes the device identifiable that way as well. Any way to speed up the process of remediation is tremendously helpful. Thanks, -Drew
On 23/11/2021 12:41, Drew Weaver wrote:
We have a lot of devices so it would really be useful if FreeRADIUS could log what client the request comes from.
The RADIUS "client" is the NAS - this might not be what you want. There may be attributes such as Calling-Station-Id which are most appropriate, rather than what the "client" is.
Does anybody know how I can adjust it so that it says something like
1. Login incorrect (pap: Crypt digest does not match "known good" digest): [drew] (from client localhost port 0) from 192.168.55.2
You can alter it in radiusd.conf - see the log{} section, e.g. msg_goodpass and msg_badpass.
Where 192.168.55.2 is the IP address that sent the RADIUS auth request?
That is the NAS - which is probably not what you want. The NAS is already shown ("from client localhost"). But e.g. something like msg_badpass = "MAC:%{Calling-Station-ID}" might be a start. See the debug output for what attributes are available.
I believe that the information inside of the ( ) is sent from the device itself
No. You can see what comes from the NAS in the RADIUS attributes in the debug output - only some of that comes from the end device.
Any way to speed up the process of remediation is tremendously helpful.
Also take a look at the linelog module, it's a lot more flexible than the built-in auth logging. -- Matthew
Thank you for your reply,
Where 192.168.55.2 is the IP address that sent the RADIUS auth request?
That is the NAS - which is probably not what you want. The NAS is already shown ("from client localhost"). ---- Since these are VPN servers all I really need to know is the IP address of the VPN server (or NAS) that the auth request originated from. I am not sure why or even how radiusd could think that the auth request is coming from itself but the requests are not sourced from the radius server to the radius server. The sources are all on different IP addresses. Thanks, -Drew
On 23/11/2021 13:08, Drew Weaver wrote:
Where 192.168.55.2 is the IP address that sent the RADIUS auth request?
That is the NAS - which is probably not what you want. The NAS is already shown ("from client localhost"). ---- Since these are VPN servers all I really need to know is the IP address of the VPN server (or NAS) that the auth request originated from.
You didn't say what the NASes were, so I had to guess. It makes giving an accurate answer much harder.
I am not sure why or even how radiusd could think that the auth request is coming from itself but the requests are not sourced from the radius server to the radius server.
Because you defined all the clients in the "localhost" section in clients.conf, so it calls them all "localhost". Give each client its own section and its own name, and it'll write the correct name in the log.
The sources are all on different IP addresses.
You could also use this in the log section msg_badpass = "IP:%{Packet-Src-IP-Address}" -- Matthew
----
I am not sure why or even how radiusd could think that the auth request is coming from itself but the requests are not sourced from the radius server to the radius server.
Because you defined all the clients in the "localhost" section in clients.conf, so it calls them all "localhost". Give each client its own section and its own name, and it'll write the correct name in the log. --- Is this something that you can define in the SQL module? That would probably be way easier than maintaining a clients.conf that is essentially 200 entries of exactly the same thing except for the name of the NAS. Alternatively is there a way to "meta define" them under the single localhost entry so that it uses the actual NAS/client information instead of just using the name of the entry in clients.conf? Since all of the config is essentially exactly the same except for the IPs that seems like a lot of lines of configuration to maintain.
The sources are all on different IP addresses.
You could also use this in the log section msg_badpass = "IP:%{Packet-Src-IP-Address}" --- That just makes it log this: (from client localhost port 0) IP:127.0.0.1 So I guess I will have to just create 200 entries in clients.conf unless there is some way to just tell clients.conf to use this :%{Packet-Src-IP-Address} instead of it's own IP address in logging.
On 23/11/2021 13:34, Drew Weaver wrote:
That just makes it log this: (from client localhost port 0) IP:127.0.0.1
So I guess I will have to just create 200 entries in clients.conf unless there is some way to just tell clients.conf to use this :%{Packet-Src-IP-Address} instead of it's own IP address in logging.
As Alan has said, please post the full debug output. At this point we're just guessing. http://wiki.freeradius.org/list-help -- Matthew
Okay I don't think it is as complicated as I made it. All of the clients do indeed fall under the localhost definition in clients.conf If there is no way for me to configure clients.conf to use the IP of the actual client/NAS when it logs things under a single entry I will merely have to create and maintain 200 configuration entries in that file or use SQL or another way to define them. Thanks for your help. -Drew -----Original Message----- From: Freeradius-Users <freeradius-users-bounces+drew.weaver=thenap.com@lists.freeradius.org> On Behalf Of Matthew Newton Sent: Tuesday, November 23, 2021 8:37 AM To: freeradius-users@lists.freeradius.org Subject: Re: Add client IP address to log messages On 23/11/2021 13:34, Drew Weaver wrote:
That just makes it log this: (from client localhost port 0) IP:127.0.0.1
So I guess I will have to just create 200 entries in clients.conf unless there is some way to just tell clients.conf to use this :%{Packet-Src-IP-Address} instead of it's own IP address in logging.
As Alan has said, please post the full debug output. At this point we're just guessing. https://urldefense.proofpoint.com/v2/url?u=http-3A__wiki.freeradius.org_list... -- Matthew - List info/subscribe/unsubscribe? See https://urldefense.proofpoint.com/v2/url?u=http-3A__www.freeradius.org_list_...
One other question this brings up is do the entries in clients.conf respect precedent? Meaning if I define one other NAS/client while leaving the current localhost/127.0.0.1 entry in tact will it fall back to the 'global/default' entry if it can't find the specific one defined or is it either/or? I think that should be my last question, sorry for bothering you guys. -Drew -----Original Message----- From: Freeradius-Users <freeradius-users-bounces+drew.weaver=thenap.com@lists.freeradius.org> On Behalf Of Drew Weaver Sent: Tuesday, November 23, 2021 8:41 AM To: 'freeradius-users@lists.freeradius.org' <freeradius-users@lists.freeradius.org> Subject: RE: Add client IP address to log messages Okay I don't think it is as complicated as I made it. All of the clients do indeed fall under the localhost definition in clients.conf If there is no way for me to configure clients.conf to use the IP of the actual client/NAS when it logs things under a single entry I will merely have to create and maintain 200 configuration entries in that file or use SQL or another way to define them. Thanks for your help. -Drew -----Original Message----- From: Freeradius-Users <freeradius-users-bounces+drew.weaver=thenap.com@lists.freeradius.org> On Behalf Of Matthew Newton Sent: Tuesday, November 23, 2021 8:37 AM To: freeradius-users@lists.freeradius.org Subject: Re: Add client IP address to log messages On 23/11/2021 13:34, Drew Weaver wrote:
That just makes it log this: (from client localhost port 0) IP:127.0.0.1
So I guess I will have to just create 200 entries in clients.conf unless there is some way to just tell clients.conf to use this :%{Packet-Src-IP-Address} instead of it's own IP address in logging.
As Alan has said, please post the full debug output. At this point we're just guessing. https://urldefense.proofpoint.com/v2/url?u=http-3A__wiki.freeradius.org_list... -- Matthew - List info/subscribe/unsubscribe? See https://urldefense.proofpoint.com/v2/url?u=http-3A__www.freeradius.org_list_... - List info/subscribe/unsubscribe? See https://urldefense.proofpoint.com/v2/url?u=http-3A__www.freeradius.org_list_...
On Nov 23, 2021, at 8:40 AM, Drew Weaver <drew.weaver@thenap.com> wrote:
All of the clients do indeed fall under the localhost definition in clients.conf
I don't know what that means. localhost is 127.0.0.1, or more pedantically 127/8. Do you have multiple clients, all of which have "ipaddr = 127.0.0.1"? Or do you have something like: client locahost { ipaddr = 1.2.3.4 ... } client localhost { ipaddr = 5.6.7.8 ... }
If there is no way for me to configure clients.conf to use the IP of the actual client/NAS when it logs things under a single entry I will merely have to create and maintain 200 configuration entries in that file or use SQL or another way to define them.
Define *what*? I really have no idea what you're getting at. Please give *details* and *useful information*. And perhaps even DEBUG OUTPUT. If you're not going to do that, then there isn't much point in anyone answering your questions. You're just ignoring what we're saying, and repeating the same vague phrasing of "I'm trying to do stuff, and it doesn't work. How do I fix stuff?" Answer: I dunno. Do other stuff. Alan DeKok.
Sorry if I really was able to somehow make it that unclear but clients.conf only has the default localhost entry in it except for the secret is changed weekly. Nevermind, I will take care of it myself I don't really want to frustrate you anymore. -Drew -----Original Message----- From: Freeradius-Users <freeradius-users-bounces+drew.weaver=thenap.com@lists.freeradius.org> On Behalf Of Alan DeKok Sent: Tuesday, November 23, 2021 8:54 AM To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Subject: Re: Add client IP address to log messages On Nov 23, 2021, at 8:40 AM, Drew Weaver <drew.weaver@thenap.com> wrote:
All of the clients do indeed fall under the localhost definition in clients.conf
I don't know what that means. localhost is 127.0.0.1, or more pedantically 127/8. Do you have multiple clients, all of which have "ipaddr = 127.0.0.1"? Or do you have something like: client locahost { ipaddr = 1.2.3.4 ... } client localhost { ipaddr = 5.6.7.8 ... }
If there is no way for me to configure clients.conf to use the IP of the actual client/NAS when it logs things under a single entry I will merely have to create and maintain 200 configuration entries in that file or use SQL or another way to define them.
Define *what*? I really have no idea what you're getting at. Please give *details* and *useful information*. And perhaps even DEBUG OUTPUT. If you're not going to do that, then there isn't much point in anyone answering your questions. You're just ignoring what we're saying, and repeating the same vague phrasing of "I'm trying to do stuff, and it doesn't work. How do I fix stuff?" Answer: I dunno. Do other stuff. Alan DeKok. - List info/subscribe/unsubscribe? See https://urldefense.proofpoint.com/v2/url?u=http-3A__www.freeradius.org_list_...
Also it appears that our documentation was wrong anyway. We are using duo 2fa so I believe duo is proxying radius requests and it must not be forwarding the information to radiusd. Sorry for the noise/spam. -----Original Message----- From: Freeradius-Users <freeradius-users-bounces+drew.weaver=thenap.com@lists.freeradius.org> On Behalf Of Drew Weaver Sent: Tuesday, November 23, 2021 8:57 AM To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Subject: RE: Add client IP address to log messages Sorry if I really was able to somehow make it that unclear but clients.conf only has the default localhost entry in it except for the secret is changed weekly. Nevermind, I will take care of it myself I don't really want to frustrate you anymore. -Drew -----Original Message----- From: Freeradius-Users <freeradius-users-bounces+drew.weaver=thenap.com@lists.freeradius.org> On Behalf Of Alan DeKok Sent: Tuesday, November 23, 2021 8:54 AM To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Subject: Re: Add client IP address to log messages On Nov 23, 2021, at 8:40 AM, Drew Weaver <drew.weaver@thenap.com> wrote:
All of the clients do indeed fall under the localhost definition in clients.conf
I don't know what that means. localhost is 127.0.0.1, or more pedantically 127/8. Do you have multiple clients, all of which have "ipaddr = 127.0.0.1"? Or do you have something like: client locahost { ipaddr = 1.2.3.4 ... } client localhost { ipaddr = 5.6.7.8 ... }
If there is no way for me to configure clients.conf to use the IP of the actual client/NAS when it logs things under a single entry I will merely have to create and maintain 200 configuration entries in that file or use SQL or another way to define them.
Define *what*? I really have no idea what you're getting at. Please give *details* and *useful information*. And perhaps even DEBUG OUTPUT. If you're not going to do that, then there isn't much point in anyone answering your questions. You're just ignoring what we're saying, and repeating the same vague phrasing of "I'm trying to do stuff, and it doesn't work. How do I fix stuff?" Answer: I dunno. Do other stuff. Alan DeKok. - List info/subscribe/unsubscribe? See https://urldefense.proofpoint.com/v2/url?u=http-3A__www.freeradius.org_list_... - List info/subscribe/unsubscribe? See https://urldefense.proofpoint.com/v2/url?u=http-3A__www.freeradius.org_list_...
Drew Weaver <drew.weaver@thenap.com> wrote:
Also it appears that our documentation was wrong anyway. We are using duo 2fa so I believe duo is proxying radius requests and it must not be forwarding the information to radiusd.
Sorry for the noise/spam.
That would explain it. Duo does have a nice REST API you can use for authentications instead of their crummy RADIUS relay, but it's a roll-your-own solution requiring a lot of coding/testing. Also, if you aren't sure you are sticking with Duo, not a good idea since many of the other providers do not provide an easy REST API. You could probably find some way to tie customized logging from duoauthproxy to the pap messages but yes, the way 2FA providers just casually injects unnecessary low-feature-set relays into AAA setups makes things hard.
On Nov 23, 2021, at 8:08 AM, Drew Weaver <drew.weaver@thenap.com> wrote:
Since these are VPN servers all I really need to know is the IP address of the VPN server (or NAS) that the auth request originated from.
Define "request". For us, it's "RADIUS packet". If you mean something different, then say so. It helps very much to be clear in what you're asking. What information in the Access-Request? Read the debug output and see. Do you recognize any of the information? i.e. IPs, MAC address, etc.? If so, what does it mean? The problem here is that you're not posting the full debug output (or reading it). You're asking vague questions which we don't know the answer to. RADIUS is complex. We can't figure out *everything* from one line of the log file. That's why we keep asking for the debug output. And after 20 years, it's *still* a mystery why people don't post it.
I am not sure why or even how radiusd could think that the auth request is coming from itself but the requests are not sourced from the radius server to the radius server.
"localhost" is not just the RADIUS server. The RADIUS packets *are* coming from localhost. The logs you posted show this clearly. So either you named all clients "localhost" as Matthew suggested, or the packets really do come from localhost. Again, without the debug output, it's *impossible* for us to tell. And if you *do* read the debug output, I'll bet dollars to donuts that the information you need is there. "Oh, look! The IP of the VPN client is in attribute X! I can just log that" It really is that easy.
The sources are all on different IP addresses.
There are multiple pieces here. If you're not clear on what they are, then you won't be able to come up with a solution. In short, what's happening is this: * VPN client connects to VPN server * VPN server *acts as the RADIUS client*, and sends an Access-Request to the RADIUS server * This access request contains a bunch of information. We have NO IDEA what this is. And unless you read the debug output, you have no idea, either. * The RADIUS server *should* log ??something?? that it gets from ??somewhere??? What is that something? Read the debug output. All of the information which is available in the Access-Request is printed there. If the information you need isn't in the Access-Request, then go poke the VPN server to add it. No amount of changing FreeRADIUS will make the VPN server magically send the information that FreeRADIUS needs. And read the debug out. Really. Alan DeKok.
participants (4)
-
Alan DeKok -
Brian Julin -
Drew Weaver -
Matthew Newton