From 44eafeee62e6982131c62df6f74335114ca53024 Mon Sep 17 00:00:00 2001 From: Daniel Baumann Date: Mon, 26 Aug 2024 12:41:52 +0200 Subject: Adding upstream version 3.2.5+dfsg. Signed-off-by: Daniel Baumann --- raddb/clients.conf | 97 +++++++++++++++++++++++++++++++++++++++++++++--------- 1 file changed, 81 insertions(+), 16 deletions(-) (limited to 'raddb/clients.conf') diff --git a/raddb/clients.conf b/raddb/clients.conf index 60f9f4b..5f39ff1 100644 --- a/raddb/clients.conf +++ b/raddb/clients.conf @@ -8,6 +8,25 @@ # # Define RADIUS clients (usually a NAS, Access Point, etc.). +# +# There are a number of security practices which are critical in the +# modern era. +# +# * don't use RADIUS/UDP or RADIUS/TCP over the Internet. Use RADIUS/TLS. +# +# * If you do send RADIUS over UDP or TCP, don't send MS-CHAPv2. +# Anyone who can see the MS-CHAPv2 data can crack it in milliseconds. +# +# * use the "radsecret" program to generate secrets. It uses Perl (sorry). +# Every time you run it, it will generate a new strong secret. +# +# * don't create shared secrets yourself. Anything you create is likely to +# be in a "cracking" dictionary, and will allow a hobbyist attacker +# to crack the shared secret in a few minutes. +# +# * Don't trust anyone who tells you to ignore the above recommendations. +# + # # Defines a RADIUS client. # @@ -82,17 +101,33 @@ client localhost { # Quotation marks can be entered by escaping them, # e.g. "foo\"bar" # - # A note on security: The security of the RADIUS protocol + # A note on security: The security of the RADIUS protocol # depends COMPLETELY on this secret! We recommend using a - # shared secret that is composed of: + # shared secret that at LEAST 16 characters long. It should + # preferably be 32 characters in length. The secret MUST be + # random, and should not be words, phrase, or anything else + # that is recognisable. + # + # Computing power has increased enormously since RADIUS was + # first defined. A hobbyist with a high-end GPU can try ALL + # of the 8-character shared secrets in about a day. The + # security of shared secrets increases MUCH more with the + # length of the shared secret, than with number of different + # characters used in it. So don't bother trying to use + # "special characters" or anything else in an attempt to get + # un-guessable secrets. Instead, just get data from a secure + # random number generator, and use that. + # + # You should create shared secrets using a method like this: + # + # dd if=/dev/random bs=1 count=24 | base64 # - # upper case letters - # lower case letters - # numbers + # This process will give output which takes 24 random bytes, + # and converts them to 32 characters of ASCII. The output + # should be accepted by all RADIUS clients. # - # And is at LEAST 8 characters long, preferably 16 characters in - # length. The secret MUST be random, and should not be words, - # phrase, or anything else that is recognisable. + # You should NOT create shared secrets by hand. They will + # not be random. They will will be trivial to crack. # # The default secret below is only for testing, and should # not be used in any real environment. @@ -100,15 +135,45 @@ client localhost { secret = testing123 # - # Old-style clients do not send a Message-Authenticator - # in an Access-Request. RFC 5080 suggests that all clients - # SHOULD include it in an Access-Request. The configuration - # item below allows the server to require it. If a client - # is required to include a Message-Authenticator and it does - # not, then the packet will be silently discarded. + # The global configuration "security.require_message_authenticator" + # flag sets the default for all clients. That default can be + # over-ridden here, by setting it to a value. If no value is set, + # then the default from the "radiusd.conf" file is used. + # + # See that file for full documentation on the flag, along + # with allowed values and meanings. + # + # This flag exists solely for legacy clients which do not send + # Message-Authenticator in all Access-Request packets. We do not + # recommend setting it to "no". + # + # The number one way to protect yourself from the BlastRADIUS + # attack is to update all RADIUS servers, and then set this + # flag to "yes". If all RADIUS servers are updated, and if + # all of them have this flag set to "yes" for all clients, + # then your network is safe. You can then upgrade the + # clients when it is convenient, instead of rushing the + # upgrades. + # + # allowed values: yes, no, auto + # +# require_message_authenticator = no + + # + # The global configuration "security.limit_proxy_state" + # flag sets the default for all clients. That default can be + # over-ridden here, by setting it to "no". + # + # See that file for full documentation on the flag, along + # with allowed values,and meanings. + # + # This flag exists solely for legacy clients which do not send + # Message-Authenticator in all Access-Request packets. We do not + # recommend setting it to "no". + # + # allowed values: yes, no, auto # - # allowed values: yes, no - require_message_authenticator = no +# limit_proxy_state = yes # # The short name is used as an alias for the fully qualified -- cgit v1.2.3