Hi,
I'm using radsecproxy to pass RADIUS auths from our ORPS machine to the
upstream national radius proxy service .
Looking at the log file I'm seeing access-rejects being sent down
generating log entries of the form
Oct 4 15:47:09 2017: Access-Reject for user
0234105273270593(a)wlan.mnc010.mcc234.3gppnetwork.org stationid
2C-0E-3D-05-37-86 from roaming0.ja.net (Request Denied) to fromFR
(127.0.0.1)
What I'd like to do is reject these locally in radsecproxy.conf. I thought
that
realm /.*\\.3gppnetwork\\.org$/ {
replymessage "Misconfigured client: Rejected by eduroam1.york.ac.uk
!"
}
would stop these from being passed onwards. As the log entry above shows,
it doesn't !
The statement is at the top of my realm statement lists with
realm * {
server roaming0.ja.net
server roaming1.ja.net
}
at the bottom.
What's wrong with my realm statement?
Rgds
Alex
Hi all!
Let me say first that I'm not entirely sure whether I should write this directly to the Debian guys, however, I'd like to discuss some stuff first with you guys to clear up some questions. I hope that Faidon (who maintains the Debian package) is reading this and can help to shed some light on this. :)
We usually build radsecproxy on Ubuntu 16.04.3 LTS from the sources from Debian:
https://packages.debian.org/de/source/sid/radsecproxy
This used to work well with 1.6.8 and (apart from one problematic dependency on debhelper >=10) it should work with 1.6.9 as well. I have a number of suggestions regarding the Debian build:
- Currently, the resulting radsecproxy will run as root. I think it would be nicer to have the daemon run as some unprivileged user (e.g. "radsecproxy").
- In the current Ubuntu release (could very likely be the same with the current Debian release), there's a rather stupid bug in systemd where you can write an arbitrary number (e.g. "1") into radsecproxy's PID file and as soon as the service radsecproxy is stopped, the process that you put into the PID file is killed (which is not so nice if it's "1"). Now, while it's unclear how easily exploitable this is, it's still easy to cure.
I would like to discuss the following patches to the Debian build tree with you. I don't have any experiences with Debian package design so please be patient if it has mistakes. :)
Patch #1:
--------8<--------8<--------8<--------8<--------8<--------
--- radsecproxy-1.6.9.old/debian/service 2017-08-04 21:12:38.000000000 +0200
+++ radsecproxy-1.6.9/debian/service 2017-08-18 07:56:46.080064099 +0200
@@ -6,12 +6,13 @@
[Service]
Type=forking
-ExecStart=/usr/sbin/radsecproxy -i /run/radsecproxy.pid
-PIDFile=/run/radsecproxy.pid
+ExecStart=/usr/sbin/radsecproxy
+User=radsecproxy
ProtectSystem=full
PrivateDevices=true
PrivateTmp=true
ProtectHome=true
+CapabilityBoundingSet=~CAP_SYS_PTRACE
[Install]
WantedBy=multi-user.target
--------8<--------8<--------8<--------8<--------8<--------
Explanation: systemd doesn't need the PID file to know about the PID that radsecproxy runs with. So you can remove the creation of a PID file entirely as well as the PIDFile= reference to it, working around the security risk above. Furthermore, the patch makes systemd run radsecproxy as user "radsecproxy". For this to be possible, we need...
Patch #2:
Add radsecproxy-1.6.9/debian/postinst
--------8<--------8<--------8<--------8<--------8<--------
adduser --system radsecproxy
--------8<--------8<--------8<--------8<--------8<--------
Could you guys have a look at the above suggestions for patches and let me know what you think? Please note that this only addresses the systemd service file, I didn't patch the init file (which would certainly also make sense at least to let radsecproxy run as an unprivileged user).
Note to Faidon: I like the changes that you made to harden the radsecproxy installation when using systemd. Thanks for the good work! I have a question though: how important is the dependency "debhelper >=10"? I'm asking because the latest debhelper on Ubuntu 16.04.3 LTS is 9.x. If possible, can I change the debhelper dependency to ">=9" again? This would certainly help building the package on Ubuntu 16.04.3 LTS. Thanks!
Cheers,
Christian
--
Dipl.-Math. Christian Strauf
Clausthal Univ. of Technology E-Mail: strauf(a)rz.tu-clausthal.de
Rechenzentrum Web: www.rz.tu-clausthal.de
Erzstraße 18 Tel.: +49-5323-72-2086 Fax: -992086
D-38678 Clausthal-Zellerfeld
Hi,
I'm pleased to announce that radsecproxy-1.6.9 now exists.
This bugfix release fixes a crash bug showing on busy servers with
multiple cores (RADSECPROXY-77) and a number of other bugs. From the
ChangeLog file:
--8<---------------cut here---------------start------------->8---
Misc:
- Use a listen(2) backlog of 128 (RADSECPROXY-72).
Bug fixes:
- Don't follow NULL the pointer at debug level 5 (RADSECPROXY-68).
- Completely reload CAs and CRLs with cacheExpiry (RADSECPROXY-50).
- Tie Access-Request log lines to response log lines (RADSECPROXY-60).
- Fix a couple of memory leaks and NULL ptr derefs in error cases.
- Take lock on realm refcount before updating it (RADSECPROXY-77).
--8<---------------cut here---------------end--------------->8---
Pick it up at
https://software.nordu.net/radsecproxy/radsecproxy-1.6.9.tar.xzhttps://software.nordu.net/radsecproxy/radsecproxy-1.6.9.tar.xz.asc
Hi,
I'm planning on releasing what's in branch maint-1.6 as
radsecproxy-1.6.9 within a couple of hours. If you're interested in
finding stupid things in it before it becomes an official release,
please try it out now!
git clone -b maint-1.6 https://git.nordu.net/radsecproxy.git
cd radsecproxy && ./configure && make clean check
Thanks!
Hi!
I'm using yesterday's git checkout. Routing of the requests to our
own RADIUS and germany's DFN Radius server is working OK!
Questions:
==========
* Currently, radsecproxy is running as root.
Is that necessary? It's not binding to any privileged ports.
* Can radsecproxy run chrooted?
* during our 2 days of operation, it crashed three times - which is
why I compiled the lasted version manually instead of using Ubuntu's
packages:
Jul 5 14:51:43 radius-ext kernel: [5611.904760] radsecproxy[2710]: segfault at d8 ip 00007f0717424518 sp 00007f07183e4e20 error 6 in libc-2.23.so[7f071733c000+1c0000]
Jul 6 09:28:46 radius-ext kernel: [72633.333687] radsecproxy[21034]: segfault at d8 ip 00007f5c647d8518 sp 00007f5c65798e30 error 6 in libc-2.23.so[7f5c646f0000+1c0000]
Jul 6 12:15:19 radius-ext kernel: [82626.748886] radsecproxy[120425]: segfault at d8 ip 00007f1267ec5518 sp 00007f1268e3bd50 error 6 in libc-2.23.so[7f1267ddd000+1c0000]
How do I debug this; is it dumping cores even when running as root?
--
Ralf Hildebrandt Charite Universitätsmedizin Berlin
ralf.hildebrandt(a)charite.de Campus Benjamin Franklin
https://www.charite.de Hindenburgdamm 30, 12203 Berlin
Geschäftsbereich IT, Abt. Netzwerk fon: +49-30-450.570.155
Hi all,
I installed radsecproxy on Debian 9.
How can I test the connection to a remote Windows 2007 Radius Server (ADS)?
Regards
Bernd
--
Mit freundlichen Gruessen
Bernd Schlichting
Leibniz Institut fuer Ostseeforschung
Bereich EDV
Seestrasse 15
18119 Warnemuende
Tel.: 0049 381 5197455
Fax.: 0049 381 51974848
Hello All,
I would like to let me know abt my requirement first,
We have a project running under RADIUS under UDP that means we have a
existing architecture and APIs to support all the user authentication to
RADIUS server via PAP and CHAP under UDP.
We are running on top of FreeBSD OS.
Requirment:
We need the same authentication to happen over a secure network where we
need to implement RADIUS TCP/TLS .I need to change my client configuration
and required code changes has to be done to adapt with RADIUS server so wher
I can be getting client side code to implement RADIUS over TLS.
Queries:
What should I start with?
Is RadSecProxy will be helpful for me at any point of view?
How and where should I implement RADIUS/TLS and client configuration and
codes.
Your reply will be much appreciated.
Thanks & Regards,
Javed Akhtar
Technical Lead
<mailto:jaakhtar@cisco.com> jaakhtar(a)cisco.com
Tel:
Cisco Systems, Inc.
India
cisco.com
Think before you print.
This email may contain confidential and privileged material for the sole use
of the intended recipient. Any review, use, distribution or disclosure by
others is strictly prohibited. If you are not the intended recipient (or
authorized to receive for the recipient), please contact the sender by reply
email and delete all copies of this message.
Please <http://www.cisco.com/web/about/doing_business/legal/cri/index.html>
click here for Company Registration Information.
