From 115ae30929aeb4b9ea63c62cbc1dbdfbcfce41a8 Mon Sep 17 00:00:00 2001 From: Jakob Lechner Date: Thu, 4 Aug 2022 03:03:55 +0000 Subject: [PATCH] Remove unused sites --- .../raddb/sites-available/README | 335 --------- .../raddb/sites-available/abfab-tls | 118 ---- .../raddb/sites-available/abfab-tr-idp | 198 ------ .../raddb/sites-available/buffered-sql | 161 ----- .../raddb/sites-available/challenge | 123 ---- .../raddb/sites-available/channel_bindings | 17 - .../raddb/sites-available/check-eap-tls | 135 ---- .../raddb/sites-available/coa | 49 -- .../raddb/sites-available/coa-relay | 331 --------- .../raddb/sites-available/control-socket | 92 --- .../sites-available/copy-acct-to-home-server | 202 ------ .../sites-available/decoupled-accounting | 139 ---- .../raddb/sites-available/dhcp | 584 ---------------- .../raddb/sites-available/dhcp.relay | 44 -- .../raddb/sites-available/dynamic-clients | 222 ------ .../raddb/sites-available/example | 122 ---- .../raddb/sites-available/originate-coa | 185 ----- .../raddb/sites-available/proxy-inner-tunnel | 47 -- .../raddb/sites-available/resource-check | 140 ---- .../sites-available/robust-proxy-accounting | 167 ----- .../raddb/sites-available/soh | 34 - .../raddb/sites-available/status | 127 ---- .../raddb/sites-available/tls | 651 ------------------ .../raddb/sites-available/totp | 85 --- .../raddb/sites-available/virtual.example.com | 32 - .../raddb/sites-available/vmps | 98 --- 26 files changed, 4438 deletions(-) delete mode 100644 pkgs/fablab/freeradius-anon-access/raddb/sites-available/README delete mode 100644 pkgs/fablab/freeradius-anon-access/raddb/sites-available/abfab-tls delete mode 100644 pkgs/fablab/freeradius-anon-access/raddb/sites-available/abfab-tr-idp delete mode 100644 pkgs/fablab/freeradius-anon-access/raddb/sites-available/buffered-sql delete mode 100644 pkgs/fablab/freeradius-anon-access/raddb/sites-available/challenge delete mode 100644 pkgs/fablab/freeradius-anon-access/raddb/sites-available/channel_bindings delete mode 100644 pkgs/fablab/freeradius-anon-access/raddb/sites-available/check-eap-tls delete mode 100644 pkgs/fablab/freeradius-anon-access/raddb/sites-available/coa delete mode 100644 pkgs/fablab/freeradius-anon-access/raddb/sites-available/coa-relay delete mode 100644 pkgs/fablab/freeradius-anon-access/raddb/sites-available/control-socket delete mode 100644 pkgs/fablab/freeradius-anon-access/raddb/sites-available/copy-acct-to-home-server delete mode 100644 pkgs/fablab/freeradius-anon-access/raddb/sites-available/decoupled-accounting delete mode 100644 pkgs/fablab/freeradius-anon-access/raddb/sites-available/dhcp delete mode 100644 pkgs/fablab/freeradius-anon-access/raddb/sites-available/dhcp.relay delete mode 100644 pkgs/fablab/freeradius-anon-access/raddb/sites-available/dynamic-clients delete mode 100644 pkgs/fablab/freeradius-anon-access/raddb/sites-available/example delete mode 100644 pkgs/fablab/freeradius-anon-access/raddb/sites-available/originate-coa delete mode 100644 pkgs/fablab/freeradius-anon-access/raddb/sites-available/proxy-inner-tunnel delete mode 100644 pkgs/fablab/freeradius-anon-access/raddb/sites-available/resource-check delete mode 100644 pkgs/fablab/freeradius-anon-access/raddb/sites-available/robust-proxy-accounting delete mode 100644 pkgs/fablab/freeradius-anon-access/raddb/sites-available/soh delete mode 100644 pkgs/fablab/freeradius-anon-access/raddb/sites-available/status delete mode 100644 pkgs/fablab/freeradius-anon-access/raddb/sites-available/tls delete mode 100644 pkgs/fablab/freeradius-anon-access/raddb/sites-available/totp delete mode 100644 pkgs/fablab/freeradius-anon-access/raddb/sites-available/virtual.example.com delete mode 100644 pkgs/fablab/freeradius-anon-access/raddb/sites-available/vmps diff --git a/pkgs/fablab/freeradius-anon-access/raddb/sites-available/README b/pkgs/fablab/freeradius-anon-access/raddb/sites-available/README deleted file mode 100644 index 7e0f27c..0000000 --- a/pkgs/fablab/freeradius-anon-access/raddb/sites-available/README +++ /dev/null @@ -1,335 +0,0 @@ -1. Virtual Servers. - - FreeRADIUS 3.0 supports virtual servers. This is probably the -single largest change that is NOT backwards compatible with 1.x. - - The virtual servers do NOT have to be set up with the -"sites-available" and "sites-enabled" directories. You can still have -one "radiusd.conf" file, and put the server configuration there: - - ... - server { - authorize { - ... - } - authenticate { - ... - } - ... - } - ... - - The power of virtual servers lies in their ability to separate -policies. A policy can be placed into a virtual server, where it is -guaranteed to affect only the requests that are passed through that -virtual server. In 1.x, the policies were global, and it sometimes -took much effort to write a policy so that it only applied in certain -limited situations. - - -2. What do we mean by "virtual server"? - - - A virtual server is a (nearly complete) RADIUS server, just like a -configuration for FreeRADIUS 1.x. However, FreeRADIUS can now run -multiple virtual servers at the same time. The virtual servers can -even proxy requests to each other! - - The simplest way to create a virtual server is to take the all of -the request processing sections from radius.conf, ("authorize" , -"authenticate", etc.) and wrap them in a "server {}" block, as above. - - You can create another virtual server by: - - 1) defining a new "server foo {...}" section in radiusd.conf - 2) Putting the normal "authorize", etc. sections inside of it - 3) Adding a "listen" section *inside* of the "server" section. - - e.g. - - ... - server foo { - listen { - ipaddr = 127.0.0.1 - port = 2000 - type = auth - } - - authorize { - update control { - Cleartext-Password := "bob" - } - pap - } - - authenticate { - pap - } - } - ... - - With that text added to "radiusd.conf", run the server in debugging -mode (radiusd -X), and in another terminal window, type: - -$ radtest bob bob localhost:2000 0 testing123 - - You should see the server return an Access-Accept. - - -3. Capabilities and limitations - - - The only sub-sections that can appear in a virtual server section -are: - - listen - client - authorize - authenticate - post-auth - pre-proxy - post-proxy - preacct - accounting - session - - All other configuration parameters (modules, etc.) are global. - - Inside of a virtual server, the authorize, etc. sections have their -normal meaning, and can contain anything that an authorize section -could contain in 1.x. - - When a "listen" section is inside of a virtual server definition, it -means that all requests sent to that IP/port will be processed through -the virtual server. There cannot be two "listen" sections with the -same IP address and port number. - - When a "client" section is inside of a virtual server definition, it -means that that client is known only to the "listen" sections that are -also inside of that virtual server. Not only is this client -definition available only to this virtual server, but the details of -the client configuration is also available only to this virtual -server. - - i.e. Two virtual servers can listen on different IP address and -ports, but both can have a client with IP address 127.0.0.1. The -shared secret for that client can be different for each virtual -server. - - -4. More complex "listen" capabilities - - The "listen" sections have a few additional configuration items that -were not in 1.x, and were not mentioned above. These configuration -items enable almost any mapping of IP / port to clients to virtual -servers. - - The configuration items are: - - virtual_server = - - If set, all requests sent to this IP / port are processed - through the named virtual server. - - This directive can be used only for "listen" sections - that are global. i.e. It CANNOT be used if the - "listen" section is inside of a virtual server. - - clients = - - If set, the "listen" section looks for a "clients" section: - - clients { - ... - } - - It looks inside of that named "clients" section for - "client" subsections, at least one of which must - exist. Each client in that section is added to the - list of known clients for this IP / port. No other - clients are known. - - If it is set, it over-rides the list of clients (if - any) in the same virtual server. Note that the - clients are NOT additive! - - If it is not set, then the clients from the current - virtual server (if any) are used. If there are no - clients in this virtual server, then the global - clients are used. - - i.e. The most specific directive is used: - * configuration in this "listen" section - * clients in the same virtual server - * global clients - - The directives are also *exclusive*, not *additive*. - If you have one client in a virtual server, and - another client referenced from a "listen" section, - then that "listen" section will ONLY use the second - client. It will NOT use both clients. - - -5. More complex "client" capabilities - - The "client" sections have a few additional configuration items that -were not in 1.x, and were not mentioned above. These configuration -items enable almost any mapping of IP / port to clients to virtual -servers. - - The configuration items are: - - virtual_server = - - If set, all requests from this client are processed - through the named virtual server. - - This directive can be used only for "client" sections - that are global. i.e. It CANNOT be used if the - "client" section is inside of a virtual server. - - If the "listen" section has a "server" entry, and a matching -client is found ALSO with a "server" entry, then the clients server is -used for that request. - - -6. Worked examples - - - Listening on one socket, and mapping requests from two clients to -two different servers. - - listen { - ... - } - client one { - ... - virtual_server = server_one - } - client two { - ... - virtual_server = server_two - } - server server_one { - authorize { - ... - } - ... - } - server server_two { - authorize { - ... - } - ... - } - - This could also be done as: - - - listen { - ... - virtual_server = server_one - } - client one { - ... - } - client two { - ... - virtual_server = server_two - } - server server_one { - authorize { - ... - } - ... - } - server server_two { - authorize { - ... - } - ... - } - - In this case, the default server for the socket is "server_one", so -there is no need to set that in the client "one" configuration. The -"server_two" configuration for client "two" over-rides the default -setting for the socket. - - Note that the following configuration will NOT work: - - listen { - ... - virtual_server = server_one - } - client one { - ... - } - server server_one { - authorize { - ... - } - ... - } - server server_two { - client two { - ... - } - authorize { - ... - } - ... - } - - In this example, client "two" is hidden inside of the virtual -server, where the "listen" section cannot find it. - - -7. Outlined examples - - This section outlines a number of examples, with alternatives. - - One server, multiple sockets - - multiple "listen" sections in a "server" section - - one server per client - - define multiple servers - - have a global "listen" section - - have multiple global "clients", each with "virtual_server = X" - - two servers, each with their own sockets - - define multiple servers - - put "client" sections into each "server" - - put a "listen" section into each "server" - - Each server can list the same client IP, and the secret - can be different - - two sockets, sharing a list of clients, but pointing to different servers - - define global "listen" sections - - in each, set "virtual_server = X" - - in each, set "clients = Y" - - define "clients Y" section, containing multiple clients. - - This also means that you can have a third socket, which - doesn't share any of these clients. - - -8. How to decide what to do - - - If you want *completely* separate policies for a socket or a client, -then create a separate virtual server. Then, map the request to that -server by setting configuration entries in a "listen" section or in a -"client" section. - - Start off with the common cases first. If most of the clients -and/or sockets get a particular policy, make that policy the default. -Configure it without paying attention to the sockets or clients you -want to add later, and without adding a second virtual server. Once -it works, then add the second virtual server. - - If you want to re-use the previously defined sockets with the second -virtual server, then you will need one or more global "client" -sections. Those clients will contain a "virtual_server = ..." entry -that will direct requests from those clients to the appropriate -virtual server. diff --git a/pkgs/fablab/freeradius-anon-access/raddb/sites-available/abfab-tls b/pkgs/fablab/freeradius-anon-access/raddb/sites-available/abfab-tls deleted file mode 100644 index b4384ad..0000000 --- a/pkgs/fablab/freeradius-anon-access/raddb/sites-available/abfab-tls +++ /dev/null @@ -1,118 +0,0 @@ -# -# Example configuration for ABFAB listening on TLS. -# -# $Id: b8d0626bbe8923a97506b7410e83f88e3af4c42a $ -# -listen { - ipaddr = * - port = 2083 - type = auth - proto = tcp - - tls { - tls_min_version = "1.2" - private_key_password = whatever - - # Moonshot tends to distribute certs separate from keys - private_key_file = ${certdir}/server.key - certificate_file = ${certdir}/server.pem - ca_file = ${cadir}/ca.pem - dh_file = ${certdir}/dh - fragment_size = 8192 - ca_path = ${cadir} - cipher_list = "DEFAULT" - cache { - enable = no - lifetime = 24 # hours - name = "abfab-tls" - # persist_dir = ${logdir}/abfab-tls - } - require_client_cert = yes - verify { - } - - psk_query = "%{psksql:select hex(key) from psk_keys where keyid = '%{TLS-PSK-Identity}'}" - } - - virtual_server = abfab-idp - clients = radsec-abfab -} - -# There needs to be a separated "listen" section for IPv6. -# Typically it will be identical to the IPv4 one above, but there might be -# some differences (e.g. if a different certificate or port is desired) -listen { - ipaddr = :: - port = 2083 - type = auth - proto = tcp - - tls { - tls_min_version = "1.2" - private_key_password = whatever - - # Moonshot tends to distribute certs separate from keys - private_key_file = ${certdir}/server.key - certificate_file = ${certdir}/server.pem - ca_file = ${cadir}/ca.pem - dh_file = ${certdir}/dh - fragment_size = 8192 - ca_path = ${cadir} - cipher_list = "DEFAULT" - cache { - enable = no - lifetime = 24 # hours - name = "abfab-tls" - # persist_dir = ${logdir}/abfab-tls - } - require_client_cert = yes - verify { - } - - psk_query = "%{psksql:select hex(key) from psk_keys where keyid = '%{TLS-PSK-Identity}'}" - } - - virtual_server = abfab-idp - clients = radsec-abfab -} - -clients radsec-abfab { - # - # Allow all clients, but require TLS. - # This client stanza will match other RP proxies from other - # realms established via the trustrouter. In general - # additional client stanzas are also required for local services. - # - client default { - ipaddr = 0.0.0.0/0 - proto = tls - } - - client default_ip6 { - ipaddr = ::/0 - proto = tls - } - - # An example local service - # client service_1 { - # ipaddr = 192.0.2.20 - # # You should either set gss_acceptor_host_name below - # # or set up policy to confirm that a client claims - # # the right acceptor hostname when using ABFAB. If - # # set, the RADIUS server will confirm that all - # # requests have this value for the acceptor host name - # gss_acceptor_host_name = "server.example.com" - # # If set, this acceptor realm name will be included. - # # Foreign realms will typically reject a request if this is not - # # properly set. - # gss_acceptor_realm_name = "example.com" - # # Additionally, trust_router_coi can be set; if set - # # it will override the default_community in the realm - # # module - # trust_router_coi = "community1.example.net" - # # In production depployments it is important to set - # # up certificate verification so that even if - # # clients spoof IP addresses, one client cannot - # # impersonate another. - # } -} diff --git a/pkgs/fablab/freeradius-anon-access/raddb/sites-available/abfab-tr-idp b/pkgs/fablab/freeradius-anon-access/raddb/sites-available/abfab-tr-idp deleted file mode 100644 index d820a85..0000000 --- a/pkgs/fablab/freeradius-anon-access/raddb/sites-available/abfab-tr-idp +++ /dev/null @@ -1,198 +0,0 @@ -# -# This file represents a server that is implementing an identity -# provider for GSS-EAP (RFC 7055) using the trust router -# protocol for dynamic realm discovery. Any ABFAB identity -# provider is also an ABFAB relying party proxy. -# -# This file does not include a TLS listener; see abfab-tls for a simple -# example of a RADSEC listener for ABFAB. -# -# $Id: be98568d3b16a163fdcd1803b171450a7b7d42da $ -# - -server abfab-idp { -authorize { - psk_authorize - abfab_client_check - filter_username - preprocess - - # If you intend to use CUI and you require that the Operator-Name - # be set for CUI generation and you want to generate CUI also - # for your local clients then uncomment the operator-name - # below and set the operator-name for your clients in clients.conf -# operator-name - - # - # If you want to generate CUI for some clients that do not - # send proper CUI requests, then uncomment the - # cui below and set "add_cui = yes" for these clients in clients.conf -# cui - - # - # Do RFC 7542 bang path routing. If you want to only do standard - # RADIUS NAI routing, comment out the below line. - rfc7542 - - # Standard RADIUS NAI routing - if (!updated) { - suffix { - updated = 1 - noop = reject - } - } - - eap { - ok = return - } - - expiration - logintime -} - -authenticate { - # - # Allow EAP authentication. - eap -} - -# Post-Authentication -# Once we KNOW that the user has been authenticated, there are -# additional steps we can take. -post-auth { - # - # For EAP-TTLS and PEAP, add the cached attributes to the reply. - # The "session-state" attributes are automatically cached when - # an Access-Challenge is sent, and automatically retrieved - # when an Access-Request is received. - # - # The session-state attributes are automatically deleted after - # an Access-Reject or Access-Accept is sent. - # - # If both session-state and reply contain a User-Name attribute, remove - # the one in the reply if it is just a copy of the one in the request, so - # we don't end up with two User-Name attributes. - - if (session-state:User-Name && reply:User-Name && request:User-Name && (reply:User-Name == request:User-Name)) { - update reply { - &User-Name !* ANY - } - } - update { - &reply: += &session-state: - } - - # Create the CUI value and add the attribute to Access-Accept. - # Uncomment the line below if *returning* the CUI. -# cui - - # - # If you want to have a log of authentication replies, - # un-comment the following line, and enable the - # 'detail reply_log' module. -# reply_log - - # - # After authenticating the user, do another SQL query. - # - # See "Authentication Logging Queries" in `mods-config/sql/main/$driver/queries.conf` - -sql - - # - # Un-comment the following if you want to modify the user's object - # in LDAP after a successful login. - # -# ldap - - # For Exec-Program and Exec-Program-Wait - exec - # Remove reply message if the response contains an EAP-Message - remove_reply_message_if_eap - # Access-Reject packets are sent through the REJECT sub-section of the - # post-auth section. - # - # Add the ldap module name (or instance) if you have set - # 'edir = yes' in the ldap module configuration - # - Post-Auth-Type REJECT { - # log failed authentications in SQL, too. - -sql - attr_filter.access_reject - - # Insert EAP-Failure message if the request was - # rejected by policy instead of because of an - # authentication failure And already has an EAP message - # For non-ABFAB, we insert the failure all the time, but for ABFAB - # It's more desirable to preserve reply-message when we can - if (&reply:Eap-Message) { - eap - } - - # Remove reply message if the response contains an EAP-Message - remove_reply_message_if_eap - } -} -# -# When the server decides to proxy a request to a home server, -# the proxied request is first passed through the pre-proxy -# stage. This stage can re-write the request, or decide to -# cancel the proxy. -# -# Only a few modules currently have this method. -# -pre-proxy { - # Before proxing the request add an Operator-Name attribute identifying - # if the operator-name is found for this client. - # No need to uncomment this if you have already enabled this in - # the authorize section. -# operator-name - - # The client requests the CUI by sending a CUI attribute - # containing one zero byte. - # Uncomment the line below if *requesting* the CUI. -# cui - - # Uncomment the following line if you want to change attributes - # as defined in the preproxy_users file. -# files - - # Uncomment the following line if you want to filter requests - # sent to remote servers based on the rules defined in the - # 'attrs.pre-proxy' file. -# attr_filter.pre-proxy - - # If you want to have a log of packets proxied to a home - # server, un-comment the following line, and the - # 'detail pre_proxy_log' section, above. -# pre_proxy_log -} -# -# When the server receives a reply to a request it proxied -# to a home server, the request may be massaged here, in the -# post-proxy stage. -# -post-proxy { - - # If you want to have a log of replies from a home server, - # un-comment the following line, and the 'detail post_proxy_log' - # section, above. -# post_proxy_log - - # Uncomment the following line if you want to filter replies from - # remote proxies based on the rules defined in the 'attrs' file. -# attr_filter.post-proxy - - # - # If you are proxying LEAP, you MUST configure the EAP - # module, and you MUST list it here, in the post-proxy - # stage. - # - # You MUST also use the 'nostrip' option in the 'realm' - # configuration. Otherwise, the User-Name attribute - # in the proxied request will not match the user name - # hidden inside of the EAP packet, and the end server will - # reject the EAP request. - # - eap -} -} diff --git a/pkgs/fablab/freeradius-anon-access/raddb/sites-available/buffered-sql b/pkgs/fablab/freeradius-anon-access/raddb/sites-available/buffered-sql deleted file mode 100644 index 43d5b46..0000000 --- a/pkgs/fablab/freeradius-anon-access/raddb/sites-available/buffered-sql +++ /dev/null @@ -1,161 +0,0 @@ -# -*- text -*- -###################################################################### -# -# In 2.0.0, radrelay functionality is integrated into the -# server core. This virtual server gives an example of -# using radrelay functionality inside of the server. -# -# In this example, the detail file is read, and the data -# is put into SQL. This configuration is used when a RADIUS -# server on this machine is receiving accounting packets, -# and writing them to the detail file. -# -# The purpose of this virtual server is to de-couple the storage -# of long-term accounting data in SQL from "live" information -# needed by the RADIUS server as it is running. -# -# The benefit of this approach is that for a busy server, the -# overhead of performing SQL queries may be significant. Also, -# if the SQL databases are large (as is typical for ones storing -# months of data), the INSERTs and UPDATEs may take a relatively -# long time. Rather than slowing down the RADIUS server by -# having it interact with a database, you can just log the -# packets to a detail file, and then read that file later at a -# time when the RADIUS server is typically lightly loaded. -# -# If you use on virtual server to log to the detail file, -# and another virtual server (i.e. this one) to read from -# the detail file, then this process will happen automatically. -# A sudden spike of RADIUS traffic means that the detail file -# will grow in size, and the server will be able to handle -# large volumes of traffic quickly. When the traffic dies down, -# the server will have time to read the detail file, and insert -# the data into a long-term SQL database. -# -# $Id: 74574ac5a36d446b2a72dcae64d1c0a1992014c8 $ -# -###################################################################### - -server buffered-sql { - listen { - type = detail - - # The location where the detail file is located. - # This should be on local disk, and NOT on an NFS - # mounted location! - # - # On most systems, this should support file globbing - # e.g. "${radacctdir}/detail-*:*" - # This lets you write many smaller detail files as in - # the example in radiusd.conf: ".../detail-%Y%m%d:%H" - # Writing many small files is often better than writing - # one large file. File globbing also means that with - # a common naming scheme for detail files, then you can - # have many detail file writers, and only one reader. - # - filename = "${radacctdir}/detail-*" - - # - # The server can read accounting packets from the - # detail file much more quickly than those packets - # can be written to a database. If the database is - # overloaded, then bad things can happen. - # - # The server will keep track of how long it takes to - # process an entry from the detail file. It will - # then pause between handling entries. This pause - # allows databases to "catch up", and gives the - # server time to notice that other packets may have - # arrived. - # - # The pause is calculated dynamically, to ensure that - # the load due to reading the detail files is limited - # to a small percentage of CPU time. The - # "load_factor" configuration item is a number - # between 1 and 100. The server will try to keep the - # percentage of time taken by "detail" file entries - # to "load_factor" percentage of the CPU time. - # - # If the "load_factor" is set to 100, then the server - # will read packets as fast as it can, usually - # causing databases to go into overload. - # - load_factor = 10 - - # - # Set the interval for polling the detail file. - # If the detail file doesn't exist, the server will - # wake up, and poll for it every N seconds. - # - # Useful range of values: 1 to 60 - # - poll_interval = 1 - - # - # Set the retry interval for when the home server - # does not respond. The current packet will be - # sent repeatedly, at this interval, until the - # home server responds. - # - # Useful range of values: 5 to 30 - # - retry_interval = 30 - - # - # Track progress through the detail file. When the detail - # file is large, and the server is re-started, it will - # read from the START of the file. - # - # Setting "track = yes" means it will skip packets which - # have already been processed. The default is "no". - # - # track = yes - - # - # In some circumstances it may be desirable for the - # server to start up, process a detail file, and - # immediately quit. To do this enable the "one_shot" - # option below. - # - # Do not enable this for normal server operation. The - # default is "no". - # - # one_shot = no - } - - # - # Pre-accounting. Decide which accounting type to use. - # - preacct { - preprocess - - # - # Ensure that we have a semi-unique identifier for every - # request, and many NAS boxes are broken. - acct_unique - - # - # Read the 'acct_users' file. This isn't always - # necessary, and can be deleted if you do not use it. - files - } - - # - # Accounting. Log the accounting data. - # - accounting { - # - # Log traffic to an SQL database. - # - # See "Accounting queries" in mods-config/sql/main/$driver/queries.conf - # sql - - - # Cisco VoIP specific bulk accounting - # pgsql-voip - - } - - # The requests are not being proxied, so no pre/post-proxy - # sections are necessary. -} diff --git a/pkgs/fablab/freeradius-anon-access/raddb/sites-available/challenge b/pkgs/fablab/freeradius-anon-access/raddb/sites-available/challenge deleted file mode 100644 index 10dcbc4..0000000 --- a/pkgs/fablab/freeradius-anon-access/raddb/sites-available/challenge +++ /dev/null @@ -1,123 +0,0 @@ -# -# This file gives an example of using Challenge-Response -# -# In this example, the user logs in with a password, which has -# to be "hello". The server will send them a challenge -# consisting of a random number 0..9. The user has to respond -# with that number. -# -# -# $Id: c3aeb0865bbfc52be9690e396196b89a2e1ae761 $ -# -listen { - type = auth - ipaddr = * - port = 2000 - virtual_server = challenge -} - -server challenge { -authorize { - # - # OTP requires a password. - # - if (!User-Password) { - reject - } - - # - # If there's no State attribute, then this is the first - # request from the user. - # - if (!State) { - # - # Set the authentication to use step 1. - update control { - Auth-Type := Step1 - - # - # For testing we will just set the password to "hello". - # - # Normally the password comes from "ldap" or "sql". - # - Cleartext-Password := "hello" - -# ldap -# sql -# ... - } - } - else { - # - # Check that the password looks like an OTP - # - if (User-Password !~ /[0-9]{6}/) { - reject - } - - # - # Set the authentication to use step 2. - # Set the "known good" password to the number - # saved in the session-state list. - # - update control { - Auth-Type := Step2 - - # - # For testing, ensure that the user enters the same password. - # - # Normally this section should look up a TOTP-Secret, and - # - Cleartext-Password := &session-state:Tmp-Integer-0 - - # - # Normally this section should also set &control:TOTP-Secret, too. - # - TOTP-Password := &User-Password - } - } -} - -authenticate { - Auth-Type Step1 { - # If the password doesn't match, the user is rejected - # immediately. - pap - - # - # For testing, just use a 6 digit random OTP. - # - update session-state { - Tmp-Integer-0 := "%{randstr:nnnnnn}" - } - - # - # For testing, tell the user what OTP to enter. - # - # Don't do this in production... - # - update reply { - Reply-Message := "Please enter OTP %{session-state:Tmp-Integer-0}" - } - - # - # Send an Access-Challenge. - # See raddb/policy.d/control for the definition - # of "challenge" - # - challenge - } - - Auth-Type Step2 { - # - # For testing, do PAP authentication with the password. - # - pap - - # - # Normally you'd do TOTP checks via the TOTP module. - # -# totp - } -} -} diff --git a/pkgs/fablab/freeradius-anon-access/raddb/sites-available/channel_bindings b/pkgs/fablab/freeradius-anon-access/raddb/sites-available/channel_bindings deleted file mode 100644 index 449c69c..0000000 --- a/pkgs/fablab/freeradius-anon-access/raddb/sites-available/channel_bindings +++ /dev/null @@ -1,17 +0,0 @@ -# -# A virtual server which is used to validate channel-bindings. -# -# $Id: b9f0ac791511903e4be8794203d324446e7a949c $ -# -server channel_bindings { - # - # Only the "authorize" section is needed. - # - authorize { - # In general this section should include a policy for each type - # of channel binding that may be in use. For example each lower - # layer such as GSS-EAP (RFC 7055) or IEEE 802.11I is likely to - # need a separate channel binding policy. - abfab_channel_bindings - } -} diff --git a/pkgs/fablab/freeradius-anon-access/raddb/sites-available/check-eap-tls b/pkgs/fablab/freeradius-anon-access/raddb/sites-available/check-eap-tls deleted file mode 100644 index 69065e1..0000000 --- a/pkgs/fablab/freeradius-anon-access/raddb/sites-available/check-eap-tls +++ /dev/null @@ -1,135 +0,0 @@ -# This virtual server allows EAP-TLS to reject access requests -# based on some attributes of the certificates involved. -# -# To use this virtual server, you must enable it in the tls -# section of mods-enabled/eap as well as adding a link to this -# file in sites-enabled/. -# -# -# Value-pairs that are available for checking include: -# -# TLS-Client-Cert-Subject -# TLS-Client-Cert-Issuer -# TLS-Client-Cert-Common-Name -# TLS-Client-Cert-Subject-Alt-Name-Email -# -# To see a full list of attributes, run the server in debug mode -# with this virtual server configured, and look at the attributes -# passed in to this virtual server. -# -# -# This virtual server is also useful when using EAP-TLS as it is -# only called once, just before the final Accept is about to be -# returned from eap, whereas the outer authorize section is called -# multiple times for each challenge / response. For this reason, -# here may be a good location to put authentication logging, and -# modules that check for further authorization, especially if they -# hit external services such as sql or ldap. - - -server check-eap-tls { - - -# Authorize - this is the only section required. -# -# To accept the access request, set Auth-Type = Accept, otherwise -# set it to Reject. - -authorize { - - # - # By default, we just accept the request: - # - update config { - &Auth-Type := Accept - } - - - # - # Check the client certificate matches a string, and reject otherwise - # - -# if ("%{TLS-Client-Cert-Common-Name}" == 'client.example.com') { -# update config { -# &Auth-Type := Accept -# } -# } -# else { -# update config { -# &Auth-Type := Reject -# } -# update reply { -# &Reply-Message := "Your certificate is not valid." -# } -# } - - - # - # Check the client certificate common name against the supplied User-Name - # -# if (&User-Name == "host/%{TLS-Client-Cert-Common-Name}") { -# update config { -# &Auth-Type := Accept -# } -# } -# else { -# update config { -# &Auth-Type := Reject -# } -# } - - - # - # This is a convenient place to call LDAP, for example, when using - # EAP-TLS, as it will only be called once, after all certificates as - # part of the EAP-TLS challenge process have been verified. - # - # An example could be to use LDAP to check that the connecting host, as - # well as presenting a valid certificate, is also in a group based on - # the User-Name (assuming this contains the service principal name). - # Settings such as the following could be used in the ldap module - # configuration: - # - # basedn = "dc=example, dc=com" - # filter = "(servicePrincipalName=%{User-Name})" - # base_filter = "(objectClass=computer)" - # groupname_attribute = cn - # groupmembership_filter = "(&(objectClass=group)(member=%{control:Ldap-UserDn}))" - -# ldap - - # Now let's test membership of an LDAP group (the ldap bind user will - # need permission to read this group membership): - -# if (!(Ldap-Group == "Permitted-Laptops")) { -# update config { -# &Auth-Type := Reject -# } -# } - - # or, to be more specific, you could use the group's full DN: - # if (!(Ldap-Group == "CN=Permitted-Laptops,OU=Groups,DC=example,DC=org")) { - - - # - # This may be a better place to call the files modules when using - # EAP-TLS, as it will only be called once, after the challenge-response - # iteration has completed. - # - -# files - - - # - # Log all request attributes, plus TLS certificate details, to the - # auth_log file. Again, this is just once per connection request, so - # may be preferable than in the outer authorize section. It is - # suggested that 'auth_log' also be in the outer post-auth and - # Post-Auth REJECT sections to log reply packet details, too. - # - - auth_log - -} -} - diff --git a/pkgs/fablab/freeradius-anon-access/raddb/sites-available/coa b/pkgs/fablab/freeradius-anon-access/raddb/sites-available/coa deleted file mode 100644 index c10f88e..0000000 --- a/pkgs/fablab/freeradius-anon-access/raddb/sites-available/coa +++ /dev/null @@ -1,49 +0,0 @@ -# -*- text -*- -###################################################################### -# -# Sample virtual server for receiving a CoA or Disconnect-Request packet. -# - -# Listen on the CoA port. -# -# This uses the normal set of clients, with the same secret as for -# authentication and accounting. -# -listen { - type = coa - ipaddr = * - port = 3799 - virtual_server = coa -} - -server coa { - # When a packet is received, it is processed through the - # recv-coa section. This applies to *both* CoA-Request and - # Disconnect-Request packets. - recv-coa { - # CoA && Disconnect packets can be proxied in the same - # way as authentication or accounting packets. - # Just set Proxy-To-Realm, or Home-Server-Pool, and the - # packets will be proxied. - - # Do proxying based on realms here. You don't need - # "IPASS" or "ntdomain", as the proxying is based on - # the Operator-Name attribute. It contains the realm, - # and ONLY the realm (prefixed by a '1') - suffix - - # Insert your own policies here. - ok - } - - # When a packet is sent, it is processed through the - # send-coa section. This applies to *both* CoA-Request and - # Disconnect-Request packets. - send-coa { - # Sample module. - ok - } - - # You can use pre-proxy and post-proxy sections here, too. - # They will be processed for sending && receiving proxy packets. -} diff --git a/pkgs/fablab/freeradius-anon-access/raddb/sites-available/coa-relay b/pkgs/fablab/freeradius-anon-access/raddb/sites-available/coa-relay deleted file mode 100644 index 05fd6bc..0000000 --- a/pkgs/fablab/freeradius-anon-access/raddb/sites-available/coa-relay +++ /dev/null @@ -1,331 +0,0 @@ -# -*- text -*- -###################################################################### -# -# This virtual server simplifies the process of sending CoA-Request or -# Disconnect-Request packets to a NAS. -# -# This virtual server will receive CoA-Request or Disconnect-Request -# packets that contain *minimal* identifying information. e.g. Just -# a User-Name, or maybe just an Acct-Session-Id attribute. It will -# look up that information in a database in order to find the rest of -# the session data. e.g. NAS-IP-Address, NAS-Identifier, NAS-Port, -# etc. That information will be added to the packet, which will then -# be sent to the NAS. -# -# This process is useful because NASes require the CoA packets to -# contain "session identification" attributes in order to to do CoA -# or Disconnect. If the attributes aren't in the packet, then the -# NAS will NAK the request. This NAK happens even if you ask to -# disconnect "User-Name = bob", and there is only one session with a -# "bob" active. -# -# Using this virtual server makes the CoA or Disconnect process -# easier. Just tell FreeRADIUS to disconnect "User-Name = bob", and -# FreeRADIUS will take care of adding the "session identification" -# attributes. -# -# The process is as follows: -# -# - A CoA/Disconnect-Request is received by FreeRADIUS. -# - The radacct table is searched for active sessions that match each of -# the provided identifier attributes: User-Name, Acct-Session-Id. The -# search returns the owning NAS and Acct-Unique-Id for the matching -# session/s. -# - The original CoA/Disconnect-Request content is written to a detail file -# with custom attributes representing the NAS and Acct-Session-Id. -# - A detail reader follows the file and originates CoA/Disconenct-Requests -# containing the original content, relayed to the corresponding NAS for -# each session using the custom attributes. -# -# This simplifies scripting directly against a set of NAS devices since a -# script need only send a single CoA/Disconnect to FreeRADIUS which will -# then: -# -# - Lookup all active sessions belonging to a user, in the case that only a -# User-Name attribute is provided in the request -# - Handle routing of the request to the correct NAS, in the case of a -# multi-NAS setup -# -# For example, to disconnect a specific session: -# -# $ echo 'Acct-Session-Id = "769df3 312343"' | \ -# radclient 127.0.0.1 disconnect testing123 -# -# To perform a CoA update of all active sessions belonging to a user: -# -# $ cat <, -# -# 00:01:02:03:04:05,192.0.2.100 -# 01:01:02:03:04:05,192.0.2.101 -# 02:01:02:03:04:05,192.0.2.102 -# -# This lets you perform simple static IP assignment. -# -# There is a preconfigured "mac2ip" module setup in -# mods-available/mac2ip. To use it do: -# -# # cd raddb/ -# # ln -s ../mods-available/mac2ip mods-enabled/mac2ip -# # mkdir mods-config/passwd -# -# Then create the file mods-config/passwd/mac2ip with the above -# format. -# -###################################################################### - - -# This is an example only - see mods-available/mac2ip instead; do -# not uncomment these lines here. -# -#passwd mac2ip { -# filename = ${confdir}/mac2ip -# format = "*DHCP-Client-Hardware-Address:=DHCP-Your-IP-Address" -# delimiter = "," -#} diff --git a/pkgs/fablab/freeradius-anon-access/raddb/sites-available/dhcp.relay b/pkgs/fablab/freeradius-anon-access/raddb/sites-available/dhcp.relay deleted file mode 100644 index 76d1e10..0000000 --- a/pkgs/fablab/freeradius-anon-access/raddb/sites-available/dhcp.relay +++ /dev/null @@ -1,44 +0,0 @@ -# -*- text -*- -###################################################################### -# -# This is a virtual server that handles DHCP relaying -# -# Only one server can listen on a socket, so you cannot -# do DHCP relaying && run a DHCP server at the same time. -# -###################################################################### - -server dhcp.eth1 { - listen { - ipaddr = * - port = 67 - type = dhcp - interface = eth1 - } - - # Packets received on the socket will be processed through one - # of the following sections, named after the DHCP packet type. - # See dictionary.dhcp for the packet types. - dhcp DHCP-Discover { - update config { - # IP Address of the DHCP server - &DHCP-Relay-To-IP-Address := 192.0.2.2 - } - update request { - # IP Address of the DHCP relay (ourselves) - &DHCP-Gateway-IP-Address := 192.0.2.1 - } - ok - } - - dhcp DHCP-Request { - update config { - # IP Address of the DHCP server - &DHCP-Relay-To-IP-Address := 192.0.2.2 - } - update request { - &DHCP-Gateway-IP-Address := 192.0.2.2 - } - ok - } -} diff --git a/pkgs/fablab/freeradius-anon-access/raddb/sites-available/dynamic-clients b/pkgs/fablab/freeradius-anon-access/raddb/sites-available/dynamic-clients deleted file mode 100644 index b86ba4b..0000000 --- a/pkgs/fablab/freeradius-anon-access/raddb/sites-available/dynamic-clients +++ /dev/null @@ -1,222 +0,0 @@ -# -*- text -*- -###################################################################### -# -# Sample configuration file for dynamically updating the list -# of RADIUS clients at run time. -# -# Everything is keyed off of a client "network". (e.g. 192.0.2/24) -# This configuration lets the server know that clients within -# that network are defined dynamically. -# -# When the server receives a packet from an unknown IP address -# within that network, it tries to find a dynamic definition -# for that client. If the definition is found, the IP address -# (and other configuration) is added to the server's internal -# cache of "known clients", with a configurable lifetime. -# -# Further packets from that IP address result in the client -# definition being found in the cache. Once the lifetime is -# reached, the client definition is deleted, and any new requests -# from that client are looked up as above. -# -# If the dynamic definition is not found, then the request is -# treated as if it came from an unknown client. i.e. It is -# silently discarded. -# -# As part of protection from Denial of Service (DoS) attacks, -# the server will add only one new client per second. This CANNOT -# be changed, and is NOT configurable. -# -# $Id: 0459a7f4b1dc824b1684e9d220a0410c69b3248a $ -# -###################################################################### - -# -# Define a network where clients may be dynamically defined. -client dynamic { - # - # You MUST specify a netmask! - # IPv4 /32 or IPv6 /128 are NOT allowed! - ipaddr = 192.0.2.0/24 - - # - # Any other configuration normally found in a "client" - # entry can be used here. - - # - # A shared secret does NOT have to be defined. It can - # be left out. - - # - # Define the virtual server used to discover dynamic clients. - dynamic_clients = dynamic_clients - - # - # The directory where client definitions are stored. This - # needs to be used ONLY if the client definitions are stored - # in flat-text files. Each file in that directory should be - # ONE and only one client definition. The name of the file - # should be the IP address of the client. - # - # If you are storing clients in SQL, this entry should not - # be used. -# directory = ${confdir}/dynamic-clients/ - - # - # Define the lifetime (in seconds) for dynamic clients. - # They will be cached for this lifetime, and deleted afterwards. - # - # If the lifetime is "0", then the dynamic client is never - # deleted. The only way to delete the client is to re-start - # the server. - lifetime = 3600 -} - -# -# This is the virtual server referenced above by "dynamic_clients". -server dynamic_clients { - - # - # The only contents of the virtual server is the "authorize" section. - authorize { - - # - # Put any modules you want here. SQL, LDAP, "exec", - # Perl, etc. The only requirements is that the - # attributes MUST go into the control item list. - # - # The request that is processed through this section - # is EMPTY. There are NO attributes. The request is fake, - # and is NOT the packet that triggered the lookup of - # the dynamic client. - # - # The ONLY piece of useful information is either - # - # Packet-Src-IP-Address (IPv4 clients) - # Packet-Src-IPv6-Address (IPv6 clients) - # - # The attributes used to define a dynamic client mirror - # the configuration items in the "client" structure. - # - - # - # Example 1: Hard-code a client IP. This example is - # useless, but it documents the attributes - # you need. - # - update control { - - # - # Echo the IP address of the client. - &FreeRADIUS-Client-IP-Address = "%{Packet-Src-IP-Address}" - - # require_message_authenticator - &FreeRADIUS-Client-Require-MA = no - - # secret - &FreeRADIUS-Client-Secret = "testing123" - - # shortname - &FreeRADIUS-Client-Shortname = "%{Packet-Src-IP-Address}" - - # nas_type - &FreeRADIUS-Client-NAS-Type = "other" - - # virtual_server - # - # This can ONLY be used if the network client - # definition (e.g. "client dynamic" above) has - # NO virtual_server defined. - # - # If the network client definition does have a - # virtual_server defined, then that is used, - # and there is no need to define this attribute. - # - &FreeRADIUS-Client-Virtual-Server = "something" - - } - - # - # Example 2: Read the clients from "clients" files - # in a directory. - # - - # This requires you to uncomment the - # "directory" configuration in the - # "client dynamic" configuration above, - # and then put one file per IP address in - # that directory. - # - dynamic_clients - - # - # Example 3: Look the clients up in SQL. - # - # This requires the SQL module to be configured, of course. - if ("%{sql: SELECT nasname FROM nas WHERE nasname = '%{Packet-Src-IP-Address}'}") { - update control { - # - # Echo the IP. - &FreeRADIUS-Client-IP-Address = "%{Packet-Src-IP-Address}" - - # - # Do multiple SELECT statements to grab - # the various definitions. - &FreeRADIUS-Client-Shortname = "%{sql: SELECT shortname FROM nas WHERE nasname = '%{Packet-Src-IP-Address}'}" - - &FreeRADIUS-Client-Secret = "%{sql: SELECT secret FROM nas WHERE nasname = '%{Packet-Src-IP-Address}'}" - - &FreeRADIUS-Client-NAS-Type = "%{sql: SELECT type FROM nas WHERE nasname = '%{Packet-Src-IP-Address}'}" - - &FreeRADIUS-Client-Virtual-Server = "%{sql: SELECT server FROM nas WHERE nasname = '%{Packet-Src-IP-Address}'}" - } - - } - - # Do an LDAP lookup in the elements OU, check to see if - # the Packet-Src-IP-Address object has a "ou" - # attribute, if it does continue. Change "ACME.COM" to - # the real OU of your organization. - # - # Assuming the following schema: - # - # OU=Elements,OU=Radius,DC=ACME,DC=COM - # - # Elements will hold a record of every NAS in your - # Network. Create Group objects based on the IP - # Address of the NAS and set the "Location" or "l" - # attribute to the NAS Huntgroup the NAS belongs to - # allow them to be centrally managed in LDAP. - # - # e.g. CN=10.1.2.3,OU=Elements,OU=Radius,DC=ACME,DC=COM - # - # With a "l" value of "CiscoRTR" for a Cisco Router - # that has a NAS-IP-Address or Source-IP-Address of - # 10.1.2.3. - # - # And with a "ou" value of the shared secret password - # for the NAS element. ie "password" - if ("%{ldap:ldap:///OU=Elements,OU=Radius,DC=ACME,DC=COM?ou?sub?cn=%{Packet-Src-IP-Address}}") { - update control { - &FreeRADIUS-Client-IP-Address = "%{Packet-Src-IP-Address}" - - # Set the Client-Shortname to be the Location - # "l" just like in the Huntgroups, but this - # time to the shortname. - - &FreeRADIUS-Client-Shortname = "%{ldap:ldap:///OU=Elements,OU=Radius,DC=ACME,DC=COM?l?sub?cn=%{Packet-Src-IP-Address}}" - - # Lookup and set the Shared Secret based on - # the "ou" attribute. - &FreeRADIUS-Client-Secret = "%{ldap:ldap:///OU=Elements,OU=Radius,DC=ACME,DC=COM?ou?sub?cn=%{Packet-Src-IP-Address}}" - } - } - - # - # Tell the caller that the client was defined properly. - # - # If the authorize section does NOT return "ok", then - # the new client is ignored. - ok - } -} diff --git a/pkgs/fablab/freeradius-anon-access/raddb/sites-available/example b/pkgs/fablab/freeradius-anon-access/raddb/sites-available/example deleted file mode 100644 index fdc1c46..0000000 --- a/pkgs/fablab/freeradius-anon-access/raddb/sites-available/example +++ /dev/null @@ -1,122 +0,0 @@ -###################################################################### -# -# An example virtual server configuration. -# -# $Id: 5f204aaa6fc87e487b8542e1e4781623ff7f4a73 $ -# -###################################################################### - - -# -# This client will be available to any "listen" section that -# are defined outside of a virtual server section. However, -# when the server receives a packet from this client, the -# request will be processed through the "example" virtual -# server, as the "client" section contains a configuration item -# to that effect. -# -# Note that this client will be able to send requests to any -# port defined in a global "listen" section. It will NOT, -# however, be able to send requests to a port defined in a -# "listen" section that is contained in a "server" section. -# -# With careful matching of configurations, you should be able -# to: -# -# - Define one authentication port, but process each client -# through a separate virtual server. -# -# - define multiple authentication ports, each with a private -# list of clients. -# -# - define multiple authentication ports, each of which may -# have the same client listed, but with different shared -# secrets -# -# FYI: We use an address in the 192.0.2.* space for this example, -# as RFC 3330 says that that /24 range is used for documentation -# and examples, and should not appear on the net. You shouldn't -# use it for anything, either. -# -client 192.0.2.10 { - shortname = example-client - secret = testing123 - virtual_server = example -} - -###################################################################### -# -# An example virtual server. It starts off with "server name {" -# The "name" is used to reference this server from a "listen" -# or "client" section. -# -###################################################################### -server example { - # - # Listen on 192.0.2.1:1812 for Access-Requests - # - # When the server receives a packet, it is processed - # through the "authorize", etc. sections listed here, - # NOT the global ones the "default" site. - # - listen { - ipaddr = 192.0.2.1 - port = 1821 - type = auth - } - - # - # This client is listed within the "server" section, - # and is therefore known ONLY to the socket defined - # in the "listen" section above. If the client IP - # sends a request to a different socket, the server - # will treat it as an unknown client, and will not - # respond. - # - # In contrast, the client listed at the top of this file - # is outside of any "server" section, and is therefore - # global in scope. It can send packets to any port - # defined in a global "listen" section. It CANNOT send - # packets to the listen section defined above, though. - # - # Note that you don't have to have a "virtual_server = example" - # line here, as the client is encapsulated within - # the "server" section. - # - client 192.0.2.9 { - shortname = example-client - secret = testing123 - } - - authorize { - # - # Some example policies. See "man unlang" for more. - # - if (&User-Name == 'bob') { - update control { - &Cleartext-Password := 'bob' - } - } - - # - # And then reject the user. The next line requires - # that the "always reject {}" section is defined in - # the "modules" section of radiusd.conf. - # - reject - } - - authenticate { - - } - - post-auth { - - Post-Auth-Type Reject { - update reply { - &Reply-Message = 'This is only an example.' - } - } - } - -} diff --git a/pkgs/fablab/freeradius-anon-access/raddb/sites-available/originate-coa b/pkgs/fablab/freeradius-anon-access/raddb/sites-available/originate-coa deleted file mode 100644 index 3325b88..0000000 --- a/pkgs/fablab/freeradius-anon-access/raddb/sites-available/originate-coa +++ /dev/null @@ -1,185 +0,0 @@ -# -*- text -*- -###################################################################### -# -# The server can originate Change of Authorization (CoA) or -# Disconnect request packets. These packets are used to dynamically -# change the parameters of a users session (bandwidth, etc.), or -# to forcibly disconnect the user. -# -# There are some caveats. Not all NAS vendors support this -# functionality. Even for the ones that do, it may be difficult to -# find out what needs to go into a CoA-Request or Disconnect-Request -# packet. All we can suggest is to read the NAS documentation -# available from the vendor. That documentation SHOULD describe -# what information their equipment needs to see in a CoA packet. -# -# This information is usually a list of attributes such as: -# -# NAS-IP-Address (or NAS-IPv6 address) -# NAS-Identifier -# User-Name -# Acct-Session-Id -# -# CoA packets can be originated when a normal Access-Request or -# Accounting-Request packet is received. Simply update the -# "coa" list: -# -# update coa { -# &User-Name = "%{User-Name}" -# &Acct-Session-Id = "%{Acct-Session-Id}" -# &NAS-IP-Address = "%{NAS-IP-Address}" -# } -# -# And the CoA packet will be sent. You can also send Disconnect -# packets by using "update disconnect { ...". -# -# This "update coa" entry can be placed in any section (authorize, -# preacct, etc.), EXCEPT for pre-proxy and post-proxy. The CoA -# packets CANNOT be sent if the original request has been proxied. -# -# The CoA functionality works best when the RADIUS server and -# the NAS receiving CoA packets are on the same network. -# -# If "update coa { ... " is used, and then later it becomes necessary -# to not send a CoA request, the following example can suppress the -# CoA packet: -# -# update control { -# &Send-CoA-Request = No -# } -# -# The default destination of a CoA packet is the NAS (or client) -# the sent the original Access-Request or Accounting-Request. See -# raddb/clients.conf for a "coa_server" configuration that ties -# a client to a specific home server, or to a home server pool. -# -# If you need to send the packet to a different destination, update -# the "coa" list with one of: -# -# Packet-Dst-IP-Address = ... -# Packet-Dst-IPv6-Address = ... -# Home-Server-Pool = ... -# -# That specifies an Ipv4 or IPv6 address, or a home server pool -# (such as the "coa" pool example below). This use is not -# recommended, however, It is much better to point the client -# configuration directly at the CoA server/pool, as outlined -# earlier. -# -# If the CoA port is non-standard, you can also set: -# -# Packet-Dst-Port -# -# to have the value of the port. -# -###################################################################### - -# -# When CoA packets are sent to a NAS, the NAS is acting as a -# server (see RFC 5176). i.e. it has a type (accepts CoA and/or -# Disconnect packets), an IP address (or IPv6 address), a -# destination port, and a shared secret. -# -home_server example-coa { - type = coa - - # - # Note that a home server of type "coa" MUST be a real NAS, - # with an ipaddr or ipv6addr. It CANNOT point to a virtual - # server. - # - # Change this IP address to the IP address of the NAS. - # - ipaddr = 192.0.2.42 - port = 3799 - - # This secret SHOULD NOT be the same as the shared - # secret in a "client" section. - secret = testing1234 - - # CoA specific parameters. See raddb/proxy.conf for details. - coa { - irt = 2 - mrt = 16 - mrc = 5 - mrd = 30 - } -} - -# -# CoA servers can be put into pools, just like normal servers. -# -home_server_pool coa { - type = fail-over - - # Point to the CoA server above. - home_server = example-coa - - # CoA requests are run through the pre-proxy section. - # CoA responses are run through the post-proxy section. - virtual_server = originate-coa.example.com - - # - # Home server pools of type "coa" cannot (currently) have - # a "fallback" configuration. - # -} - -# -# When this virtual server is run, the original request has FINISHED -# processing. i.e. the reply has already been sent to the NAS. -# You can access the attributes in the original packet, reply, and -# control items, but changing them will have NO EFFECT. -# -# The CoA packet is in the "proxy-request" attribute list. -# The CoA reply (if any) is in the "proxy-reply" attribute list. -# -server originate-coa.example.com { - pre-proxy { - update proxy-request { - NAS-IP-Address = 192.0.2.42 - } - } - - # - # Handle the responses here. - # - post-proxy { - switch &proxy-reply:Packet-Type { - case CoA-ACK { - ok - } - - case CoA-NAK { - # the NAS didn't like the CoA request - ok - } - - case Disconnect-ACK { - ok - } - - case Disconnect-NAK { - # the NAS didn't like the Disconnect request - ok - } - - # Invalid packet type. This shouldn't happen. - case { - fail - } - } - - # - # These methods are run when there is NO response - # to the request. - # - Post-Proxy-Type Fail-CoA { - ok - } - - Post-Proxy-Type Fail-Disconnect { - ok - } - } -} diff --git a/pkgs/fablab/freeradius-anon-access/raddb/sites-available/proxy-inner-tunnel b/pkgs/fablab/freeradius-anon-access/raddb/sites-available/proxy-inner-tunnel deleted file mode 100644 index f77f9cb..0000000 --- a/pkgs/fablab/freeradius-anon-access/raddb/sites-available/proxy-inner-tunnel +++ /dev/null @@ -1,47 +0,0 @@ -# -*- text -*- -###################################################################### -# -# This is a virtual server that handles *only* inner tunnel -# requests for EAP-TTLS and PEAP types. -# -# $Id: 938d954592d3824e4d51e3315d0f7e0b5cfde824 $ -# -###################################################################### - -server proxy-inner-tunnel { - -# -# This example is very simple. All inner tunnel requests get -# proxied to another RADIUS server. -# -authorize { - # - # Do other things here, as necessary. - # - # e.g. run the "realms" module, to decide how to proxy - # the inner tunnel request. - # - - update control { - # You should update this to be one of your realms. - &Proxy-To-Realm := "example.com" - } -} - -authenticate { - # - # This is necessary so that the inner tunnel EAP-MSCHAPv2 - # method can be called. That method takes care of turning - # EAP-MSCHAPv2 into plain MS-CHAPv2, if necessary. - eap -} - -post-proxy { - # - # This is necessary for LEAP, or if you set: - # - # proxy_tunneled_request_as_eap = no - # - eap -} -} diff --git a/pkgs/fablab/freeradius-anon-access/raddb/sites-available/resource-check b/pkgs/fablab/freeradius-anon-access/raddb/sites-available/resource-check deleted file mode 100644 index 486c3b8..0000000 --- a/pkgs/fablab/freeradius-anon-access/raddb/sites-available/resource-check +++ /dev/null @@ -1,140 +0,0 @@ -# -*- text -*- -###################################################################### -# -# This virtual server provides an example of how to dynamically amend the -# control flow within some virtual server's policy on the basis of the status -# of some resource, such as an external database. -# -# This resource-check virtual server receives periodic dummy server-status -# requests that trigger an arbitrary set of checks. On the basis of those -# checks the status of an instance of the rlm_always module, that we refer to -# as the "control module", is updated to reflect the system status. -# -# Elsewhere, some other virtual server (the "controlled virtual server") uses -# the control module to make decisions during the processing of incoming -# requests. By amending the status of the control module in response to the -# system status this virtual server is able to manipulate the outcome of the -# controlled virtual server. -# -# Firstly, the authorize section of this virtual server will need to be -# amended to check the status of the external resources and to set the status -# of the control module appropriately, as described in the inline comments -# below... -# -# In addition to configuring and activating this virtual server, a control -# module must be configured as an instance of rlm_always in mods-enabled, for -# example: -# -# always db_online { -# # Default to online -# rcode = ok -# } -# -# Now trigger the resource checks by sending a server-status request to this -# virtual server, as follows: -# -# echo "Message-Authenticator = 0x00" | \ -# radclient -r 1 -t 3 -q 127.0.0.1:18122 status testing123 -# -# The trigger could be invoked by a cron job or if more frequent checks than -# once per minute are required a systemd timer might be used. -# -# The current status of the control module can be examined at any time using -# radmin: -# -# radmin -e 'show module status db_online' -# -# For radmin to work requires that the control-socket virtual server is -# configured and enabled. -# -# The controlled virtual server will contain some control flow decision that -# uses the control module, for example: -# -# server default { -# -# ... -# -# authorize { -# -# # If the database is not healthy then remain silent to trigger -# # NAS failover -# # -# db_online { -# fail = 1 -# } -# if (fail) { -# do_not_respond -# } -# -# sql -# -# pap -# } -# -# ... -# -# -# The configuration for this virtual server follows and should be amended as -# required... -# - - -# -# Listen on a local port for Server-Status requests that trigger the resource -# checks. -# -# This uses the normal set of clients, with the same secret as for -# authentication and accounting. -# -listen { - type = status - ipaddr = 127.0.0.1 - port = 18122 - virtual_server = resource_check -} - - -# -# Within this virual server we provide only an Autz-Type Status-Server section -# whose task is to perform the resource checks and sets the status of the -# "control module" -# -server resource-check { - -authorize { - -Autz-Type Status-Server { - - # - # In this example we check whether a PostgreSQL database is in - # recovery (or inaccessible) and when this is the case we fail the - # db_online control module. - # - # Other modules could be used here. - # - # You can even invoke synchronous checks using the %{exec:...} xlat in - # which case timeout should be set to less than the check trigger - # interval to avoid buildup of checks when resources do not respond. - # See rlm_exec for details. - # - if ("%{sql:SELECT pg_is_in_recovery()}" != "f") { - - # Fail the db_online module, if it isn't already - if ("%{db_online:}" != "fail") { - %{db_online:fail} - } - - } else { - - # Set the db_online module status to alive, if it isn't already - if ("%{db_online:}" != "alive") { - %{db_online:alive} - } - - } - -} - -} - -} diff --git a/pkgs/fablab/freeradius-anon-access/raddb/sites-available/robust-proxy-accounting b/pkgs/fablab/freeradius-anon-access/raddb/sites-available/robust-proxy-accounting deleted file mode 100644 index b0a3ca9..0000000 --- a/pkgs/fablab/freeradius-anon-access/raddb/sites-available/robust-proxy-accounting +++ /dev/null @@ -1,167 +0,0 @@ -# -*- text -*- -###################################################################### -# -# This is a sample configuration for robust proxy accounting. -# accounting packets are proxied, OR logged locally if all -# home servers are down. When the home servers come back up, -# the accounting packets are forwarded. -# -# This method enables the server to proxy all packets to the -# home servers when they're up, AND to avoid writing to the -# detail file in most situations. -# -# In most situations, proxying of accounting messages is done -# in a "pass-through" fashion. If the home server does not -# respond, then the proxy server does not respond to the NAS. -# That means that the NAS must retransmit packets, sometimes -# forever. This example shows how the proxy server can still -# respond to the NAS, even if all home servers are down. -# -# This configuration could be done MUCH more simply if ALL -# packets were written to the detail file. But that would -# involve a lot more disk writes, which may not be a good idea. -# -# This file is NOT meant to be used as-is. It needs to be -# edited to match your local configuration. -# -# Please see the sites-available/default file, in the -# "Post-Proxy-Type Fail-Accounting" section. That should be -# configured to write packets to the "detail.example.com" -# file when proxying fails. The "listen" section below will -# then read packets from that file, and proxy them. -# -# See also mods-available/detail.example.com, which is the -# module that writes the "detail.example.com" file. -# -# -# $Id: 85f2f9dcc06ed2cc2c14d371c7cfc5a086b4c6cf $ -# -###################################################################### - -# (1) Define two home servers. -home_server home1.example.com { - type = acct - ipaddr = 192.0.2.10 - port = 1813 - secret = testing123 - - # Mark this home server alive ONLY when it starts being responsive - status_check = request - username = "test_user_status_check" - - # Set the response timeout aggressively low. - # You MAY have to increase this, depending on tests with - # your local installation. - response_window = 6 -} - -home_server home2.example.com { - type = acct - ipaddr = 192.0.2.20 - port = 1813 - secret = testing123 - - # Mark this home server alive ONLY when it starts being responsive - status_check = request - username = "test_user_status_check" - - # Set the response timeout aggressively low. - # You MAY have to increase this, depending on tests with - # your local installation. - response_window = 6 -} - -# (2) Put all of the servers into a pool. -home_server_pool acct_pool.example.com { - type = load-balance # other types are OK, too. - - home_server = home1.example.com - home_server = home2.example.com - # add more home_server's here. - - # for pre/post-proxy policies - virtual_server = home.example.com -} - -# (3) Define a realm for these home servers. -# It should NOT be used as part of normal proxying decisions! -realm acct_realm.example.com { - acct_pool = acct_pool.example.com -} - -# (4) Define a detail file writer. -# See raddb/modules/detail.example.com - -# (5) Define a virtual server to handle pre/post-proxy re-writing -server home.example.com { - pre-proxy { - # Insert pre-proxy rules here - } - - post-proxy { - # Insert post-proxy rules here - - # This will be called when the CURRENT packet failed - # to be proxied. This may happen when one home server - # suddenly goes down, even though another home server - # may be alive. - # - # i.e. the current request has run out of time, so it - # cannot fail over to another (possibly) alive server. - # - # We want to respond to the NAS, so that it can stop - # re-sending the packet. We write the packet to the - # "detail" file, where it will be read, and sent to - # another home server. - # - Post-Proxy-Type Fail-Accounting { - detail.example.com - } - - # - # This section is run when there are problems - # proxying Access-Request packets - # - Post-Proxy-Type Fail-Authentication { - # add policies here - } - - } - - - # Read accounting packets from the detail file(s) for - # the home server. - # - # Note that you can have only ONE "listen" section reading - # detail files from a particular directory. That is why the - # destination host name is used as part of the directory name - # below. Having two "listen" sections reading detail files - # from the same directory WILL cause problems. The packets - # may be read by one, the other, or both "listen" sections. - listen { - type = detail - filename = "${radacctdir}/detail.example.com/detail-*:*" - load_factor = 10 - } - - # All packets read from the detail file are proxied back to - # the home servers. - # - # The normal pre/post-proxy rules are applied to them, too. - # - # If the home servers are STILL down, then the server stops - # reading the detail file, and queues the packets for a later - # retransmission. The Post-Proxy-Type "Fail" handler is NOT - # called. - # - # When the home servers come back up, the packets are forwarded, - # and the detail file processed as normal. - accounting { - # You may want accounting policies here... - - update control { - &Proxy-To-Realm := 'acct_realm.example.com' - } - } - -} diff --git a/pkgs/fablab/freeradius-anon-access/raddb/sites-available/soh b/pkgs/fablab/freeradius-anon-access/raddb/sites-available/soh deleted file mode 100644 index 86748b6..0000000 --- a/pkgs/fablab/freeradius-anon-access/raddb/sites-available/soh +++ /dev/null @@ -1,34 +0,0 @@ -# This is a simple server for the MS SoH requests generated by the -# peap module - see "eap.conf" for more info - -# Requests are ONLY passed through the authorize section, and cannot -# current be proxied (in any event, the radius attributes used are -# internal). - -server soh-server { - authorize { - if (&SoH-Supported == no) { - # client NAKed our request for SoH - not supported, or turned off - update config { - &Auth-Type = Accept - } - } - else { - # client replied; check something - this is a local policy issue! - if (&SoH-MS-Windows-Health-Status =~ /antivirus (warn|error) /) { - update config { - &Auth-Type = Reject - } - update reply { - &Reply-Message = 'You must have antivirus enabled & installed!' - } - } - else { - update config { - &Auth-Type = Accept - } - } - } - } -} - diff --git a/pkgs/fablab/freeradius-anon-access/raddb/sites-available/status b/pkgs/fablab/freeradius-anon-access/raddb/sites-available/status deleted file mode 100644 index 5432203..0000000 --- a/pkgs/fablab/freeradius-anon-access/raddb/sites-available/status +++ /dev/null @@ -1,127 +0,0 @@ -# -*- text -*- -###################################################################### -# -# A virtual server to handle ONLY Status-Server packets. -# -# Server statistics can be queried with a properly formatted -# Status-Server request. See dictionary.freeradius for comments. -# -# If radiusd.conf has "status_server = yes", then any client -# will be able to send a Status-Server packet to any port -# (listen section type "auth", "acct", or "status"), and the -# server will respond. -# -# If radiusd.conf has "status_server = no", then the server will -# ignore Status-Server packets to "auth" and "acct" ports. It -# will respond only if the Status-Server packet is sent to a -# "status" port. -# -# The server statistics are available ONLY on socket of type -# "status". Queries for statistics sent to any other port -# are ignored. -# -# Similarly, a socket of type "status" will not process -# authentication or accounting packets. This is for security. -# -# $Id: e7d4346310b837d56bffe4c991b4e5680742ebc0 $ -# -###################################################################### - -server status { - listen { - # ONLY Status-Server is allowed to this port. - # ALL other packets are ignored. - type = status - - ipaddr = 127.0.0.1 - port = 18121 - } - - # - # We recommend that you list ONLY management clients here. - # i.e. NOT your NASes or Access Points, and for an ISP, - # DEFINITELY not any RADIUS servers that are proxying packets - # to you. - # - # If you do NOT list a client here, then any client that is - # globally defined (i.e. all of them) will be able to query - # these statistics. - # - # Do you really want your partners seeing the internal details - # of what your RADIUS server is doing? - # - client admin { - ipaddr = 127.0.0.1 - secret = adminsecret - } - - # - # Simple authorize section. The "Autz-Type Status-Server" - # section will work here, too. See "raddb/sites-available/default". - authorize { - ok - - # respond to the Status-Server request. - Autz-Type Status-Server { - ok - } - } -} - -# Statistics can be queried via a number of methods: -# -# All packets received/sent by the server (1 = auth, 2 = acct) -# FreeRADIUS-Statistics-Type = 3 -# -# All packets proxied by the server (4 = proxy-auth, 8 = proxy-acct) -# FreeRADIUS-Statistics-Type = 12 -# -# All packets sent && received: -# FreeRADIUS-Statistics-Type = 15 -# -# Internal server statistics: -# FreeRADIUS-Statistics-Type = 16 -# -# All packets for a particular client (globally defined) -# FreeRADIUS-Statistics-Type = 35 -# FreeRADIUS-Stats-Client-IP-Address = 192.0.2.1 -# -# All packets for a client attached to a "listen" ip/port -# FreeRADIUS-Statistics-Type = 35 -# FreeRADIUS-Stats-Client-IP-Address = 192.0.2.1 -# FreeRADIUS-Stats-Server-IP-Address = 127.0.0.1 -# FreeRADIUS-Stats-Server-Port = 1812 -# -# All packets for a "listen" IP/port -# FreeRADIUS-Statistics-Type = 67 -# FreeRADIUS-Stats-Server-IP-Address = 127.0.0.1 -# FreeRADIUS-Stats-Server-Port = 1812 -# -# All packets for a home server IP / port -# FreeRADIUS-Statistics-Type = 131 -# FreeRADIUS-Stats-Server-IP-Address = 192.0.2.2 -# FreeRADIUS-Stats-Server-Port = 1812 - -# -# You can also get exponentially weighted moving averages of -# response times (in usec) of home servers. Just set the config -# item "historic_average_window" in a home_server section. -# -# By default it is zero (don't calculate it). Useful values -# are between 100, and 10,000. The server will calculate and -# remember the moving average for this window, and for 10 times -# that window. -# - -# -# Some of this could have been simplified. e.g. the proxy-auth and -# proxy-acct bits aren't completely necessary. But using them permits -# the server to be queried for ALL inbound && outbound packets at once. -# This gives a good snapshot of what the server is doing. -# -# Due to internal limitations, the statistics might not be exactly up -# to date. Do not expect all of the numbers to add up perfectly. -# The Status-Server packets are also counted in the total requests && -# responses. The responses are counted only AFTER the response has -# been sent. -# diff --git a/pkgs/fablab/freeradius-anon-access/raddb/sites-available/tls b/pkgs/fablab/freeradius-anon-access/raddb/sites-available/tls deleted file mode 100644 index d52c785..0000000 --- a/pkgs/fablab/freeradius-anon-access/raddb/sites-available/tls +++ /dev/null @@ -1,651 +0,0 @@ -###################################################################### -# -# RADIUS over TLS (radsec) -# -# When a new client connects, the various TLS parameters for the -# connection are available as dynamic expansions, e.g. -# -# %{listen:TLS-Client-Cert-Common-Name} -# -# Along with other TLS-Client-Cert-... attributes. -# These expansions will only exist if the relevant fields -# are in the client certificate. Read the debug output to see -# which fields are available. Look for output like the following: -# -# (0) TLS - Creating attributes from certificate OIDs -# (0) TLS-Client-Cert-Subject-Alt-Name-Dns := "one.example.org" -# (0) TLS-Client-Cert-Subject-Alt-Name-Dns := "two.example.org" -# ... -# -# It is also possible to distinguish between connections which have -# TLS enables, and ones which do not. The expansion: -# -# %{listen:tls} -# -# Will return "yes" if the connection has TLS enabled. It will -# return "no" if TLS is not enabled for a particular listen section. -# -# A number of TLS-Client-Cert-.. attributes holds X509v3 extensions -# data, attributes named the way OpenSSL names them. It is possible -# to extract data for an extension not known to OpenSSL by defining -# a custom string attribute which contains extension OID in it's -# name after 'TLS-Client-Cert-' prefix. E.g.: -# -# ATTRIBUTE TLS-Client-Cert-1.3.6.1.4.1.311.21.7 3002 string -# -# which will yield something simmilar to: -# -# (0) eap_tls: TLS - Creating attributes from certificate OIDs -# (0) eap_tls: TLS-Client-Cert-1.3.6.1.4.1.311.21.7 += "0x302e06" -# ... -# -###################################################################### - -listen { - ipaddr = * - port = 2083 - - # - # TCP and TLS sockets can accept Access-Request and - # Accounting-Request on the same socket. - # - # auth = only Access-Request - # acct = only Accounting-Request - # auth+acct = both - # coa = only CoA / Disconnect requests - # - type = auth+acct - - # For now, only TCP transport is allowed. - proto = tcp - - # Send packets to the default virtual server - virtual_server = default - - clients = radsec - - # - # Use the haproxy "PROXY protocol". - # - # This configuration allows for many FreeRADIUS servers to be - # behind a haproxy server. The "PROXY protocol" allows - # haproxy to send the actual client IP to FreeRADIUS. - # - # This will work ONLY for RadSec (TLS). Both the haproxy AND - # the RadSec client MUST be listed as allowed RADIUS clients. - # - # haproxy needs to have "send-proxy" configured for this server. - # Health checks should be turned off, as haproxy does not - # support RADIUS health checks. - # - # The main use of this feature is for scalability. There is no - # longer any need to have a RADIUS proxy as a load balancer. - # haproxy is fast, stable, and supports dynamic reloads! - # - # The only problem is that many RADIUS clients do not support - # RadSec. That situation will hopefully change over time. - # -# proxy_protocol = no - - # - # When this is set to "yes", new TLS connections - # are processed through a section called - # - # Autz-Type New-TLS-Connection { - # ... - # } - # - # The request contains TLS client certificate attributes, - # and nothing else. The debug output will print which - # attributes are available on your system. - # - # If the section returns "ok" or "updated", then the - # connection is accepted. Otherwise the connection is - # terminated. - # -# check_client_connections = yes - - # - # Connection limiting for sockets with "proto = tcp". - # - limit { - # - # Limit the number of simultaneous TCP connections to the socket - # - # The default is 16. - # Setting this to 0 means "no limit" - max_connections = 16 - - # The per-socket "max_requests" option does not exist. - - # - # The lifetime, in seconds, of a TCP connection. After - # this lifetime, the connection will be closed. - # - # Setting this to 0 means "forever". - lifetime = 0 - - # - # The idle timeout, in seconds, of a TCP connection. - # If no packets have been received over the connection for - # this time, the connection will be closed. - # - # Setting this to 0 means "no timeout". - # - # We STRONGLY RECOMMEND that you set an idle timeout. - # - idle_timeout = 30 - } - - # This is *exactly* the same configuration as used by the EAP-TLS - # module. It's OK for testing, but for production use it's a good - # idea to use different server certificates for EAP and for RADIUS - # transport. - # - # If you want only one TLS configuration for multiple sockets, - # then we suggest putting "tls { ...}" into radiusd.conf. - # The subsection below can then be changed into a reference: - # - # tls = ${tls} - # - # Which means "the tls sub-section is not here, but instead is in - # the top-level section called 'tls'". - # - # If you have multiple tls configurations, you can put them into - # sub-sections of a top-level "tls" section. There's no need to - # call them all "tls". You can then use: - # - # tls = ${tls.site1} - # - # to refer to the "site1" sub-section of the "tls" section. - # - tls { - private_key_password = whatever - private_key_file = ${certdir}/server.pem - - # Accept an expired Certificate Revocation List - # - # allow_expired_crl = no - - # If Private key & Certificate are located in - # the same file, then private_key_file & - # certificate_file must contain the same file - # name. - # - # If ca_file (below) is not used, then the - # certificate_file below MUST include not - # only the server certificate, but ALSO all - # of the CA certificates used to sign the - # server certificate. - certificate_file = ${certdir}/server.pem - - # Trusted Root CA list - # - # ALL of the CA's in this list will be trusted - # to issue client certificates for authentication. - # - # In general, you should use self-signed - # certificates for 802.1x (EAP) authentication. - # In that case, this CA file should contain - # *one* CA certificate. - # - # This parameter is used only for EAP-TLS, - # when you issue client certificates. If you do - # not use client certificates, and you do not want - # to permit EAP-TLS authentication, then delete - # this configuration item. - ca_file = ${cadir}/ca.pem - - # - # For DH cipher suites to work, you have to - # run OpenSSL to create the DH file first: - # - # openssl dhparam -out certs/dh 1024 - # - dh_file = ${certdir}/dh - - # - # If your system doesn't have /dev/urandom, - # you will need to create this file, and - # periodically change its contents. - # - # For security reasons, FreeRADIUS doesn't - # write to files in its configuration - # directory. - # -# random_file = /dev/urandom - - # - # The default fragment size is 1K. - # However, it's possible to send much more data than - # that over a TCP connection. The upper limit is 64K. - # Setting the fragment size to more than 1K means that - # there are fewer round trips when setting up a TLS - # connection. But only if the certificates are large. - # - fragment_size = 8192 - - # include_length is a flag which is - # by default set to yes If set to - # yes, Total Length of the message is - # included in EVERY packet we send. - # If set to no, Total Length of the - # message is included ONLY in the - # First packet of a fragment series. - # - # include_length = yes - - # Check the Certificate Revocation List - # - # 1) Copy CA certificates and CRLs to same directory. - # 2) Execute 'c_rehash '. - # 'c_rehash' is OpenSSL's command. - # 3) uncomment the line below. - # 5) Restart radiusd - # check_crl = yes - ca_path = ${cadir} - - # OpenSSL does not reload contents of ca_path dir over time. - # That means that if check_crl is enabled and CRLs are loaded - # from ca_path dir, at some point CRLs will expire and - # RADIUSd will stop authenticating NASes. - # If ca_path_reload_interval is non-zero, it will force OpenSSL - # to reload all data from ca_path periodically - # - # Flush ca_path each hour - ca_path_reload_interval = 3600 - - # - # If check_cert_issuer is set, the value will - # be checked against the DN of the issuer in - # the client certificate. If the values do not - # match, the certificate verification will fail, - # rejecting the user. - # - # This check can be done more generally by checking - # the value of the TLS-Client-Cert-Issuer attribute. - # This check can be done via any mechanism you choose. - # - # check_cert_issuer = "/C=GB/ST=Berkshire/L=Newbury/O=My Company Ltd" - - # - # If check_cert_cn is set, the value will - # be xlat'ed and checked against the CN - # in the client certificate. If the values - # do not match, the certificate verification - # will fail rejecting the user. - # - # This check is done only if the previous - # "check_cert_issuer" is not set, or if - # the check succeeds. - # - # In 2.1.10 and later, this check can be done - # more generally by checking the value of the - # TLS-Client-Cert-Common-Name attribute. This check - # can be done via any mechanism you choose. - # - # check_cert_cn = %{User-Name} - # - # Set this option to specify the allowed - # TLS cipher suites. The format is listed - # in "man 1 ciphers". - cipher_list = "DEFAULT" - - # If enabled, OpenSSL will use server cipher list - # (possibly defined by cipher_list option above) - # for choosing right cipher suite rather than - # using client-specified list which is OpenSSl default - # behavior. Having it set to yes is a current best practice - # for TLS - cipher_server_preference = no - - # - # Older TLS versions are deprecated. But for RadSec, - # we CAN allow TLS 1.3. - # - tls_min_version = "1.2" - tls_max_version = "1.3" - - # - # Session resumption / fast reauthentication - # cache. - # - # The cache contains the following information: - # - # session Id - unique identifier, managed by SSL - # User-Name - from the Access-Accept - # Stripped-User-Name - from the Access-Request - # Cached-Session-Policy - from the Access-Accept - # - # The "Cached-Session-Policy" is the name of a - # policy which should be applied to the cached - # session. This policy can be used to assign - # VLANs, IP addresses, etc. It serves as a useful - # way to re-apply the policy from the original - # Access-Accept to the subsequent Access-Accept - # for the cached session. - # - # On session resumption, these attributes are - # copied from the cache, and placed into the - # reply list. - # - # You probably also want "use_tunneled_reply = yes" - # when using fast session resumption. - # - cache { - # - # Enable it. The default is "no". - # Deleting the entire "cache" subsection - # Also disables caching. - # - # - # As of version 3.0.14, the session cache requires the use - # of the "name" and "persist_dir" configuration items, below. - # - # The internal OpenSSL session cache has been permanently - # disabled. - # - # You can disallow resumption for a - # particular user by adding the following - # attribute to the control item list: - # - # Allow-Session-Resumption = No - # - # If "enable = no" below, you CANNOT - # enable resumption for just one user - # by setting the above attribute to "yes". - # - enable = no - - # - # Lifetime of the cached entries, in hours. - # The sessions will be deleted after this - # time. - # - lifetime = 24 # hours - - # - # Internal "name" of the session cache. - # Used to distinguish which TLS context - # sessions belong to. - # - # The server will generate a random value - # if unset. This will change across server - # restart so you MUST set the "name" if you - # want to persist sessions (see below). - # - # If you use IPv6, change the "ipaddr" below - # to "ipv6addr" - # - #name = "TLS ${..ipaddr} ${..port} ${..proto}" - - # - # Simple directory-based storage of sessions. - # Two files per session will be written, the SSL - # state and the cached VPs. This will persist session - # across server restarts. - # - # The server will need write perms, and the directory - # should be secured from anyone else. You might want - # a script to remove old files from here periodically: - # - # find ${logdir}/tlscache -mtime +2 -exec rm -f {} \; - # - # This feature REQUIRES "name" option be set above. - # - #persist_dir = "${logdir}/tlscache" - } - - # - # Require a client certificate. - # - require_client_cert = yes - - # - # As of version 2.1.10, client certificates can be - # validated via an external command. This allows - # dynamic CRLs or OCSP to be used. - # - # This configuration is commented out in the - # default configuration. Uncomment it, and configure - # the correct paths below to enable it. - # - verify { - # A temporary directory where the client - # certificates are stored. This directory - # MUST be owned by the UID of the server, - # and MUST not be accessible by any other - # users. When the server starts, it will do - # "chmod go-rwx" on the directory, for - # security reasons. The directory MUST - # exist when the server starts. - # - # You should also delete all of the files - # in the directory when the server starts. - # tmpdir = /tmp/radiusd - - # The command used to verify the client cert. - # We recommend using the OpenSSL command-line - # tool. - # - # The ${..ca_path} text is a reference to - # the ca_path variable defined above. - # - # The %{TLS-Client-Cert-Filename} is the name - # of the temporary file containing the cert - # in PEM format. This file is automatically - # deleted by the server when the command - # returns. - # client = "/path/to/openssl verify -CApath ${..ca_path} %{TLS-Client-Cert-Filename}" - } - } -} - -clients radsec { - client 127.0.0.1 { - ipaddr = 127.0.0.1 - - # - # Ensure that this client is TLS *only*. - # - proto = tls - - # - # TCP clients can have any shared secret. - # - # TLS clients MUST have the shared secret - # set to "radsec". Or, for "proto = tls", - # you can omit the secret, and it will - # automatically be set to "radsec". - # - secret = radsec - - # - # You can also use a "limit" section here. - # See raddb/clients.conf for examples. - # - # Note that BOTH limits are applied. You - # should therefore set the "listen" limits - # higher than the ones for each individual - # client. - # - } -} - -# -# When a request is proxied to a TLS-enabled home server, -# the TLS parameters are available via the expansion: -# -# %{proxy_listen: ... } -# -# The contents of the expansion are the same as described -# above with the %{listen: ... } expansion, and have similar -# meanings. "client" in this case is the proxy (this system) -# and "server" is the remote system (home server). -# -# Note that the %{proxy_listen: ... } parameters are available -# only AFTER the connection has been made to the home server. -# -home_server tls { - ipaddr = 127.0.0.1 - port = 2083 - - # type can be the same types as for the "listen" section/ - # e.g. auth, acct, auth+acct, coa - type = auth - secret = radsec - proto = tcp - status_check = none - - tls { - # - # Similarly to HTTP, the client can use Server Name - # Indication to inform the RadSec server of which - # domain it is requesting. This selection allows - # multiple sites to exist at the same IP address. - # - # For example, and identity provider could host - # multiple sites, but present itself with one public - # IP address. - # - # SNI also permits the use of a load balancer such as - # haproxy. That load balancer can terminate the TLS - # connection, and then use SNI to route the - # underlying RADIUS TCP traffic to a particular host. - # - # Note that "hostname" here is only for SNI, and is NOT - # the hostname or IP address we connect to. For that, - # see "ipaddr", above. - # - # hostname = "example.com" - - private_key_password = whatever - private_key_file = ${certdir}/client.pem - - # If Private key & Certificate are located in - # the same file, then private_key_file & - # certificate_file must contain the same file - # name. - # - # If ca_file (below) is not used, then the - # certificate_file below MUST include not - # only the server certificate, but ALSO all - # of the CA certificates used to sign the - # server certificate. - certificate_file = ${certdir}/client.pem - - # Trusted Root CA list - # - # ALL of the CA's in this list will be trusted - # to issue client certificates for authentication. - # - # In general, you should use self-signed - # certificates for 802.1x (EAP) authentication. - # In that case, this CA file should contain - # *one* CA certificate. - # - # This parameter is used only for EAP-TLS, - # when you issue client certificates. If you do - # not use client certificates, and you do not want - # to permit EAP-TLS authentication, then delete - # this configuration item. - ca_file = ${cadir}/ca.pem - - # - # For TLS-PSK, the key should be specified - # dynamically, instead of using a hard-coded - # psk_identity and psk_hexphrase. - # - # The input to the dynamic expansion will be the PSK - # identity supplied by the client, in the - # TLS-PSK-Identity attribute. The output of the - # expansion should be a hex string, of no more than - # 512 characters. The string should not be prefixed - # with "0x". e.g. "abcdef" is OK. "0xabcdef" is not. - # - # psk_query = "%{psksql:select hex(key) from psk_keys where keyid = '%{TLS-PSK-Identity}'}" - - # - # For DH cipher suites to work, you have to - # run OpenSSL to create the DH file first: - # - # openssl dhparam -out certs/dh 1024 - # - dh_file = ${certdir}/dh - random_file = /dev/urandom - - # - # The default fragment size is 1K. - # However, TLS can send 64K of data at once. - # It can be useful to set it higher. - # - fragment_size = 8192 - - # include_length is a flag which is - # by default set to yes If set to - # yes, Total Length of the message is - # included in EVERY packet we send. - # If set to no, Total Length of the - # message is included ONLY in the - # First packet of a fragment series. - # - # include_length = yes - - # Check the Certificate Revocation List - # - # 1) Copy CA certificates and CRLs to same directory. - # 2) Execute 'c_rehash '. - # 'c_rehash' is OpenSSL's command. - # 3) uncomment the line below. - # 5) Restart radiusd - # check_crl = yes - ca_path = ${cadir} - - # - # If check_cert_issuer is set, the value will - # be checked against the DN of the issuer in - # the client certificate. If the values do not - # match, the certificate verification will fail, - # rejecting the user. - # - # In 2.1.10 and later, this check can be done - # more generally by checking the value of the - # TLS-Client-Cert-Issuer attribute. This check - # can be done via any mechanism you choose. - # - # check_cert_issuer = "/C=GB/ST=Berkshire/L=Newbury/O=My Company Ltd" - - # - # If check_cert_cn is set, the value will - # be xlat'ed and checked against the CN - # in the client certificate. If the values - # do not match, the certificate verification - # will fail rejecting the user. - # - # This check is done only if the previous - # "check_cert_issuer" is not set, or if - # the check succeeds. - # - # In 2.1.10 and later, this check can be done - # more generally by checking the value of the - # TLS-Client-Cert-Common-Name attribute. This check - # can be done via any mechanism you choose. - # - # check_cert_cn = %{User-Name} - # - # Set this option to specify the allowed - # TLS cipher suites. The format is listed - # in "man 1 ciphers". - cipher_list = "DEFAULT" - } - -} - -home_server_pool tls { - type = fail-over - home_server = tls -} - -realm tls { - auth_pool = tls -} diff --git a/pkgs/fablab/freeradius-anon-access/raddb/sites-available/totp b/pkgs/fablab/freeradius-anon-access/raddb/sites-available/totp deleted file mode 100644 index 59f0f85..0000000 --- a/pkgs/fablab/freeradius-anon-access/raddb/sites-available/totp +++ /dev/null @@ -1,85 +0,0 @@ -###################################################################### -# -# $Id: e42bf05e189b6272426927173033c4d6d6eae237 $ -# -###################################################################### -# -# Simple server to do TOTP and not much else. -# -server totp { -authorize { - # - # TOTP only works for PAP - # - if (!&User-Password) { - reject - } - - # - # The 6-digit TOTP password should be at the end of the - # User-Password attribute. It can be at the beginning or at - # the end, it doesn't really make any difference. Just - # update the regular expression for whatever you want. - # - # If the password doesn't have 6 digits at the end, reject. - # - if (User-Password !~ /^(.*)([0-9]{6})$/) { - reject - } - - # - # Separate the two fields - # - update request { - User-Password := "%{1}" - TOTP-Password := "%{2}" - } - - # - # Get the users' real password and authorization credentials - # from somewhere, such as a database. This should also set - # - # &control:TOTP-Secret - # - -ldap - -sql - - # - # As an example, fake out the TOTP secret - # - # The value should be the base-32 version of the TOTP secret. - # - # Note that the TOTP secret is effectively a password, and - # should be kept secret! At this time, there is no way to - # "hide" or "encrypt" the TOTP secret for a user. Even if it - # was encrypted, the server would still need a key to decrypt - # it. So encrypying this field does not offer much benefit. - # - if (&User-Name == "bob") { - &control:TOTP-Secret := 12345678901234567890 - } - - # - # Verify the 6-digit TOTP password. If the module does not - # return "ok", then the TOTP password is wrong. - # - totp.authenticate - if (!ok) { - reject - } - - # - # Set Auth-Type = PAP - # - pap -} - -authenticate { - # - # Check the User-Password against whatever we found in LDAP - # or SQL. - # - pap -} - -} diff --git a/pkgs/fablab/freeradius-anon-access/raddb/sites-available/virtual.example.com b/pkgs/fablab/freeradius-anon-access/raddb/sites-available/virtual.example.com deleted file mode 100644 index d25f031..0000000 --- a/pkgs/fablab/freeradius-anon-access/raddb/sites-available/virtual.example.com +++ /dev/null @@ -1,32 +0,0 @@ -# -*- text -*- -###################################################################### -# -# Sample virtual server for internally proxied requests. -# -# See the "realm virtual.example.com" example in "proxy.conf". -# -# $Id: 3c4aea7458cca50c9f43f33e6aebd5ca08180de7 $ -# -###################################################################### - -# -# You will want to edit this to your local needs. We suggest copying -# the text from the "default" file here, and then editing the text. -# That way, any changes to the "default" file will not affect this -# virtual server, and vice-versa. -# -# When this virtual server receives the request, the original -# attributes can be accessed as "outer.request", "outer.control", etc. -# See "man unlang" for more details. -# -server virtual.example.com { -authorize { - # insert policies here -} - -authenticate { - # insert policies here -} - -# etc. -} diff --git a/pkgs/fablab/freeradius-anon-access/raddb/sites-available/vmps b/pkgs/fablab/freeradius-anon-access/raddb/sites-available/vmps deleted file mode 100644 index 4470586..0000000 --- a/pkgs/fablab/freeradius-anon-access/raddb/sites-available/vmps +++ /dev/null @@ -1,98 +0,0 @@ -# -*- text -*- -###################################################################### -# -# As of version 2.0.0, the server also supports the VMPS -# protocol. -# -# $Id: c5c50786f4f5563d27218c70bf98c3898f47e5ba $ -# -###################################################################### - -server vmps { - listen { - # VMPS sockets only support IPv4 addresses. - ipaddr = * - - # Port on which to listen. - # Allowed values are: - # integer port number - # 1589 is the default VMPS port. - port = 1589 - - # Type of packets to listen for. Here, it is VMPS. - type = vmps - - # Some systems support binding to an interface, in addition - # to the IP address. This feature isn't strictly necessary, - # but for sites with many IP addresses on one interface, - # it's useful to say "listen on all addresses for - # eth0". - # - # If your system does not support this feature, you will - # get an error if you try to use it. - # - # interface = eth0 - } - - # If you have switches that are allowed to send VMPS, but NOT - # RADIUS packets, then list them here as "client" sections. - # - # Note that for compatibility with RADIUS, you still have to - # list a "secret" for each client, though that secret will not - # be used for anything. - - - # And the REAL contents. This section is just like the - # "post-auth" section of radiusd.conf. In fact, it calls the - # "post-auth" component of the modules that are listed here. - # But it's called "vmps" to highlight that it's for VMPS. - # - vmps { - # - # Some requests may not have a MAC address. Try to - # create one using other attributes. - if (!&VMPS-Mac) { - if (&VMPS-Ethernet-Frame =~ /0x.{12}(..)(..)(..)(..)(..)(..).*/) { - update request { - &VMPS-Mac = "%{1}:%{2}:%{3}:%{4}:%{5}:%{6}" - } - } - else { - update request { - &VMPS-Mac = &VMPS-Cookie - } - } - } - - # Do a simple mapping of MAC to VLAN. - # - # See radiusd.conf for the definition of the "mac2vlan" - # module. - # - #mac2vlan - - # required VMPS reply attributes - update reply { - &VMPS-Packet-Type = VMPS-Join-Response - &VMPS-Cookie = &VMPS-Mac - - &VMPS-VLAN-Name = "please_use_real_vlan_here" - - # - # If you have VLAN's in a database, you can select - # the VLAN name based on the MAC address. - # - #&VMPS-VLAN-Name = "%{sql:select ... where mac='%{VMPS-Mac}'}" - } - - # correct reply packet type for reconfirmation requests - # - if (&VMPS-Packet-Type == VMPS-Reconfirm-Request){ - update reply { - &VMPS-Packet-Type := VMPS-Reconfirm-Response - } - } - } - - # Proxying of VMPS requests is NOT supported. -}