rlm_python: Access Request source IP Address is missing from authorize(p) function argument
Hi! I'd like to be able to work in my python authorize function with the IP address of the NAS interface from which Access-Request is received (external). From the radiusd -X output this is the A1.A2.A3.A4 address I am interested in. ========================================= Received Access-Request Id 7 from A1.A2.A3.A4:54594 to B1.B2.B3.B4:1812 length 415 ========================================== This is the same IP address that gets tested against shared secret configured in clients.conf Unfortunately, the tuple (p) that gets passed to the authorize function (authorize(p)) by rlm_python has a different (internal) NAS-IP-Address, which is of no use to me. If radiusd is in principle aware of the A1.A2.A3.A4 IP address I am interested in, how can I gain access to it in my python authorize(p) or any other function? Thank you, Gleb
On May 29, 2020, at 11:28 PM, Gleb Lisikh <in4bit.general@gmail.com> wrote:
I'd like to be able to work in my python authorize function with the IP address of the NAS interface from which Access-Request is received (external). From the radiusd -X output this is the A1.A2.A3.A4 address I am interested in. ========================================= Received Access-Request Id 7 from A1.A2.A3.A4:54594 to B1.B2.B3.B4:1812 length 415 ========================================== This is the same IP address that gets tested against shared secret configured in clients.conf
Unfortunately, the tuple (p) that gets passed to the authorize function (authorize(p)) by rlm_python has a different (internal) NAS-IP-Address, which is of no use to me.
The attributes which get passed to Python are the ones in the packet. Not the various IP / UDP headers.
If radiusd is in principle aware of the A1.A2.A3.A4 IP address I am interested in, how can I gain access to it in my python authorize(p) or any other function?
You can get the source IP and convert it to a real attribute: update request { Packet-Src-IP-Address := "%{Packet-Src-IP-Address}" } It's a little weird, but this "realizes" the virtual src IP into a real attribute. Alan DeKok.
Awesome, thanks! This seems like exactly what I need, even though it is indeed a bit weird. Where would you suggest to insert this 'update request' piece of code? Would you be able to point me to the doc's describing how to work with the UDP/IP packet data? I might need to get more from the headers than just IP address. Thanks again for your help! On Sat, May 30, 2020, 09:21 Alan DeKok, <aland@deployingradius.com> wrote:
On May 29, 2020, at 11:28 PM, Gleb Lisikh <in4bit.general@gmail.com> wrote:
I'd like to be able to work in my python authorize function with the IP address of the NAS interface from which Access-Request is received (external). From the radiusd -X output this is the A1.A2.A3.A4 address I
am
interested in. ========================================= Received Access-Request Id 7 from A1.A2.A3.A4:54594 to B1.B2.B3.B4:1812 length 415 ========================================== This is the same IP address that gets tested against shared secret configured in clients.conf
Unfortunately, the tuple (p) that gets passed to the authorize function (authorize(p)) by rlm_python has a different (internal) NAS-IP-Address, which is of no use to me.
The attributes which get passed to Python are the ones in the packet. Not the various IP / UDP headers.
If radiusd is in principle aware of the A1.A2.A3.A4 IP address I am interested in, how can I gain access to it in my python authorize(p) or any other function?
You can get the source IP and convert it to a real attribute:
update request { Packet-Src-IP-Address := "%{Packet-Src-IP-Address}" }
It's a little weird, but this "realizes" the virtual src IP into a real attribute.
Alan DeKok.
On May 30, 2020, at 10:41 AM, Gleb Lisikh <in4bit.general@gmail.com> wrote:
Awesome, thanks! This seems like exactly what I need, even though it is indeed a bit weird.
Where would you suggest to insert this 'update request' piece of code?
Anywhere before you run the "python" module.
Would you be able to point me to the doc's describing how to work with the UDP/IP packet data? I might need to get more from the headers than just IP address.
You can get Packet-Src-IP-Address, Packet-Src-Port, Packet-Dst-IP-Address, and Packet-Dst-Port I'm not sure what other fields you'd need. Alan DeKok.
I might need source MAC Gleb On Sat, May 30, 2020 at 11:16 AM Alan DeKok <aland@deployingradius.com> wrote:
On May 30, 2020, at 10:41 AM, Gleb Lisikh <in4bit.general@gmail.com> wrote:
Awesome, thanks! This seems like exactly what I need, even though it is
indeed a bit weird.
Where would you suggest to insert this 'update request' piece of code?
Anywhere before you run the "python" module.
Would you be able to point me to the doc's describing how to work with the UDP/IP packet data? I might need to get more from the headers than just IP address.
You can get Packet-Src-IP-Address, Packet-Src-Port, Packet-Dst-IP-Address, and Packet-Dst-Port
I'm not sure what other fields you'd need.
Alan DeKok.
On May 31, 2020, at 12:09 PM, Gleb Lisikh <in4bit.general@gmail.com> wrote:
I might need source MAC
That's just not available. The only way to get that is with PCAP. The standard socket APIs don't supply that. And I'm curious why source MAC matters. If you need to see which machine sent the RADIUS packet, look at (a) source IP, or (b) NAS-Identifier. The NAS-Identifier is supposed to identity a NAS. Source MAC tells you pretty much nothing. Alan DeKok.
Hi Alan, In the current lab setup I do get NAS MAC in a request packet in "Called-Station-Id". Well... this is not MAC field strictly speaking, of course, but the MAC is there because of the way NAS identifies itself in this case, and which obviously cannot be relied upon in all the cases. I was merely looking for more ways of validating NAS, because IP address can change, so can MAC, but unlikely both at the same time. Hope this makes sense. Making progress slowly but surely - thanks to you ! Gleb On Sun, May 31, 2020 at 12:23 PM Alan DeKok <aland@deployingradius.com> wrote:
On May 31, 2020, at 12:09 PM, Gleb Lisikh <in4bit.general@gmail.com> wrote:
I might need source MAC
That's just not available. The only way to get that is with PCAP. The standard socket APIs don't supply that.
And I'm curious why source MAC matters. If you need to see which machine sent the RADIUS packet, look at (a) source IP, or (b) NAS-Identifier.
The NAS-Identifier is supposed to identity a NAS. Source MAC tells you pretty much nothing.
Alan DeKok.
participants (2)
-
Alan DeKok -
Gleb Lisikh