fablab-nea/nix-gscheits
1
0
Fork 0
Code Issues 7 Pull requests 3 Projects Releases Packages Wiki Activity Actions

Remove unused sites

Browse source
This commit is contained in:
Jakob Lechner 2022-08-04 03:03:55 +00:00
parent 2c13e0d224
commit 115ae30929
No known key found for this signature in database
GPG key ID: 996082EFB5906C10
26 changed files with 0 additions and 4438 deletions
Download patch file Download diff file Expand all files Collapse all files

335
pkgs/fablab/freeradius-anon-access/raddb/sites-available/README
View file

@ -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 = <name>
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 = <name>
If set, the "listen" section looks for a "clients" section:
clients <name> {
...
}
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 = <name>
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.

118
pkgs/fablab/freeradius-anon-access/raddb/sites-available/abfab-tls
View file

@ -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.
# }
}

198
pkgs/fablab/freeradius-anon-access/raddb/sites-available/abfab-tr-idp
View file

@ -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
}
}

161
pkgs/fablab/freeradius-anon-access/raddb/sites-available/buffered-sql
View file

@ -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.
}

123
pkgs/fablab/freeradius-anon-access/raddb/sites-available/challenge
View file

@ -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
}
}
}

17
pkgs/fablab/freeradius-anon-access/raddb/sites-available/channel_bindings
View file

@ -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
}
}

135
pkgs/fablab/freeradius-anon-access/raddb/sites-available/check-eap-tls
View file

@ -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
}
}

49
pkgs/fablab/freeradius-anon-access/raddb/sites-available/coa
View file

@ -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.
}

331
pkgs/fablab/freeradius-anon-access/raddb/sites-available/coa-relay
View file

@ -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 <<EOF | radclient 127.0.0.1 coa testing123
# User-Name = bob
# Cisco-AVPair = "subscriber:sub-qos-policy-out=q_out_uncapped"
# EOF
#
# In addition to configuring and activating this site, a detail
# writer module must be configured in mods-enabled:
#
# detail detail_coa {
# filename = ${radacctdir}/detail_coa
# escape_filenames = no
# permissions = 0600
# header = "%t"
# locking = yes
# }
#
# Listen on a local CoA port.
#
# This uses the normal set of clients, with the same secret as for
# authentication and accounting.
#
listen {
type = coa
ipaddr = 127.0.0.1
port = 3799
virtual_server = coa
}
#
# Receive CoA/Disconnect, lookup sessions, write them to a detail file
#
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 {
#
# Lookup all active sessions matching User-Name and/or
# Acct-Session-Id and write each session (which includes to
# owning NAS and session ID) to a detail file.
#
# Returns a single result in the format:
#
# NasIpAddress1#AcctSessionId1|NasIPAddress2#AcctSessionId2|...
#
# i.e. each session is separated by '|', and attributes
# within a session are separated by '#'
#
# You will likely have to update the SELECT to add in
# any other "session identification" attributes
# needed by the NAS. These may include NAS-Port,
# NAS-Identifier, etc. Only the NAS vendor knows
# what these attributes are unfortunately, so we
# cannot give more detailed advice here.
#
update control {
#
# Example MySQL lookup
#
# Tmp-String-0 := "%{sql:SELECT IFNULL(GROUP_CONCAT(CONCAT(nasipaddress,'#',acctsessionid) separator '|'),'') FROM (SELECT * FROM radacct WHERE ('%{User-Name}'='' OR UserName='%{User-Name}') AND ('%{Acct-Session-Id}'='' OR acctsessionid = '%{Acct-Session-Id}') AND AcctStopTime IS NULL) a}"
#
# Example PostgreSQL lookup
#
# Tmp-String-0 := "%{sql:SELECT STRING_AGG(CONCAT(nasipaddress,'#',acctsessionid),'|') FROM (SELECT * FROM radacct WHERE ('%{User-Name}'='' OR UserName='%{User-Name}') AND ('%{Acct-Session-Id}'='' OR acctsessionid = '%{Acct-Session-Id}') AND AcctStopTime IS NULL) a}"
}
#
# Split the string and split into pieces.
#
if (&control:Tmp-String-0 != "" && "%{explode:&control:Tmp-String-0 |}") {
foreach &control:Tmp-String-0 {
if ("%{Foreach-Variable-0}" =~ /([^#]*)#(.*)/) {
update request {
COA-Packet-Type := "%{Packet-Type}"
COA-Packet-DST-IP-Address := "%{1}"
COA-Acct-Session-Id := "%{2}"
#
# Add any other attributes here.
#
# Set the CoA/Disconnect port
COA-Packet-DST-Port := 1700
# SQL-User-Name was left over
# from the xlat
SQL-User-Name !* ANY
# Uncomment if the NAS does not
# expect User-Name
#User-Name !* ANY
}
#
# If we're sending a CoA packet, send it out.
#
if (COA-Packet-DST-IP-Address && \
COA-Acct-Session-Id != "") {
detail_coa.accounting
}
}
}
} else {
# No sessions found
reject
}
}
}
#
# Detail file reader that processes the queue of CoA/Disconnect requests
#
server coa-buffered-reader {
listen {
#
# See sites-available/buffered-sql for more details on
# all the options available for the detail reader.
#
type = detail
filename = "${radacctdir}/detail_coa"
load_factor = 90
track = yes
}
#
# For historical reasons packets from the detail file reader are
# processed through the "accounting" section.
#
accounting {
switch &COA-Packet-Type {
case "Disconnect-Request" {
update {
# Include given attributes
disconnect: += request:[*]
disconnect:Packet-DST-IP-Address := \
&COA-Packet-DST-IP-Address
disconnect:Packet-DST-Port := \
&COA-Packet-DST-Port
disconnect:Acct-Session-Id := \
&COA-Acct-Session-Id
# Some NASs want these, others don't
disconnect:Event-Timestamp := "%l"
disconnect:Message-Authenticator := 0x00
# Remove this. We're not accounting
disconnect:Acct-Delay-Time !* ANY
}
}
case "CoA-Request" {
update {
# Include given attributes
coa: += request:[*]
coa:Packet-DST-IP-Address := \
&COA-Packet-DST-IP-Address
coa:Packet-DST-Port := \
&COA-Packet-DST-Port
coa:Acct-Session-Id := \
&COA-Acct-Session-Id
# Some NASs want these, others don't
coa:Event-Timestamp := "%l"
coa:Message-Authenticator := 0x00
#
# Remove attributes which will confuse the NAS
#
# The NAS will "helpfully" NAK the packet
# if it contains attributes which are NOT
# "session identification" attributes.
#
# Those attributes should be listed here.
#
coa:Acct-Delay-Time !* ANY
coa:Proxy-State !* ANY
}
}
}
#
# ACK the CoA / Disconnect packet.
#
ok
}
}
# 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-relay {
#
# 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
}
}
}
#
# Homeserver CoA / Disconnect endpoints
#
# See proxy.conf for more details on configuring a home_server and
# home_server_pool.
#
home_server coa-nas1 {
type = coa
# Update these to match your NAS
ipaddr = 192.0.2.1
port = 1700
secret = testing1234
coa {
irt = 2
mrt = 16
mrc = 5
mrd = 30
}
}
home_server_pool coa-nas1 {
type = fail-over
home_server = coa-nas1
virtual_server = originate-coa-relay
}

92
pkgs/fablab/freeradius-anon-access/raddb/sites-available/control-socket
View file

@ -1,92 +0,0 @@
# -*- text -*-
######################################################################
#
# Control socket interface.
#
# In the future, we will add username/password checking for
# connections to the control socket. We will also add
# command authorization, where the commands entered by the
# administrator are run through a virtual server before
# they are executed.
#
# For now, anyone who has permission to connect to the socket
# has nearly complete control over the server. Be warned!
#
# This functionality is NOT enabled by default.
#
# See also the "radmin" program, which is used to communicate
# with the server over the control socket.
#
# $Id: 97ba9ef972539af80dcaf84090b55d991095a93e $
#
######################################################################
listen {
#
# Listen on the control socket.
#
type = control
#
# Socket location.
#
# This file is created with the server's uid and gid.
# It's permissions are r/w for that user and group, and
# no permissions for "other" users. These permissions form
# minimal security, and should not be relied on.
#
socket = ${run_dir}/${name}.sock
#
# Peercred auth
#
# By default the server users the peercred feature of unix
# sockets to get the UID and GID of the user connecting to
# the socket. You may choose to disable this functionality
# and rely on the file system for enforcing permissions.
#
# On most Unix systems, the permissions set on the socket
# are not enforced, but the ones on the directory containing
# the socket are.
#
# To use filesystem permissions you should create a new
# directory just to house the socket file, and set
# appropriate permissions on that.
#
# peercred = no
# socket = ${run_dir}/control/${name}.sock
#
# The following two parameters perform authentication and
# authorization of connections to the control socket.
#
# If not set, then ANYONE can connect to the control socket,
# and have complete control over the server. This is likely
# not what you want.
#
# One, or both, of "uid" and "gid" should be set. If set, the
# corresponding value is checked. Unauthorized users result
# in an error message in the log file, and the connection is
# closed.
#
#
# Name of user that is allowed to connect to the control socket.
#
# uid = radius
#
# Name of group that is allowed to connect to the control socket.
#
# gid = radius
#
# Access mode.
#
# This can be used to give *some* administrators access to
# monitor the system, but not to change it.
#
# ro = read only access (default)
# rw = read/write access.
#
# mode = rw
}

202
pkgs/fablab/freeradius-anon-access/raddb/sites-available/copy-acct-to-home-server
View file

@ -1,202 +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 packets
# are proxied to a home server. You will have to configure
# realms, home_server_pool, and home_server in proxy.conf
# for this to work.
#
# The purpose of this virtual server is to enable duplication
# of information across a load-balanced, or fail-over set of
# servers. For example, if a group of clients lists two
# home servers (primary, secondary), then RADIUS accounting
# messages will go only to one server at a time. This file
# configures a server (primary, secondary) to send copies of
# the accounting information to each other.
#
# That way, each server has the same set of information, and
# can make the same decision about the user.
#
# $Id: cd085e099a30f492984f539760561c8d34edff95 $
#
######################################################################
server copy-acct-to-home-server {
listen {
type = detail
#
# See sites-available/buffered-sql for more details on
# all the options available for the detail reader.
#
######################################################
#
# !!!! WARNING !!!!
#
# The detail file reader acts just like a NAS.
#
# This means that if accounting fails, the packet
# is re-tried FOREVER. It is YOUR responsibility
# to write an accounting policy that returns "ok"
# if the packet was processed properly, "fail" on
# a database error, AND "ok" if you want to ignore
# the packet (e.g. no Acct-Status-Type).
#
# Neither the detail file write OR the detail file
# reader look at the contents of the packets. They
# just either dump the packet verbatim to the file,
# or read it verbatim from the file and pass it to
# the server.
#
######################################################
# 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.
#
# Do NOT copy the "filename" configuration from the
# "detail" module here. It won't work. Instead, use
# file globbing (or wildcards), such as:
#
# filename = ${radacctdir}/reader1/detail-*
#
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
#
# 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
}
#
# Pre-accounting. Decide which accounting type to use.
#
preacct {
preprocess
# Since we're just proxying, we don't need acct_unique.
#
# Look for IPASS-style 'realm/', and if not found, look for
# '@realm', and decide whether or not to proxy, based on
# that.
#
# Accounting requests are generally proxied to the same
# home server as authentication requests.
# IPASS
# suffix
# ntdomain
#
# Edit proxy.conf to add a "home_server" section,
# which points to the other server.
#
# Then set that home_server name here.
#
update control {
Home-Server-Name := "name_of_home_server_from_proxy.conf"
}
#
# 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 {
#
# Since we're proxying, we don't log anything
# locally. Ensure that the accounting section
# "succeeds" by forcing an "ok" return.
ok
}
#
# 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 {
# 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 in radiusd.conf.
# 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 in radiusd.conf.
# 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
}
}

139
pkgs/fablab/freeradius-anon-access/raddb/sites-available/decoupled-accounting
View file

@ -1,139 +0,0 @@
# -*- text -*-
######################################################################
#
# This is a sample configuration for "decoupled" accounting.
# "Decoupled" accounting is where the accounting packets are
# NOT written "live" to the back-end database. This method
# can only be used if you are not interested in "live"
# accounting. i.e. Where you can tolerate delays that may be
# a few seconds, before accounting packets get written to
# the DB.
#
# Oddly enough, this method can speed up the processing of
# accounting packets, as all database activity is serialized.
#
# This file is NOT meant to be used as-is. It needs to be
# edited to match your local configuration.
#
# $Id: abf455cc2cf10da1e8e749a90b544a533c7e26e1 $
#
######################################################################
# Define a virtual server to write the accounting packets.
# Any "listen" section that listens on an accounting port should
# set "virtual_server = write-detail.example.com
server write_detail.example.com {
accounting {
#
# Write the "detail" files.
#
# See raddb/modules/detail.example.com for more info.
detail.example.com
}
# That's it!
}
# Define a virtual server to process the accounting packets.
server read-detail.example.com {
# Read accounting packets from the detail file(s) for
# the home server.
listen {
type = detail
filename = "${radacctdir}/detail.example.com/detail-*:*"
load_factor = 10
track = yes
}
# All packets read from the detail file are processed through
# the preacct && accounting sections.
#
# The following text is copied verbatim from sites-available/default.
# You should edit it for your own local configuration.
#
# 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
#
# Look for IPASS-style 'realm/', and if not found, look for
# '@realm', and decide whether or not to proxy, based on
# that.
#
# Accounting requests are generally proxied to the same
# home server as authentication requests.
# IPASS
suffix
# ntdomain
#
# Read the 'acct_users' file
files
}
#
# Accounting. Log the accounting data.
#
accounting {
#
# Create a 'detail'ed log of the packets.
# Note that accounting requests which are proxied
# are also logged in the detail file.
detail
# daily
# Update the wtmp file
#
# If you don't use "radlast", you can delete this line.
unix
#
# For Simultaneous-Use tracking.
#
# Due to packet losses in the network, the data here
# may be incorrect. There is little we can do about it.
radutmp
# sradutmp
#
# Return an address to the IP Pool when we see a stop record.
#
# Ensure that &control:Pool-Name is set to determine which
# pool of IPs are used.
# sqlippool
#
# Log traffic to an SQL database.
#
# NOTE! You will have to ensure that any accounting packets
# NOT handled by the SQL module (e.g. "stop with zero session length"
# result in the accounting section still returning "ok".
#
# Otherwise, the server will think that the accounting packet
# was NOT handled properly, and will keep trying to process it
# through this virtual server!
#
# See "Accounting queries" in `mods-config/sql/main/$driver/queries.conf`
# sql
# Cisco VoIP specific bulk accounting
# pgsql-voip
# Filter attributes from the accounting response.
attr_filter.accounting_response
#
# See "Autz-Type Status-Server" for how this works.
#
# Acct-Type Status-Server {
#
# }
}
}

584
pkgs/fablab/freeradius-anon-access/raddb/sites-available/dhcp
View file

@ -1,584 +0,0 @@
# -*- text -*-
######################################################################
#
# This is a virtual server that handles DHCP.
#
# See raddb/mods-available/dhcp_sqlippool for the IP Pool configuration.
#
# See raddb/policy.d/dhcp_sqlippool for the "glue" code that allows
# the RADIUS based "sqlippool" module to be used for DHCP.
#
# See raddb/mods-config/sql/ippool/ for the schemas.
#
# See raddb/sites-available/dhcp for instructions on how to configure
# the DHCP server.
#
# $Id: 4f5ed5102a6c9fed3c352b3666faafe5b2f86c11 $
#
######################################################################
#
# The DHCP functionality goes into a virtual server.
#
server dhcp {
# Define a DHCP socket.
#
# The default port below is 6700, so you don't break your network.
# If you want it to do real DHCP, change this to 67, and good luck!
#
# You can also bind the DHCP socket to an interface.
# See below, and raddb/radiusd.conf for examples.
#
# This lets you run *one* DHCP server instance and have it listen on
# multiple interfaces, each with a separate policy.
#
# If you have multiple interfaces, it is a good idea to bind the
# listen section to an interface. You will also need one listen
# section per interface.
#
# FreeBSD does *not* support binding sockets to interfaces. Therefore,
# if you have multiple interfaces, broadcasts may go out of the wrong
# one, or even all interfaces. The solution is to use the "setfib" command.
# If you have a network "10.10.0/24" on LAN1, you will need to do:
#
# Pick any IP on the 10.10.0/24 network
# $ setfib 1 route add default 10.10.0.1
#
# Edit /etc/rc.local, and add a line:
# setfib 1 /path/to/radiusd
#
# The kern must be built with the following options:
# options ROUTETABLES=2
# or any value larger than 2.
#
# The other only solution is to update FreeRADIUS to use BPF sockets.
#
listen {
# This is a dhcp socket.
type = dhcp
# IP address to listen on. Will usually be the IP of the
# interface, or 0.0.0.0
ipaddr = 127.0.0.1
# source IP address for unicast packets sent by the
# DHCP server.
#
# The source IP for unicast packets is chosen from the first
# one of the following items which returns a valid IP
# address:
#
# src_ipaddr
# ipaddr
# reply:DHCP-Server-IP-Address
# reply:DHCP-DHCP-Server-Identifier
#
src_ipaddr = 127.0.0.1
# The port should be 67 for a production network. Don't set
# it to 67 on a production network unless you really know
# what you're doing. Even if nothing is configured below, the
# server may still NAK legitimate responses from clients.
port = 6700
# Interface name we are listening on. See comments above.
# interface = lo0
# The DHCP server defaults to allowing broadcast packets.
# Set this to "no" only when the server receives *all* packets
# from a relay agent. i.e. when *no* clients are on the same
# LAN as the DHCP server.
#
# It's set to "no" here for testing. It will usually want to
# be "yes" in production, unless you are only dealing with
# relayed packets.
broadcast = no
# On Linux if you're running the server as non-root, you
# will need to do:
#
# sudo setcap cap_net_admin=ei /path/to/radiusd
#
# This will allow the server to set ARP table entries
# for newly allocated IPs
# De-duplicate DHCP packets. If clients don't receive
# a reply within their timeout, most will re-transmit.
# A reply to either packet will satisfy, so de-duplicating
# helps manage load on a busy server
performance {
skip_duplicate_checks = no
}
}
# 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.
# Return packets will be sent to, in preference order:
# DHCP-Gateway-IP-Address
# DHCP-Client-IP-Address
# DHCP-Your-IP-Address
# At least one of these attributes should be set at the end of each
# section for a response to be sent.
# An internal attribute of DHCP-Network-Subnet is set to provide
# a basis for determining the network that a client belongs to. This
# is a hierarchical assignment based on:
#
# - DHCP-Relay-Link-Selection
# - DHCP-Subnet-Selection-Option
# - DHCP-Gateway-IP-Address
# - DHCP-Client-IP-Address
#
# Except for cases where all IP allocation is performed using a mapping from
# the device MAC address to a fixed IP address the DHCP configuration will
# involve the use of one or more pools.
#
# Each pool should be composed of a set of equally valid IP addresses for the
# devices designated as users of the pool. During IP allocation the choice of
# pool is driven by setting the Pool-Name attribute which may either be
# specified directly or chosen (usually with the help of the dhcp_network
# module) based on the initial value of DHCP-Network-Subnet.
#
# DHCP-Network-Subnet indicates the network from which the request is
# originating. In cases where the originating network alone is insufficent to
# define the required IP allocated policy, DHCP-Network-Subnet may be
# overridden to force the selection of a particular pool.
#
# IP addresses belonging to a single pool that is designated for a Layer 2
# network containing multiple subnets (a "shared-network" or "multinet"
# configuration as defined by some other DHCP servers), will by definition be
# members of distinct subnets that require their own DHCP reply parameters. In
# this case the dhcp_subnet policy can be used to set the correct
# DHCP-Subnet-Mask, DHCP-Router-Address and DHCP-Broadcast-Address options
# based on the allocated IP.
dhcp DHCP-Discover {
# The DHCP Server Identifier is set here since is returned in OFFERs
update control {
&DHCP-DHCP-Server-Identifier = 192.0.2.2
}
# Call a policy (defined in policy.d/dhcp) to set common reply attributes
dhcp_common
# Use a "passwd" module to set group memberships in DHCP-Group-Name
# Enable mods-available/dhcp_passwd to use this
#dhcp_group_membership
# If clients need to be assigned to a particular network based on
# an attribute in the packet rather than the calculated
# DHCP-Network-Subnet described above, then call a policy
# (defined in policy.d/dhcp) to perform the override
#dhcp_override_network
# Use a "files" module to lookup global and subnet options
# For multiple subnets use this in place of dhcp_common
# Enable mods-available/dhcp_files to use this
# Options are set in mods-config/files/dhcp
#dhcp_network
# Do a simple mapping of MAC to assigned IP.
#
# See below for the definition of the "mac2ip"
# module.
#
#mac2ip
# Or, allocate IPs from the DHCP pool in SQL. You may need to
# set the pool name here if you haven't set it elsewhere.
#update control {
# &Pool-Name := "local"
#}
#dhcp_sqlippool
# If the IP address was not allocated, do something else.
# You could call a Perl, Python, or Java script here.
#if (notfound) {
# ...
#}
# "Shared-networks" may have multiple IP subnets co-existing in a
# single Layer 2 network. If the pool for the network contains
# addresses from more that one subnet then the setting subnet-specific
# DHCP-Subnet-Mask, DHCP-Router-Address and DHCP-Broadcast-Address
# parameters must be performed after the allocation of the IP address.
#
# Set any subnet-specific parameters using this policy.
#
# Enable mods-available/dhcp_files AND uncomment dhcp_subnet in
# policy.d/dhcp to use this.
#
#dhcp_subnet
# Use a "files" module to lookup options based on DHCP-Group-Name
# Enable mods-available/dhcp_files to use this
# Options are set in mods-config/files/dhcp
#dhcp_group_options
# Use a "files" module to lookup host specific options
# Enable mods-available/dhcp_files to use this
# Options are set in mods-config/files/dhcp
#dhcp_hosts
# As an alternative or complement to configuration files based lookup
# for options data you can instead use an SQL database. Example
# configuration is found in dhcp_policy_sql in policy.d/dhcp which
# will need to be adapted to your requirements.
#dhcp_policy_sql
# Set the type of packet to send in reply.
#
# The server will look at the DHCP-Message-Type attribute to
# determine which type of packet to send in reply. Common
# values would be DHCP-Offer, DHCP-Ack or DHCP-NAK. See
# dictionary.dhcp for all the possible values.
#
# DHCP-Do-Not-Respond can be used to tell the server to not
# respond.
#
# In the event that DHCP-Message-Type is not set then the
# server will fall back to determining the type of reply
# based on the rcode of this section.
#
#update reply {
# DHCP-Message-Type = DHCP-Offer
#}
#
# If DHCP-Message-Type is not set, returning "ok" or
# "updated" from this section will respond with a DHCP-Offer
# message.
#
# Other rcodes will tell the server to not return any response.
#
#ok
}
dhcp DHCP-Request {
# You must set the DHCP Server Identifier here since this is returned
# in ACKs and is used to determine whether a request containing a
# "server-ip" field is intended for this server
update control {
&DHCP-DHCP-Server-Identifier = 192.0.2.2
}
# If the request is not for this server then silently discard it
if (&request:DHCP-DHCP-Server-Identifier && \
&request:DHCP-DHCP-Server-Identifier != &control:DHCP-DHCP-Server-Identifier) {
do_not_respond
}
# Response packet type. See DHCP-Discover section above.
#update reply {
# &DHCP-Message-Type = DHCP-Ack
#}
# Call a policy (defined in policy.d/dhcp) to set common reply attributes
dhcp_common
# Use a "passwd" module to set group memberships in DHCP-Group-Name
# Enable mods-available/dhcp_passwd to use this
#dhcp_group_membership
# Optionally override the network address based on client attributes
# See Discover section
#dhcp_override_network
# Use a "files" module to lookup global and subnet options
# For multiple subnets use this in place of dhcp_common
# Enable mods-available/dhcp_files AND uncomment dhcp_subnet in
# policy.d/dhcp to use this
# Options are set in mods-config/files/dhcp
#dhcp_network
# Do a simple mapping of MAC to assigned IP.
#
# See below for the definition of the "mac2ip"
# module.
#
#mac2ip
# Or, allocate IPs from the DHCP pool in SQL. You may need to
# set the pool name here if you haven't set it elsewhere.
# update control {
# &Pool-Name := "local"
# }
# dhcp_sqlippool_request
# If the IP was not allocated, do something else.
# You could call a Perl, Python, or Java script here.
#if (notfound) {
# ...
#}
# "Shared-networks" may have multiple IP subnets co-existing in a
# single Layer 2 network. If the pool for the network contains
# addresses from more that one subnet then the setting subnet-specific
# DHCP-Subnet-Mask, DHCP-Router-Address and DHCP-Broadcast-Address
# parameters must be performed after the allocation of the IP address.
#
# Set any subnet-specific parameters using this policy.
#
#dhcp_subnet
# Use a "files" module to lookup options based on DHCP-Group-Name
# Enable mods-available/dhcp_files to use this
# Options are set in mods-config/files/dhcp
#dhcp_group_options
# Use a "files" module to lookup host specific options
# Enable mods-available/dhcp_files to use this
# Options are set in mods-config/files/dhcp
#dhcp_hosts
# As an alternative or complement to configuration files based lookup
# for options data you can instead use an SQL database. Example
# configuration is found in dhcp_policy_sql in policy.d/dhcp which
# will need to be adapted to your requirements.
#dhcp_policy_sql
# If DHCP-Message-Type is not set, returning "ok" or
# "updated" from this section will respond with a DHCP-Ack
# packet.
#
# "handled" will not return a packet, all other rcodes will
# send back a DHCP-NAK.
#
#ok
}
#
# Other DHCP packet types
#
# There should be a separate section for each DHCP message type.
# By default this configuration will ignore them all. Any packet type
# not defined here will be responded to with a DHCP-NAK.
dhcp DHCP-Decline {
# Use a "passwd" module to set group memberships in DHCP-Group-Name
# Enable mods-available/dhcp_passwd to use this
#dhcp_group_membership
# Optionally override the network address based on client attributes
# See Discover section
#dhcp_override_network
# Use a "files" module to lookup global and subnet options
# For multiple networks use this in place of dhcp_common
# Enable mods-available/dhcp_files to use this
# Options are set in mods-config/files/dhcp
#dhcp_network
# Use a policy that set options from data stored in an SQL database
#dhcp_policy_sql
# If using IPs from a DHCP pool in SQL then you may need to set the
# pool name here if you haven't set it elsewhere and release the IP.
# update control {
# &Pool-Name := "local"
# }
# dhcp_sqlippool_decline
update reply {
&DHCP-Message-Type = DHCP-Do-Not-Respond
}
reject
}
#
# A dummy config for Inform packets - this should match the
# options set in the Request section above, except Inform replies
# must not set Your-IP-Address or IP-Address-Lease-Time
#
dhcp DHCP-Inform {
# Call a policy (defined in policy.d/dhcp) to set common reply attributes
dhcp_common
# Use a "passwd" module to set group memberships in DHCP-Group-Name
# Enable mods-available/dhcp_passwd to use this
#dhcp_group_membership
# Optionally override the network address based on client attributes
# See Discover section
#dhcp_override_network
# Use a "files" module to lookup global and network options
# For multiple networks use this in place of dhcp_common
# Enable mods-available/dhcp_files to use this
# Options are set in mods-config/files/dhcp
#dhcp_network
# Use a policy with calls a "files" module of the same name to lookup
# subnet options
# Enable mods-available/dhcp_files AND uncomment dhcp_subnet in
# policy.d/dhcp to use this
# Options are set in mods-config/files/dhcp
#dhcp_subnet
# Use a "files" module to lookup options based on DHCP-Group-Name
# Enable mods-available/dhcp_files to use this
# Options are set in mods-config/files/dhcp
#dhcp_group_options
# Use a "files" module to lookup host specific options
# Enable mods-available/dhcp_files to use this
# Options are set in mods-config/files/dhcp
#dhcp_hosts
# Use a policy that set options from data stored in an SQL database
#dhcp_policy_sql
ok
}
#
# For Windows 7 boxes
#
#dhcp DHCP-Inform {
# update reply {
# Packet-Dst-Port = 67
# DHCP-Message-Type = DHCP-ACK
# DHCP-DHCP-Server-Identifier = "%{Packet-Dst-IP-Address}"
# DHCP-Site-specific-28 = 0x0a00
# }
# ok
#}
dhcp DHCP-Release {
# Use a "passwd" module to set group memberships in DHCP-Group-Name
# Enable mods-available/dhcp_passwd to use this
#dhcp_group_membership
# Optionally override the network address based on client attributes
# See Discover section
#dhcp_override_network
# Use a "files" module to lookup global and subnet options
# For multiple subnets use this in place of dhcp_common
# Enable mods-available/dhcp_files to use this
# Options are set in mods-config/files/dhcp
#dhcp_network
# If using IPs from a DHCP pool in SQL then you may need to set the
# pool name here if you haven't set it elsewhere and release the IP.
# update control {
# &Pool-Name := "local"
# }
# dhcp_sqlippool_release
update reply {
&DHCP-Message-Type = DHCP-Do-Not-Respond
}
reject
}
dhcp DHCP-Lease-Query {
# The thing being queried for is implicit
# in the packets.
# has MAC, asking for IP, etc.
if (&DHCP-Client-Hardware-Address) {
# look up MAC in database
}
# has IP, asking for MAC, etc.
elsif (&DHCP-Your-IP-Address) {
# look up IP in database
}
# has host name, asking for IP, MAC, etc.
elsif (&DHCP-Client-Identifier) {
# look up identifier in database
}
else {
update reply {
&DHCP-Message-Type = DHCP-Lease-Unknown
}
ok
# stop processing
return
}
#
# We presume that the database lookup returns "notfound"
# if it can't find anything.
#
if (notfound) {
update reply {
&DHCP-Message-Type = DHCP-Lease-Unknown
}
ok
return
}
#
# Add more logic here. Is the lease inactive?
# If so, respond with DHCP-Lease-Unassigned.
#
# Otherwise, respond with DHCP-Lease-Active
#
#
# Also be sure to return ALL information about
# the lease.
#
#
# The reply types are:
#
# DHCP-Lease-Unknown
# DHCP-Lease-Active
# DHCP-Lease-Unassigned
#
update reply {
&DHCP-Message-Type = DHCP-Lease-Unassigned
}
}
}
######################################################################
#
# This next section is a sample configuration for the "passwd"
# module, that reads flat-text files. It should go into
# radiusd.conf, in the "modules" section.
#
# The file is in the format <mac>,<ip>
#
# 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 = ","
#}

44
pkgs/fablab/freeradius-anon-access/raddb/sites-available/dhcp.relay
View file

@ -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
}
}

222
pkgs/fablab/freeradius-anon-access/raddb/sites-available/dynamic-clients
View file

@ -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
}
}

122
pkgs/fablab/freeradius-anon-access/raddb/sites-available/example
View file

@ -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.'
}
}
}
}

185
pkgs/fablab/freeradius-anon-access/raddb/sites-available/originate-coa
View file

@ -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
}
}
}

47
pkgs/fablab/freeradius-anon-access/raddb/sites-available/proxy-inner-tunnel
View file

@ -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
}
}

140
pkgs/fablab/freeradius-anon-access/raddb/sites-available/resource-check
View file

@ -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}
}
}
}
}
}

167
pkgs/fablab/freeradius-anon-access/raddb/sites-available/robust-proxy-accounting
View file

@ -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'
}
}
}

34
pkgs/fablab/freeradius-anon-access/raddb/sites-available/soh
View file

@ -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
}
}
}
}
}

127
pkgs/fablab/freeradius-anon-access/raddb/sites-available/status
View file

@ -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.
#

651
pkgs/fablab/freeradius-anon-access/raddb/sites-available/tls
View file

@ -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 <CA certs&CRLs Directory>'.
# '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 <CA certs&CRLs Directory>'.
# '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
}

85
pkgs/fablab/freeradius-anon-access/raddb/sites-available/totp
View file

@ -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
}
}

32
pkgs/fablab/freeradius-anon-access/raddb/sites-available/virtual.example.com
View file

@ -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.
}

98
pkgs/fablab/freeradius-anon-access/raddb/sites-available/vmps
View file

@ -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.
}