Copyright © 2021 BalaSys IT Security.
Copyright 2021 BalaSys IT Security.. All rights reserved. This document is protected by copyright and is distributed under licenses restricting its use, copying, distribution, and decompilation. No part of this document may be reproduced in any form by any means without prior written authorization of BalaSys.
This documentation and the product it describes are considered protected by copyright according to the applicable laws.
This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit (http://www.openssl.org/). This product includes cryptographic software written by Eric Young (eay@cryptsoft.com)
Linux™ is a registered trademark of Linus Torvalds.
Windows™ 10 is registered trademarks of Microsoft Corporation.
The BalaSys™ name and the BalaSys™ logo are registered trademarks of BalaSys IT Security.
The PNS™ name and the PNS™ logo are registered trademarks of BalaSys IT Security.
AMD Ryzen™ and AMD EPYC™ are registered trademarks of Advanced Micro Devices, Inc.
Intel® Core™ and Intel® Xeon™ are trademarks of Intel Corporation or its subsidiaries in the U.S. and/or other countries.
All other product names mentioned herein are the trademarks of their respective owners.
DISCLAIMER
BalaSys is not responsible for any third-party websites mentioned in this document. BalaSys does not endorse and is not responsible or liable for any content, advertising, products, or other material on or available from such sites or resources. BalaSys will not be responsible or liable for any damage or loss caused or alleged to be caused by or in connection with use of or reliance on any such content, goods, or services that are available on or through any such sites or resources.
October 31, 2024
Abstract
This document is a detailed reference guide for Proxedo Network Security Suite administrators.
Table of Contents
List of Examples
List of Procedures
Welcome to the Application-level Gateway Reference Guide. This book contains reference documentation on the available PNS proxies and their working environment, the Python framework.
This book contains information about the low-level proxy attributes available to customize proxy behavior and the low-level classes comprising ALG's access control and service framework. Basic introduction to the various protocols is also provided for reference, but the detailed discussion of the protocols is beyond the scope of this book.
Note |
---|
The name of the application effectively serving as the Application-level Gateway component of Proxedo Network Security Suite is PNS, commands, paths and internal references will relate to that naming. |
Chapter 1, How PNS works provides an overview of the internal working of ALG, for example, how a connection is received.
Chapter 2, Configuring PNS proxies describes the general concepts of configuring ALG proxies.
Chapter 3, The PNS SSL framework explains how to handle SSL-encrypted connections with ALG.
Chapter 4, Proxies is a complete reference of the ALG proxies, including their special features and options.
Chapter 5, Core is the reference of ALG core modules which are directly used by gateway administrators, forming the access control and authentication framework.
Appendix C, PNS manual pages is a collection of the command-line PNS utilities.
Appendix B, Global options of PNS is a reference the global options of PNS.
The following terms used throughout this documentation might require a brief explanation:
class: A class is a set of attribute and method definitions performing certain specific functionality. Classes can inherit methods and attributes from one or more parent classes. Classes do not contain actual values for attributes; they only describe them.
instance: An instance is a set of attribute values (as described by the class) and associated methods. Instances are also called objects. Instances are created from classes by "calling" the class, with arguments required by the constructor. For example, to create an instance of a class named "class" one would write class(arg1, arg2 [,.. argN]) where arg1 and arg2 are arguments of the constructor.
method: A function working in the context of an instance. It automatically receives a "self" argument which can be used to fetch or set attributes stored in the associated instance.
type: Variables in Python are not strongly typed, meaning that it is possible to assign any kind of values to a variable; typing is assigned to the value.
attribute: An attribute of an object is a variable holding some value, interpreted and manipulated by object methods. Although Python is not strongly typed, types were assigned to the variables in PNS to indicate what kind of values they are supposed to hold.
actiontuple: A tuple is a simple Python type defined as a list of values. An actiontuple is a special tuple defined by PNS where the first value must be a value specifying what action to take, and trailing items specify arguments to the action. For example (HTTP_REQ_REJECT, "We don't like this request") is a tuple for rejecting HTTP requests and returning the message specified in the second value.
This guide is intended for use by system administrators and consultants responsible for network security and whose task is the configuration and maintenance of PNS firewalls. PNS gives them a powerful and versatile tool to create full control over their network traffic and enables them to protect their clients against Internet-delinquency.
This guide is also useful for IT decision makers evaluating different firewall products because apart from the practical side of everyday PNS administration, it introduces the philosophy behind PNS without the marketing side of the issue.
The following skills and knowledge are necessary for a successful PNS administrator.
Skill | Level/Description |
---|---|
Linux | At least a power user's knowledge is required. |
Experience in system administration | Experience in system administration is certainly an advantage, but not absolutely necessary. |
Programming language knowledge | It is not an explicit requirement to know any programming languages though being familiar with the basics of Python may be an advantage, especially in evaluating advanced firewall configurations or in troubleshooting misconfigured firewalls. |
General knowledge on firewalls | A general understanding of firewalls, their roles in the enterprise IT infrastructure and the main concepts and tasks associated with firewall administration is essential. To fulfill this requirement a significant part of Chapter 3, Architectural overview in the PNS Administrator's Guide is devoted to the introduction to general firewall concepts. |
Knowledge on Netfilter concepts | In-depth knowledge is strongly recommended; while it is not strictly required definitely helps understanding the underlying operations and also helps in shortening the learning curve. |
Knowledge on TCP/IP protocol | High level knowledge of the TCP/IP protocol suite is a must, no successful firewall administration is possible without this knowledge. |
Table 1. Prerequisites
The PNS Distribution DVD-ROM contains the following software packages:
Current version of PNS 2 packages.
Current version of Management Server (MS) 2.
Current version of Management Console (MC) 2 (GUI) for both Linux and Windows operating systems, and all the necessary software packages.
Current version of Authentication Server (AS) 2.
Current version of the Authentication Agent (AA) 2, the AS client for both Linux and Windows operating systems.
For a detailed description of hardware requirements of PNS, see Chapter 1, System requirements in Proxedo Network Security Suite 2 Installation Guide.
For additional information on PNS and its components visit the PNS website containing white papers, tutorials, and online documentations on the above products.
This product is developed and maintained by BalaSys IT Security..
Contact:
BalaSys IT Security.
4 Alíz Street
H-1117 Budapest, Hungary
Tel: +36 1 646 4740
E-mail: <info@balasys.hu>
Web: http://balasys.hu/
You can directly contact us with sales related topics at the e-mail address
<sales@balasys.hu>
, or leave us your contact information and we call you back.
To access the BalaSys Support System, sign up for an account at the BalaSys Support System page. Online support is available 24 hours a day.
BalaSys Support System is available only for registered users with a valid support package.
Support e-mail address: <support@balasys.hu>
.
BalaSys IT Security. holds courses on using its products for new and experienced users. For dates, details, and application forms, visit the https://www.balasys.hu/en/services#training webpage.
This guide is a work-in-progress document with new versions appearing periodically.
The latest version of this document can be downloaded from the Documentation Page.
Any feedback is greatly appreciated, especially on what else this document should cover, including protocols and network setups. General comments, errors found in the text, and any suggestions about how to improve the documentation is welcome at <support@balasys.hu>
.
This chapter describes how PNS works, and provides information about the core PNS modules, explaining how they interoperate. For a detailed reference of the core modules, see the description of the particular in Chapter 5, Core.
PNS startup and initialization: The main PNS thread is started, and the rules listening for incoming connections are initialized.
Handling incoming connections: The client-side connection is established and the service to proxy the connection is selected.
Proxy startup and server-side connections: The proxy instance inspecting the traffic is created and connection to the server is established.
The velactl utility loads the
instances.conf
file and starts the main PNS
program. The instances.conf
file stores the parameters of the
configured PNS instances.
PNS performs the following initialization steps:
Sets the stack limit.
Creates its PID file.
Changes the running user to the user and group specified for the instance.
Initializes the handling of dynamic capabilities and sets the chroot directory.
Loads the firewall policy from the policy.py
file.
The init()
of PNS initializes the ruleset defined for the PNS instance.
The vela-nfqueue-helper
service uploads packet filtering services, rules, and zones into the kernel's netfilter module.
Note |
---|
PNS creates four sockets (one for each type of traffic: TCP IPv6, TCP IPv4, UDP IPv6, UDP IPv4); the nfqueue-helper service directs the incoming connections to the appropriate socket. |
Incoming connections are first received by the vela-nfqueue-helper service, which is actually a client module connected to the libnetfilter-queue kernel framework. The nfqueue-helper determines the source and destination zones of the connection, and then tries to find a suitable firewall rule. If the rule points to a packet filtering service, the connection is processed according to Procedure 1.2.1, Handling packet filtering services; if it points to an application-level service, the connection is processed according to Procedure 1.2.2, Handling application-level services. If no suitable rule is found, the connection is rejected.
PNS generates a session ID and creates a CONNTRACK entry for the connection. This ID is based on all relevant information about the connection, including the protocol (TCP/UDP) and the client's address.
The session ID uniquely identifies the connection and is included in every log message related to this particular connection.
Based on the parameters of the connection, the Rule selects the service that will inspect the connection.
The Router defined in the service determines the destination address of the server.
The Router performs the following actions:
Determines the destination address of the server.
Sets the source address of the server-side connection, according to the forge_address
settings
of the router.
If the client is permitted to access the selected service, the packet filter is instructed to let the connection pass PNS.
Network address translation (NAT) on the connection is also performed by the packet filter, if needed.
For incoming connection requests that are processed on the application level, the main PNS thread establishes the connection with the client. The connection is further processed in a separate thread; the main thread is listening for new connections.
The Dispatcher creates the MasterSession object of the connection and generates the base session ID. This object stores all relevant information of the connection, including the protocol (TCP/UDP) and the client's address.
The session ID uniquely identifies the connection and is included in every log message related to this particular connection. Other components of PNS add further digits to the session ID.
For TCP-based connections, PNS copies the Type of Service (ToS) value of the client-PNS connection in the PNS-client connection.
The Rule selects the service that will inspect the connection.
The Router defined in the service determines the destination address of the server. The result is stored in the Session object, where the Chainer can access it later.
The Router performs the following actions:
Determines the destination address of the server.
Sets the source address of the server-side connection (according to the
forge_port
, forge_address
settings
of the router).
Sets the ToS value of the server-side connection.
If the client is permitted to access the selected service, the
startInstance()
method of the service is started. The
startInstance()
method performs the following actions:
Verifies that the new instance does not exceed the number of instances
permitted for the service (max_instances
parameter).
Creates the final session ID.
Creates an instance of the proxy class associated with the service. This proxy instance is associated with a StackedSession object. The startup of the proxy is detailed in Procedure 1.3, Proxy startup and the server-side connection.
To create an instance of the application-level proxy, the
__init__
constructor of the proxy class calls the Proxy.__init__
function of the Proxy module. The proxy
instance is created into a new thread from the PNSProxy ancestor class.
From the new thread, the proxy loads its configuration.
The proxy initiates connection to the server.
Note |
---|
Some proxies connect the server only after receiving the first client request. |
The Proxy.connectServer() method creates the server-side connection using the Chainer assigned to the service. The Chainer performs the following actions:
Reads the parameters related to the server-side connection from the Session object. These parameters were set by the Router and the Proxy.
Performs source and destination network address translation. This may modify the addresses set by the Router and the Proxy.
Verifies that access to the server is permitted.
Establishes the connection using the Attach subsystem, and passes to the proxy the stream that represents the connection.
Note |
---|
The Proxy.connectServer() method connects stacked proxies with their parent proxies. |
This chapter describes how PNS proxies work in general, and how to configure them.
For the details on configuring TLS/SSL connections, see Chapter 2, Configuring PNS proxies.
For a complete reference of the available PNS proxies, see Chapter 4, Proxies.
PNS offers great flexibility in proxy customization. Requests and commands, responses, headers, etc. can be managed individually in PNS. This means that it is not only possible to enable/disable them one-by-one, but custom actions can be assigned to them as well. The available options are listed in the description of each proxy, but the general guidelines are discussed here.
All important events of a protocol have an associated policy hash: usually there is one for the requests or commands and one for the responses. Where applicable for a protocol, there are other policy hashes defined as well (e.g., for controlling the capabilities available in the IMAP protocol, etc.). The entries of the hash are the possible events of the protocol (e.g., the request hash of the FTP protocol contains the possible commands - RMD, DELE, etc.) and an action associated with the event - what PNS should do when this event occurs. The available actions may slightly vary depending on the exact protocol and the hash, but usually they are the following:
Action | Description |
---|---|
ACCEPT | Enable the event; the command/response/etc. can be used and is allowed through the firewall. |
REJECT | Reject the event and send an error message. The event is blocked and the client notified. The communication can continue, the connection is not closed. |
DROP | Reject the event without sending an error message. The event is blocked but the client is not notified. The communication can continue, the connection is not closed. In some cases (depending on the protocol) this action is able to remove only a part of the message (e.g., a particular header in HTTP traffic) without rejecting the entire message. |
ABORT | Reject the event and terminate the connection. |
POLICY | Call a Python function to make a decision about the event. The final decision must be one of the above actions (i.e. POLICY is not allowed). The parameters received by the function are listed in the module descriptions. See the examples below and in the module descriptions for details. |
Table 2.1. Action codes for protocol events
The use of the policy hashes and the action codes is illustrated in the following examples.
It must be noted that there is a difference between how PNS processes the POLICY actions and all the other ones (e.g., ACCEPT, DROP, etc.). POLICY actions are evaluated on the policy (or Python) level of PNS, while the other ones on the proxy (or C) level. Since the proxies of PNS are written in C, and operate on the proxy level, the evaluation of POLICY actions is slightly slower, but this can be an issue only in very high-throughput environments with complex policy settings.
Default actions for all events of a hash (e.g., all requests) can be set using the '*' wildcard as the event. (Most hashes have default actions configured by default, these can be found in the description of the proxy classes.) It is important to note that setting the action using the '*' wildcard does NOT override an action explicitly defined for an event, even if the explicit setting precedes the general one in the Python code. This feature is illustrated in the example below.
Warning |
---|
If the relevant hash does not contain a received request or response, the '*' entry is used which matches to every request/response. If there is no '*' entry in the given hash, the request/response is denied. |
Responses in certain protocols include numeric response codes, e.g., in the FTP protocol responses start with a three-digit code. In PNS it is possible to filter these codes as well, furthermore, to filter them based on the command to which the response arrives to. In these cases the hash contains both the command and the answer, and an action as well. The '*' wildcard character can be used to match for every command or response code.
It is not necessary to specify the full response code, it is also possible to specify only the first, or the first two digits.
For example, all three response codes presented below are valid, but have different effects:
"PWD","200"
Match exactly the answer 200 coming in a reply to a PWD command.
"PWD","2"
Match every answer starting with '2' in a reply to a PWD command.
"*","20"
Match every answer between 200 and 209 in a reply to any command.
This kind of response code lookup is available in the following proxies: FTP, HTTP, and SMTP. The precedence how the hash table entries are processed is the following:
Exact match. ("PWD","200")
Exact command match, partial response matches ("PWD","20"; "PWD","2"; "PWD","*")
Wildcard command, with answer codes repeated as above. ("*","200"; "*","20"; "*","2")
Wildcard for both indexes. ("*","*")
Certain proxies support the use of secondary sessions, i.e. several sessions using the same proxy instance (the same thread), effectively reusing proxy instances. As new sessions enter the proxy via a fastpath, using secondary sessions can significantly decrease the load on the firewall.
When a new connection is accepted, PNS looks for the appropriate proxy instance which is willing to accept secondary sessions. If there is none, a new proxy instance is started. An already running proxy instance is appropriate if it is willing to accept secondary channels and the criteria about secondary sessions are met. (The criteria can be specified in the configuration of the proxy class.)
The criteria are set via the secondary_mask
attribute, while
the number of secondary sessions allowed within the same instance is controlled by the
secondary_sessions
attribute. The
secondary_mask
attribute is an integer specifying which properties
of an established session are considered to be important. If all important properties
match, the connection can be handled as a secondary session by a proxy instance accepting
secondary sessions, provided the new session does not exceed the limit set in
secondary_sessions
. The secondary_mask
attribute is actually a bitfield interpreted as follows: bit 0 means source address; bit 1
means source port; bit 2 means destination address; bit 3 means destination port.
Currently the Plug, RADIUS, and Sip proxies support the use of secondary sessions.
Each protocol proxy available in PNS inspects the traffic for conformance to the given protocol. Often further analysis of the data transferred via the protocol is required, this can be accomplished via stacking. Stacking is a method when the data transferred in the protocol is passed to another proxy or program. After performing the inspection, the stacked proxy or program returns the data to the original proxy, which resumes its transmission.
Proxy stacking is mainly used to inspect embedded protocols, or perform virus filtering: e.g., to inspect the parts of e-mail messages, the mail transport protocol is examined with an Smtp proxy, and then a MIME proxy is stacked to inspect MIME-formatted mail messages. It is possible to stack several layers of proxies into each other if needed, e.g., in the above example, a further virus filtering solution (like a CF module) could be stacked into the MIME proxy.
Note |
---|
Every proxy is able to handle SSL/TLS-encypted connection on its own. This feature greatly decreases the need of proxy stacking, making it needed only in special cases, for example, to inspect HTTP traffic tunneled in SSH. |
Stacking a proxy to inspect the embedded protocol is possible via the
self.request_stack
attribute; if another attribute has to be
used, it is noted in the description of the given proxy. The HTTP proxy is special in
the sense that it is possible to stack different proxies into the requests and the
responses.
The parameters of the stack attribute has to specify the following:
The protocol elements for which embedded inspection is required. This parameter can be used to specify if all received data should be passed to the stacked proxy ("*"), or only the data related (sent or received) to specific protocol elements (e.g., only the data received with a GET request in HTTP).
The mode how the data is passed to the stacked proxy. This parameter governs if only the data part should be passed to the stacked proxy (XXXX_STK_DATA, where XXXX depends on the protocol), or (if applicable) MIME header information should be included as well (XXXX_STK_MIME) to make it possible to process the data body as a MIME envelope. Please note that while it is possible to change the data part in the stacked proxy, it is not possible to change the MIME headers - they can be modified only by the upper level proxy. The available constants are listed in the respective protocol descriptions. The default value for this argument is XXXX_STK_NONE, meaning that no data is transferred to the stacked proxy. In some proxies it is also possible to call a function (using the XXXX_STK_POLICY action) to decide which part (if any) of the traffic should be passed to the stacked proxy.
The proxy class that will perform inspection of the embedded protocol.
For additional information on proxy stacking, see Section 6.6.3, Analyzing embedded traffic in Proxedo Network Security Suite 2 Administrator Guide, and the various tutorials available at the BalaSys Documentation Page.
When stacking a program, the data received by a proxy within a protocol is directed to the standard input. Arbitrary commands (including command line scripts, or applications) working from the standard input can be run on this data stream. The original proxy obtains the processed data back from the standard output. When stacking a command, the command to be called has to be included in the proper stack attribute of the proxy between double-quotes. This is illustrated in the following example.
This chapter describes the SSL protocol and the SSL framework available for every Application-level Gateway proxy.
Secure Socket Layer v3 (SSL) and Transport Layer Security v1 (TLS) are widely used crypto protocols guaranteeing data integrity and confidentiality in many PKI and e-commerce systems. They allow both the client and the server to authenticate each other. SSL/TLS use a reliable TCP connection for data transmission and cooperate with any application-level protocol. SSL/TLS guarantee that:
Communication in the channel is private, only the other communicating party can decrypt the messages.
The channel is authenticated, so the client can make sure that it communicates with the right server. Optionally, the server can also authenticate the client. Authentication is performed via certificates issued by a Certificate Authority (CA). Certificates identify the owner of an encryption keypair used in encrypted communication.
The channel is reliable, which is ensured by message integrity verification using MAC.
SSL/TLS is almost never used in itself: it is used as a secure channel to transfer other, less secure protocols. The protocols most commonly embedded into SSL/TLS are HTTP and POP3 (i.e. these are the HTTPS and POP3S protocols).
As an initial step, both the client and the server collect information to start the encrypted communication.
The client sends a CLIENT-HELLO message.
The server answers with a SERVER-HELLO message containing the certificate of the server. At this point the parties determine if a new master key is needed.
Note |
---|
The server stores information (including the session ID and other parameters) about past SSL/TLS sessions in its session cache. Clients that have contacted a particular server previously can request to continue a session (by identifying its session ID); this can be used to accelerate the initialization of the connection. Application-level Gateway currently does not support this feature, but this does not cause any noticeable difference to the clients. |
The client verifies the server's certificate. If the certificate is invalid the client sends an ERROR message to the server.
Note |
---|
If a new master key is needed the client gets the server certificate from the SERVER-HELLO message and generates a master key, sending it to the server in a CLIENT-MASTER-KEY message. |
The server sends a SERVER-VERIFY message, which authenticates the server itself.
Optionally, the server can also authenticate the client by requesting the client's certificate with a REQUEST-CERTIFICATE message.
The server verifies the certificate received from the client and finishes the handshake with a SERVER-FINISH message.
Note |
---|
In SSL two separate session keys are used, one for outgoing communication (which is of course incoming at the other end), and another key for incoming communication. These are known as SERVER/CLIENT-READ-KEY and SERVER/CLIENT-WRITE-KEY. |
PNS has a common framework that allows every Application-level Gateway proxy to use SSL/TLS encryption, and - in some cases - also supports STARTTLS.
Note |
---|
Currently, the following proxies support STARTTLS: Ftp proxy (to start FTPS sessions), Smtp proxy. |
The SSL framework inspects SSL/TLS connections, and also any other connections embedded into the encrypted SSL/TLS channel. SSL/TLS connections initiated from the client are terminated on the firewall, and two separate SSL/TLS connections are built: one between the client and the firewall, and one between the firewall and the server. If both connections match the configuration settings of Application-level Gateway (for example, the certificates are valid, and only the allowed encryption algorithms are used), Application-level Gateway inspects the protocol embedded into the secure channel as well. Note that the configuration settings can be different for the two connections, for example, it is possible to permit different protocol versions and encryption settings.
When a firewall rule matches an incoming connection, Application-level Gateway starts the Service specified in the firewall rule to inspect the connection. The Encryption policy set in the Service determines the encryption settings used in the connection.
For the details of the attributes related to the SSL framework, see Section 5.5, Module Encryption.
Several configuration examples and considerations are discussed in the Technical White Paper and Tutorial Proxying secure channels - the Secure Socket Layer, available at the BalaSys Documentation Page.
Depending on the scenario (TwoSidedEncryption, ClientOnlyEncryption, and so on) set in the Encryption policy, the SSL framework selects the first peer to perform the SSL handshake with.
As part of the handshake process, Application-level Gateway checks if encryption is required on the given side. It is not necessary for SSL to be enabled on both sides - Application-level Gateway can handle one-sided SSL connections as well (for example, the firewall communicates in an unencrypted channel with the client, but in a secure channel with the server). If SSL is not enabled, the handshake is skipped for that side.
When SSL is needed, the Service collects the required parameters (keys, certificates, and so on) from the Encryption policy.
The SSL handshake is slightly different for the client (in this case Application-level Gateway behaves as an SSL server) and the server (when Application-level Gateway behaves as an SSL client):
Client-side (SSL server) behavior. In the client-side connection Application-level Gateway acts as an SSL server, and shows the client a certificate.
If peer authentication is enabled (that is, the required
and trust_level
attributes of the verifier used in the Encryption policy is properly set), Application-level Gateway sends a list of trusted CAs to the client. If the client returns a certificate, Application-level Gateway verifies it against the trusted CA list and their associated revocation lists, and also checks the validity of the certificate.
Server-side (SSL client) behavior. The server-side handshake is similar to the client-side handshake only the order of certificate verification is different. On the server side, Application-level Gateway verifies the server's certificate first, and then sends its own certificate for verification.
Starting with version 6.0, PNS supports session reuse in SSL and TLS connections. PNS supports both session identifiers (RFC 8446) and session tickets (RFC 8446). Note that session tickets can be used only in TLS connections. Unless explicitly disabled in the configuration of the Encryption policy (for details, see Section 5.5, Module Encryption), PNS attempts to use session tickets, and automatically falls back to using session identifiers if needed.
This section describes the configuration blocks of Encryption policies and objects used in Encryption policies. Encryption policies were designed to be flexible, and make encryption settings easy to reuse in different services.
An Encryption policy is an object that has a unique name, and references a fully-configured encryption scenario.
Encryption scenarios are actually Python classes that describe how encryption is used in a particular connection, for example, both the server-side and the client-side connection is encrypted, or the connection uses a one-sided SSL connection, and so on. Encryption scenarios also reference other classes that contain the actual settings for the scenario. Depending on the scenario, the following classes can be set for the client-side, the server-side, or both.
Certificate generator: It creates or loads an X.509 certificate that Application-level Gateway shows to the peer. The certificate can be a simple certificate (Section 5.5.23, Class StaticCertificate), a dynamically generated certificate (for example, used in a keybridging scenario, Section 5.5.12, Class DynamicCertificate), or a list of certificates to support Server Name Indication (SNI, Section 5.5.18, Class SNIBasedCertificate).
The related parameters are: client_certificate_generator
, server_certificate_generator
Certificate verifier: The settings in this class determine if Application-level Gateway requests a certificate of the peer and the way to verify it. Application-level Gateway has separate built-in classes for the client-side and the server-side verification settings: Section 5.5.6, Class ClientCertificateVerifier and Section 5.5.19, Class ServerCertificateVerifier. For details and examples, see Section 3.2.5, Certificate verification options.
The related parameters are: client_verify
, server_verify
Protocol settings: The settings in this class determine the protocol-level settings of the SSL/TLS connection, for example, the permitted ciphers and protocol versions, session-reuse settings, and so on. Application-level Gateway has separate built-in classes for the client-side and the server-side SSL/TLS settings: Section 5.5.10, Class ClientTLSOptions and Section 5.5.22, Class ServerTLSOptions. For details and examples, see Section 3.2.6, Protocol-level TLS settings.
The related parameters are: client_tls_options
, server_tls_options
Application-level Gateway provides the following built-in encryption scenarios:
Application-level Gateway and the Application-level Gateway-server connections are encrypted. For details, see Section 5.5.25, Class TwoSidedEncryption.
: Both the client-Application-level Gateway connection is encrypted, the Application-level Gateway-server connection is not. For details, see Section 5.5.8, Class ClientOnlyEncryption.
: Only the client-Application-level Gateway-server connection is encrypted, the client-Application-level Gateway connection is not. For details, see Section 5.5.21, Class ServerOnlyEncryption.
: Only theFor example, on configuring Encryption policies, see How to configure TLS proxying in PNS 2. For details on HTTPS-specific problems and the related solutions, see How to configure HTTPS proxying in PNS 2.
To configure Encryption policies, you have to create an Encryption policy, and derive and configure your own scenario from the available built-in scenarios. To configure a scenario, you have to derive and configure your own certificate generator, certificate verifier, and protocol settings classes. (Do not change the built-in classes directly, because that changes the default behavior of Application-level Gateway, and can have unexpected and unwanted effects on the configuration of Application-level Gateway.)
Note |
---|
If the built-in scenarios do not cover your particular use-case, derive an own class from TwoSidedEncryption, and configure it to suit your needs. |
For a details on configuring Encryption Policies, see the following procedure, or the How to configure TLS proxying in PNS 2 tutorial.
Purpose:
To proxy HTTPS connections, configure an Encryption Policy to handle TLS connections, and use this Encryption Policy in your Service. The policy will be configured to:
Require the client and the server to use strong encryption algorithms, the use of weak algorithms will not be permitted.
Enable connections only to servers with certificates signed by CAs that are in the trusted CAs list of the PNS firewall node. (For details on managing trusted CA groups, see Section 11.3.7.3, Managing trusted groups in Proxedo Network Security Suite 2 Administrator Guide.)
The clients will only see the certificate of PNS. To allow the clients to access the certificate information of the server, see Procedure 2.2, Configuring keybridging in How to configure TLS proxying in PNS 2.
Steps:
Generate a certificate for your firewall. The Application-level Gateway component requires its own certificate and keypair to perform TLS proxying.
MC: Create a certificate, set the firewall as the owner host of the certificate, then distribute it to the firewall host. For details, see Chapter 11, Key and certificate management in PNS in Proxedo Network Security Suite 2 Administrator Guide.
Python: In configurations managed manually from python, create an X.509 certificate (with its related keypair) using a suitable software and deploy it to the PNS firewall host (for example, copy it to the /etc/key.d/mycert
folder).
Create and configure an Encryption Policy. Complete the following steps.
Navigate to the MC component of the firewall host.
Select
.Enter a name into the MyTLSEncryption
.
Select
, then click OK.Select
.Python:
EncryptionPolicy( name="MyTLSEncryption", encryption=TwoSidedEncryption() )
Double-click
, then select .Double-click the
and click to add a certificate entry to a list of certificates.Double-click the Application-level Gateway is required to show to the clients (for example, the certificate created in Step 1), then click .
. A window displaying the certificates owned by the host will open up. The lower section of the window shows the information contained in the certificate. Select the list of certificatesPython:
encryption=TwoSidedEncryption( client_certificate_generator=StaticCertificate( certificates=( Certificate.fromFile( certificate_file_path="/etc/key.d/VMS_Engine/cert.pem", private_key=PrivateKey.fromFile( "/etc/key.d/VMS_Engine/key.pem") ), ) ) )
If the private key of the certificate is password-protected, double-click
, type the password, then click OK. Otherwise, click OK.Disable mutual authentication. That way, Application-level Gateway will not request a certificate from the clients.
Double-click
, select , then click OK.Python:
encryption=TwoSidedEncryption( client_verify=None )
Specify the directory containing the certificates of the trusted CAs. These settings determine which servers can the clients access: the clients will be able to connect only those servers via TLS which have certificate signed by one of these CAs (or a lower level CA in the CA chain).
Double-click /etc/ca.d/certs/
. Click OK.
Python:
encryption=TwoSidedEncryption( server_verify=ServerCertificateVerifier( verify_ca_directory="/etc/ca.d/certs/" ) )
Note |
---|
CAs cannot be referenced directly, only the trusted group containing them. For details on managing trusted groups, see Section 11.3.7.3, Managing trusted groups in Proxedo Network Security Suite 2 Administrator Guide. |
Specify the directory containing the CRLs of the trusted CAs.
Double-click /etc/ca.d/crls/
. Click OK.
Python:
encryption=TwoSidedEncryption( server_verify=ServerCertificateVerifier( verify_ca_directory="/etc/ca.d/certs/", verify_crl_directory="/etc/ca.d/crls/" )verify_ )
Optional Step: The Common Name in the certificate of a server or webpage is usually its domain name or URL. By default, Application-level Gateway compares this Common Name to the actual domain name it receives from the server, and rejects the connection if they do not match. That way it is possible to detect several types of false certificates and prevent a number of phishing attacks. If this mode of operation interferes with your environment, and you cannot use certificates that have proper Common Names, disable this option.
Double-click FALSE
, then click OK.
Python:
encryption=TwoSidedEncryption( server_verify=ServerCertificateVerifier( verify_ca_directory="/etc/ca.d/certs/", verify_crl_directory="/etc/ca.d/crls/", check_subject=FALSE ) )
Optional Step: Forbid the use of weak encryption algorithms to increase security. The related parameters can be set separately for the client and the server-side of Application-level Gateway, using the and parameters of the Encryption Policy. Disabling weak algorithms also eliminates the risk of downgrade attacks, where the attacker modifies the TLS session-initiation messages to force using weak encryption that can be easily decrypted by a third party.
Note |
---|
Certain outdated operating systems, or old browser applications do not properly support strong encryption algorithms. If your clients use such systems or applications, it might be required to permit weak encryption algorithms. |
Optional Step: Enable untrusted certificates. Since a significant number of servers use self-signed certificates (with unverifiable trustworthiness), in certain situations it might be needed to permit access to servers that have untrusted certificates.
Note |
---|
When an untrusted certificate is accepted, the generated certificates will be signed with the untrusted CA during keybridge scenarios. For details on configuring keybridging, see Procedure 2.2, Configuring keybridging in How to configure TLS proxying in PNS 2 |
Double-click UNTRUSTED
, then click OK.
Note |
---|
When the |
Python:
encryption=TwoSidedEncryption( server_verify=ServerCertificateVerifier( trust_level=TLS_TRUST_LEVEL_UNTRUSTED ) )
Python:
The Encryption Policy configured in the previous steps is summarized in the following code snippet.
EncryptionPolicy( name="MyTLSEncryption", encryption=TwoSidedEncryption( client_verify=ClientNoneVerifier(), client_tls_options=ClientTLSOptions(), server_verify=ServerCertificateVerifier( trust_level=TLS_TRUST_LEVEL_FULL, intermediate_revocation_check_type = TLS_INTERMEDIATE_REVOCATION_SOFT_FAIL, leaf_revocation_check_type = TLS_LEAF_REVOCATION_SOFT_FAIL, trusted_certs_directory="", verify_depth=4, verify_ca_directory="/etc/ca.d/certs/", verify_crl_directory="/etc/ca.d/crls/", check_subject=TRUE ), server_tls_options=ServerTLSOptions(), client_certificate_generator=StaticCertificate( certificates=( Certificate.fromFile( certificate_file_path= "/etc/key.d/VMS_Engine/cert.chain.pem", private_key=PrivateKey.fromFile( "/etc/key.d/VMS_Engine/key.pem")), )) ))
Select
.Note when managing PNS without MC, copy the certificates and CRLs to their respective directories. They are not updated automatically as in configurations managed by MC.
By performing the above steps, the proxy has been configured to use the specified certificate and its private key, and also the directory has been set that will store the certificates of the trusted CAs and their CRLs. Client authentication has also been disabled.
Create a service that clients can use to access the Internet in a secure channel. This service will use the MyTLSEncryption
Encryption Policy.
Select intra_HTTPS_inter
), then click OK.
Select
.Select
.Configure the other parameters of the service as neecessary for the environment, then click
.Select Section 6.5, Configuring firewall rules in Proxedo Network Security Suite 2 Administrator Guide.
, and select the service created in the previous step. For more details on creating firewall rules, seeConfigure the other parameters of the rule as necessary for the environment, then click
.Python:
def demo() : Service( name='demo/intra_HTTPS_inter', router=TransparentRouter(), chainer=ConnectChainer(), proxy_class=HttpProxy, max_instances=0, max_sessions=0, keepalive=V_KEEPALIVE_NONE, encryption_policy="MyTLSEncryption" ) Rule( rule_id=300, src_subnet=('192.168.1.1/32', ), dst_zone=('internet', ), proto=6, service='demo/intra_HTTPS_inter' )
Commit and upload the changes, then restart Application-level Gateway.
Expected result:
Every time a client connects to a server, Application-level Gateway checks the certificate of the server. If the signer CA is trusted, Application-level Gateway shows a trusted certificate to the client (browser or other application). If the certificate of the server is untrusted, Application-level Gateway shows an untrusted certificate to the client, giving a warning to the user. The user can then decide whether the certificate can be accepted or not.
Application-level Gateway is able to automatically verify the certificates received.
When checking revocation state for certificate chains Application-level Gateway offers two options:
leaf verification: When enabled, leaf revocation check performs both CRL and OCSP staple checking.
non-leaf verification: Non-leaf revocation check performs CRL checking.
To support both maximum security verification and the more common use-cases with less strict scenarios, the level of strictness for the verification can be configured separately for leaf and for non-leaf certificates. The configuration is done in encryption policies using options intermediate_revocation_check_type
and leaf_revocation_check_type
.
For both intermediate_revocation_check_type
and leaf_revocation_check_type
options 3 values are available:
NONE: no revocation check is done
HARD_FAIL: revocation check is performed with strict rules. No uncertainty is tolerated, the certificate must have up-to-date and authentic information about a status not being revoked. Otherwise the certificate is rejected by the policy.
SOFT_FAIL: revocation check is performed, however, the information is not verified, and the failure to get revocation information is tolerated. If any available information states that the certificate is revoked, the certificate is rejected, otherwise the connection can be established.
intermediate_revocation_check_type
also controls the chain verifier behavior of OCSP stapling.
If no CRL list from the intermediate CA is available, the OCSP stapling signer's 'certification revoked' state cannot be determined.
If intermediate_revocation_check_type
has the HARD_FAIL value, the OCSP stapling message is not accepted as a valid
revocation information. However, if the OCSP stapling message shows 'revoked state' the message is considered regardless of its chain verification.
The following tables describe how the values, that is NONE, HARD_FAIL or SOFT_FAIL influence the result of the revocation check type:
CRL result | OCSP stapling result | SOFT_FAIL evaluates the results as: | HARD_FAIL evaluates the results as: |
---|---|---|---|
GOOD | GOOD | ACCEPT | ACCEPT |
GOOD | UNKNOWN | ACCEPT | ACCEPT |
UNKNOWN | GOOD | ACCEPT | ACCEPT |
UNKNOWN | UNKNOWN | ACCEPT | DENY |
GOOD | REVOKED | DENY | DENY |
REVOKED | GOOD | DENY | DENY |
UNKNOWN | REVOKED | DENY | DENY |
REVOKED | UNKNOWN | DENY | DENY |
REVOKED | REVOKED | DENY | DENY |
Table 3.1. Evaluation logic for leaf revocation check type
CRL result | SOFT_FAIL evaluates the results as: | HARD_FAIL evaluates the results as: |
---|---|---|
GOOD | ACCEPT | ACCEPT |
UNKNOWN | ACCEPT | DENY |
REVOKED | DENY | DENY |
Table 3.2. Evaluation logic for non-leaf revocation check type
The types of accepted certificates can be controlled separately on the client and the server side using the attributes of the ClientCertificateVerifier and ServerCertificateVerifier classes (or your own classes derived from these), respectively.
By default (if the check_subject
parameter is set to TRUE
in the verifier), Application-level Gateway compares the domain name provided in the Subject
field of the server certificate to application-level information about the server (that is, the domain name of the URL in HTTP and HTTPS connections).
The following sections describe and show examples to common protocol-level TLS settings.
The cipher algorithms used for key exchange and mass symmetric encryption are specified by the cipher
attribute of the class referred in the client_tls_options
or server_tls_options
of the Encryption policy. These attributes contain a cipher specification as specified by the OpenSSL manuals, see the manual page ciphers(ssl) for further details.
The default set of ciphers can be set by using the following predefined variables.
Name | Value |
---|---|
TLS_CIPHERS_DEFAULT | n/a |
TLS_CIPHERS_OLD | n/a |
TLS_CIPHERS_CUSTOM | n/a |
Table 3.3. Constants for cipher selection
Cipher specifications as defined above are sorted by key length. The cipher providing the best key length will be the most preferred.
Application-level Gateway supports the STARTTLS method for encrypting connections. STARTTLS support can be configured separately for the client- and server side. Currently, the following proxies support STARTTLS: Ftp proxy (to start FTPS sessions), Smtp proxy.
STARTTLS is enabled by default in the following encryption scenarios:
ClientOnlyStartTLSEncryption: STARTTLS is enabled on the client-side, but the server-side connection will not be encrypted.
FakeStartTLSEncryption: STARTTLS is enabled on the client-side, the server-side connection is always encrypted.
ForwardStartTLSEncryption: STARTTLS is enabled on the client-side, and Application-level Gateway forwards the request to the server.
Purpose:
Keybridging is a method to let the client see a copy of the server's certificate (or vice versa). That way the client can inspect the certificate of the server, and decide about its trustworthiness. If the PNS firewall is proxying the TLS connection, the client cannot inspect the certificate of the server directly, but you can configure Application-level Gateway to generate a new certificate on-the-fly, using the data in the server's certificate. Application-level Gateway sends this generated certificate to the client. To configure to perform keybridging, complete the following steps.
Steps:
Create the required keys and CA certificates.
Generate two local CA certificates. Application-level Gateway will use one of them to sign the generated certificate for servers having trusted certificates, the other one for servers with untrusted or self-signed certificates. Make this difference visible somewhere in the CA's certificates, for example, in their common name (CA_for_Untrusted_certs
; CA_for_Trusted_certs
). These CA certificates can be self-signed, or signed by your local root CA.
IMPORTANT: Do NOT set a password for these CAs, as Application-level Gateway must be able to access them automatically.
Import the certificate of the CA signing the trusted certificates to your clients to make the generated certificates 'trusted'.
IMPORTANT: Do NOT import the other CA certificate.
Generate a new certificate. The private key of this keypair will be used in the on-the-fly generated certificates, the public part (DN and similar information) will not be used.
In MC, set the PNS firewall host to be the owner of this certificate, then select .
Python:
Copy the certificates and CRLs to their respective directories (for example, into /etc/vela/tls-bridge/
). Note that they are not updated automatically as in configurations managed by MC.
Create and configure an Encryption Policy. Complete the following steps.
Navigate to the MC component of the firewall host.
Select
.Enter a name into the KeybridgingEncryption
.
Select
, then click OK.Select
.Python:
EncryptionPolicy( name="KeybridgingEncryption", encryption=TwoSidedEncryption() )
Double-click
, then select .Python:
encryption=TwoSidedEncryption( client_certificate_generator=DynamicCertificate() )
Double-click MC will automatically fill the value of the parameter to point to the location of the private key file of the certificate.
. The certificates owned by the host will be displayed. Select the one you created in Step 1c, then click OK.If the private key of the certificate is password-protected, double-click passphrase
, then enter the passphrase for the private key.
Python:
encryption=TwoSidedEncryption( client_certificate_generator=DynamicCertificate( private_key=PrivateKey.fromFile(key_file_path="/etc/key.d/TLS-bridge/key.pem") ) )
Double-click trusted_ca_files > certificate_file_path
, select CA that will be used to sign the generated certificates for trusted peers (for example, CA_for_Trusted_certs
), then click OK.
If the private key of the certificate is password-protected, double-click private_key_password
, then enter the passphrase for the private key.
Python:
client_certificate_generator=DynamicCertificate( private_key=PrivateKey.fromFile(key_file_path="/etc/key.d/TLS-bridge/key.pem"), trusted_ca=Certificate.fromFile( certificate_file_path="/etc/ca.d/certs/CA_for_Trusted_certs.pem", private_key=PrivateKey.fromFile("/etc/ca.d/keys/CA_for_Trusted_certs.pem")) )
Double-click untrusted_ca_files
, then select CA that will be used to sign the generated certificates for untrusted peers (for example, CA_for_Untrusted_certs
).
If the private key of the certificate is password-protected, double-click private_key_password
, then enter the passphrase for the private key.
Python:
client_certificate_generator=DynamicCertificate( private_key=PrivateKey.fromFile(key_file_path="/etc/key.d/TLS-bridge/key.pem"), trusted_ca=Certificate.fromFile( certificate_file_path="/etc/ca.d/certs/CA_for_Trusted_certs.pem", private_key=PrivateKey.fromFile("/etc/ca.d/keys/CA_for_Trusted_certs.pem")), untrusted_ca=Certificate.fromFile( certificate_file_path="/etc/ca.d/certs/CA_for_Untrusted_certs.pem", private_key=PrivateKey.fromFile("/etc/ca.d/keys/CA_for_Untrusted_certs.pem")) )
Python:
The Encryption Policy configured in the previous steps is summarized in the following code snippet.
EncryptionPolicy( name="KeybridgingEncryption", encryption=TwoSidedEncryption( client_verify=ClientNoneVerifier(), client_tls_options=ClientTLSOptions(), server_verify=ServerCertificateVerifier(), server_tls_options=ServerTLSOptions(), client_certificate_generator=DynamicCertificate( private_key=PrivateKey.fromFile(key_file_path="/etc/key.d/TLS-bridge/key.pem"), trusted_ca=Certificate.fromFile( certificate_file_path="/etc/ca.d/certs/CA_for_Trusted_certs.pem", private_key=PrivateKey.fromFile("/etc/ca.d/keys/CA_for_Trusted_certs.pem")), untrusted_ca=Certificate.fromFile( certificate_file_path="/etc/ca.d/certs/CA_for_Untrusted_certs.pem", private_key=PrivateKey.fromFile("/etc/ca.d/keys/CA_for_Untrusted_certs.pem") ) ) ))
Create a service that uses the Encryption Policy created in the previous step.
Python:
def demo_instance() : Service(name='demo/intra_HTTPS_Keybridge_inter', router=TransparentRouter(), chainer=ConnectChainer(), proxy_class=HttpProxy, max_instances=0, max_sessions=0, keepalive=V_KEEPALIVE_NONE, encryption_policy="KeybridgingEncryption") Rule(rule_id=20, src_zone=('intra', ), dst_zone=('internet', ), proto=6, service='demo_instance/intra_HTTPS_Keybridge_inter' )
Configure other parameters of the Encryption Policy, service, and firewall rule as needed by your environment.
Commit and upload the changes, then restart Application-level Gateway.
Expected result:
Every time a client connects to a previously unknown server, Application-level Gateway will generate a new certificate, sign it with one of the specified CAs, and send it to the client. This new certificate will be stored under /var/lib/vela/tls-bridge
under a filename based on the original server certificate. If the signer CA is trusted, the client (browser or other application) will accept the connection. If the certificate is signed by the CA for untrusted certificates, the application will not recognize the issuer CA (since its certificate has not been imported to the client) and give a warning to the user. The user can then decide whether the certificate can be accepted or not.
(Actually, two files are stored on the firewall for each certificate: the original certificate received from the server, and the generated certificate. When a client connects to the server, the certificate provided by the server is compared to the stored one: if they do not match, a new certificate is generated. For example, this happens when the server certificate has been expired and refreshed.)
The SSL protocol, the TLS protocol, as well as the session tickets and session identifiers as methods for SSL session reuse are described in RFC 8446 in details.
The SSL protocol is described in RFC 6101 in details.
The available encryption-related classes and options are described in Section 5.5, Module Encryption.
An X.509 certificate is a public key with a subject name specified as an X.500 DN (distinguished name) signed by a certificate issuing authority (CA). X.509 certificates are represented as Python policy objects having the following attributes:
Subject of the certificate.
Issuer of the certificate (i.e. the CA that signed it).
Serial number of the certificate.
The certificate itself as a string in PEM format.
PNS uses X.509 certificates to provide a convenient and efficient way to manage and distribute certificates and keys used by the various components and proxies of the managed firewall hosts. It is mainly aimed at providing certificates required for the secure communication between the different parts of the firewall system, e.g. firewall hosts and MS engine (the actual communication is realized by agents).
Certificates of trusted CAs (and their accompanying CRLs) are used in Application-level Gateway to validate the certificates of servers accessed by the clients. The hashes and structures below are used by the various certificate-related attributes of the Application-level Gateway Encryption Policies, particularly the ones of certificate
type.
A certificate name behaves as a string, and contains a DN in the following format (also known as one-line format):
/RDN=value/RDN=value/.../RDN=value/
The word RDN stands for relative distinguished name. For example, the DN cn=Root CA, ou=CA Group, o=Foo Ltd, l=Bar, st=Foobar State, c=US
becomes /C=US/ST=Foobar State/L=Bar/O=Foo Ltd/OU=CA Group/CN=Root CA/
A certifying authority may revoke the issued certificates. A revocation means that the serial number and the revocation date is added to the list of revoked certificates. Revocations are published on a regular basis. This list is called the Certificate Revocation List, also known as CRL. A CRL always has an issuer, a date when the list was published, and the expected date of its next update.
Online Certificate Status Protocol (OCSP) stapling is an alternative to Certificate Revocation Lists (CRL) in verifying the validity of certificates. The protocol is described in details in IETF RFC 6960. It is now also possible to define to what level of strictness the encryption policies shall check the revocation status of the certificates. OCSP stapling provides a potentially faster revocation state with less traffic.
The proxy stores trusted CA certificates in a Certificate hash. This hash can be indexed by two different types. If an integer index is used, the slot specified by this value is looked up; if a string index is used, it is interpreted as a one-line DN value, and the appropriate certificate is looked up. Each slot in this hash contains an X.509 certificate.
This chapter contains reference information on all the available PNS proxies.
The sections discussing the available proxies are organized as follows. Overall introduction is followed by proxy class descriptions. Each module has an abstract class which is an interface between the policy and the proxy itself. Abstract classes are the point where the low-level attributes implemented by the proxy appear.
Each Python module contains an abstract proxy class (e.g., AbstractFtpProxy) and one or more preconfigured proxy classes derived from the abstract class (e.g., FtpProxy, FtpProxyRO, etc.). These abstract proxies are very low level classes which always require customization to operate at all, thus they are not directly usable. The preconfigured classes customize the base abstract proxy to perform actually useful functionality. These derived classes inherit all their attributes from the class they were derived from, but have some of their parameters set to default values. Consequently, they can be used for certain tasks without any (or only minimal) modification. Most default classes were derived directly from the abstract classes, but it is possible to derive a class from another derived class. In this case this new class inherits the attributes from its parent class and the abstract class as well. Abstract classes should not be used directly for configuring services in PNS, always derive an own class and modify its attributes to suit the requirements.
The description of each abstract class includes a detailed list and definition of the attributes of the proxy class. The type and default value of the attribute is also provided. Most types of the attributes (e.g., integer, string, boolean, etc.) are self-explanatory; more complicated attributes (listed as complex type) are explained in their respective description or in the general proxy behavior section of the module.
Proxy attributes can be available and modified during configuration time, run time, or
both. Configuration time attributes are set and modified when the proxy is configured,
that is, when the session starts. Run time attributes are available when the connection is
active, for example, information about the HTTP header being processed is available only
when the header is processed. Access to the attributes is indicated in the header of the
description of the attribute in the following format: availability during
configuration time : availability during run time
. The type of availability
can be read (r
) access, write (w
) access,
both, or not available (n/a
). An attribute that is available for
reading and writing during both configuration and run time is indicated as
rw:rw
, an attribute that is available only for reading during run
time is indicated as n/a:r
.
Note |
---|
Unless noted otherwise, default values related to lengths (e.g., line length, etc.) are in bytes. Timeout values are always given in milliseconds. Setting a timeout to
|
The description of every proxy class includes a list or textual description of the attributes modified relative to their parent class. The values of the other attributes are inherited from the parent class.
A number of Python code samples is provided for the proxies to illustrate both their general operation and their capabilities. Most of the proxy configurations shown in the examples can be easily reproduced using the MC graphical interface. However, some of them utilize the advanced flexibility of PNS and therefore require the use of configuration scripts written in Python. From MC these can be implemented, maintained and edited using the Class editor. (The Class editor is available under the Proxies tab of the PNS MC component. When creating a new class, click on the button under the list of available classes.)
This module defines an interface to the AnyPy proxy implementation. AnyPy is basically a Python proxy which means that the proxy behaviour is defined in Python by the administrator.
Class | Description |
---|---|
AbstractAnyPyProxy | Class encapsulating an AnyPy proxy. |
AnyPyProxy | Class encapsulating the default AnyPy proxy. |
Table 4.1. Classes of the AnyPy module
This class encapsulates AnyPy, a proxy module calling a Python function to do all of its work. It can be used for defining proxies for protocols not directly supported.
Warning |
---|
This proxy class is a basis for creating a custom proxy, and cannot be used on its own. Create a new proxy class using the AnyPyProxy as its parent, and implement the proxyThread method to handle the traffic. Your code will be running as the proxy to transmit protocol elements. When writing your code, take care and be security conscious: do not make security vulnerabilities. |
Method | Description |
---|---|
__init__(self, session) | Constructor to initialize an AnyPy instance. |
proxyThread(self) | Function called by the low-level proxy core to transfer requests. |
Table 4.2. Method summary
This constructor initializes a new AnyPy instance based on its arguments, and calls the inherited constructor.
This class encapsulates AnyPy, a proxy module calling a Python function to do all of its work. It can be used for defining proxies for protocols not directly supported.
This proxy class can only be used as a basis for creating a custom proxy and cannot be used on its own. Please create a new proxy class with the AnyPyProxy as its parent and implement the proxyThread method for handling traffic.
Your code will be running as the proxy to transmit protocol elements, you'll have to take care and be security conscious not to make security vulnerabilities.
The Ftp module defines the classes constituting the proxy for the File Transfer Protocol (FTP).
File Transfer Protocol (FTP) is a protocol to transport files via a reliable TCP connection between a client and a server. FTP uses two reliable TCP connections to transfer files: a simple TCP connection (usually referred to as the Control Channel) to transfer control information and a secondary TCP connection (usually referred to as the Data Channel) to perform the data transfer. It uses a command/response based approach, i.e. the client issues a command and the server responds with a 3-digit status code and associated status information in text format. The Data Channel can be initiated either from the client or the server; the Control Channel is always started from the client.
The client is required to authenticate itself before other commands can be issued. This is performed using the USER and PASS commands specifying username and password, respectively.
The basic protocol is as follows: the client issues a request (also called command in FTP terminology) and the server responds with the result. Both commands and responses are line based: commands are sent as complete lines starting with a keyword identifying the operation to be performed. A response spans one or more lines, each specifying the same 3-digit status code and possible explanation.
Certain commands (for example RETR, STOR or LIST) also have a data attachment which is transferred to the peer. Data attachments are transferred in a separate TCP connection. This connection is established on-demand on a random, unprivileged port when a data transfer command is issued.
Endpoint information of this data channel is exchanged via the PASV and PORT commands, or their newer equivalents (EPSV and EPRT).
The data connection can either be initiated by the client (passive mode) or the server (active mode). In passive mode (PASV or EPSV command) the server opens a listening socket and sends back the endpoint information in the PASV response. In active mode (PORT or EPRT command) the client opens a listening socket and sends its endpoint information as the argument of the PORT command. The source port of the server is usually either 20, or the port number of the Command Channel minus one.
FtpProxy is a module built for parsing commands of the Control Channel in the FTP protocol. It reads the REQUEST at the client side, parses it and - if the local security policy permits - sends it to the server. The proxy parses the arriving RESPONSES and sends them to the client if the policy permits that. FtpProxy uses a PlugProxy to transfer the data arriving in the Data Channel. The proxy is capable of manipulating commands and stacking further proxies (for example, MimeProxy) into the Data Channel. Both transparent and non-transparent modes are supported.
The default low-level proxy implementation (AbstractFtpProxy) denies all requests by default. Different commands and/or responses can be enabled by using one of the several predefined proxy classes which are suitable for most tasks. Alternatively, use of the commands can be permitted individually using different attributes. This is detailed in the following two sections.
Changing the default behavior of commands can be done by
using the hash attribute request
, indexed by the command name (e.g.: USER or PWD). There is a similar attribute for responses called response
, indexed by the command name and the response code.
The possible values of these hashes are shown in the tables below. See Section 2.1, Policies for requests and responses for details. When looking up entries of the response
attribute hash, the lookup precedence described in Section 2.1.2, Response codes is used.
Action | Description |
---|---|
FTP_REQ_ACCEPT | Allow the request to pass. |
FTP_REQ_REJECT | Reject the request with the error message specified in the second optional parameter. |
FTP_REQ_ABORT | Terminate the connection. |
Table 4.3. Action codes for commands in FTP
Action | Description |
---|---|
FTP_RSP_ACCEPT | Allow the response to pass. |
FTP_RSP_REJECT | Modify the response to a general failure with error message specified in the optional second parameter. |
FTP_RSP_ABORT | Terminate the connection. |
Table 4.4. Action codes for responses in FTP
FTP servers send the list of supported features to the clients. For example, ProFTPD supports the following features: LANG en, MDTM, UTF8, AUTH TLS, PBSZ, PROT, REST STREAM, SIZE
. The default behavior of FTP features can be changed using the hash attribute features
, indexed by the name of the feature (e.g.: UTF8 or AUTH TLS).
The possible actions are shown in the table below. See Section 2.1, Policies for requests and responses for details.
The built-in FTP proxies permit the use of every feature by default.
Action | Description |
---|---|
FTP_FEATURE_ACCEPT | Forward the availability of the feature from the server to the client. |
FTP_FEATURE_DROP | Remove the feature from the feature list sent by the server. |
FTP_FEATURE_INSERT | Add the feature into the list of available features. |
Table 4.5. Policy about enabling FTP features.
For FTPS connections to operate correctly, the FTP server and client applications must comply to the FTP Security Extensions (RFC 2228) and Securing FTP with TLS (RFC 4217) RFCs.
For FTPS connections, the AUTH TLS, PBSZ, PROT
features must be accepted. Also, STARTTLS support must be properly configured. See Section 3.2, Handling TLS and SSL connections in Application-level Gateway for details.
If the proxy is configured to disable encryption between PNS and the client, the proxy automatically removes the AUTH TLS, PBSZ, PROT
features from the list sent by the server.
If STARTTLS connections are accepted on the client side (self.tls.client_security=TLS_ACCEPT_STARTTLS
), but TLS-forwarding is disabled on the server side, the proxy automatically inserts the AUTH TLS, PBSZ, PROT
features into the list sent by the server. These features are inserted even if encryption is explicitly disabled on the server side or the server does not support the FEAT
command, making one-sided STARTTLS support feasible.
Warning |
---|
When using inband routing with the FTPS protocol, the server's certificate is compared to its hostname. The subject_alt_name parameter (or the Common Name parameter if the subject_alt_name parameter is empty) of the server's certificate must contain the hostname or the IP address (as resolved from the PNS host) of the server (e.g., Alternatively, the Common Name or the Note that if the Common Name of the certificate contains a generic hostname, do not specify a specific hostname or an IP address in the |
Note |
---|
|
The available stacking modes for this proxy module are listed in the following table. For additional information on stacking, see Section 2.3.1, Proxy stacking.
Action | Description |
---|---|
FTP_STK_DATA | Pass the data to the stacked proxy or program. |
FTP_STK_NONE | No proxy stacked. |
Table 4.6. Stacking policy.
The Ftp proxy supports inband authentication as well to use the built-in authentication method of the FTP and FTPS protocols to authenticate the client. The authentication itself is performed by the ASbackend configured for the service.
If the client uses different usernames on AS and the remote server (e.g., he uses his own username to authenticate to AS, but anonymous on the target FTP server), the client must specify the usernames and passwords in the following format:
Username:
<ftp user>@<proxy user>@<remote site>[:<port>]
Password:
<ftp password>@<proxy password>
Alternatively, all the above information can be specified as the username:
<ftp user>@<proxy user>@<remote site>[:<port>]:<ftp password>@<proxy password>
Warning |
---|
When using inband routing with the FTPS protocol, the server's certificate is compared to its hostname. The subject_alt_name parameter (or the Common Name parameter if the subject_alt_name parameter is empty) of the server's certificate must contain the hostname or the IP address (as resolved from the PNS host) of the server (e.g., Alternatively, the Common Name or the Note that if the Common Name of the certificate contains a generic hostname, do not specify a specific hostname or an IP address in the |
The File Transfer Protocol is described in RFC 959.
FTP Security Extensions including the FTPS protocol and securing FTP with TLS are described in RFC 2228 and RFC 4217.
Class | Description |
---|---|
AbstractFtpProxy | Class encapsulating the abstract FTP proxy. |
FtpProxy | Default Ftp proxy based on AbstractFtpProxy. |
FtpProxyAnonRO | FTP proxy based on AbstractFtpProxy, only allowing read-only access to anonymous users. |
FtpProxyAnonRW | FTP proxy based on AbstractFtpProxy, allowing full read-write access, but only to anonymous users. |
FtpProxyRO | FTP proxy based on AbstractFtpProxy, allowing read-only access to any user. |
FtpProxyRW | FTP proxy based on AbstractFtpProxy, allowing full read-write access to any user. |
Table 4.7. Classes of the Ftp module
This proxy implements the FTP protocol as specified in RFC 959. All traffic and commands are denied by default. Consequently, either customized Ftp proxy classes derived from the abstract class should be used, or one of the predefined classes (e.g.: FtpProxy, FtpProxyRO, etc.).
auth_tls_ok_client (boolean, n/a:r) | |
---|---|
Default: "" | |
Shows whether the client-side authentication was performed over a secure channel. |
auth_tls_ok_server (boolean, n/a:r) | |
---|---|
Default: "" | |
Shows whether the server-side authentication was performed over a secure channel. |
data_port_max (integer, rw:r) | |
---|---|
Default: 41000 | |
On the proxy side, ports equal to or below the value of data_port_max can be allocated as the data channel.
|
data_port_min (integer, rw:r) | |
---|---|
Default: 40000 | |
On the proxy side, ports equal to or above the value of data_port_min can be allocated as the data channel.
|
data_protection_enabled_client (boolean, n/a:r) | |
---|---|
Default: "" | |
Shows whether the data channel is encrypted or not on the client-side. |
data_protection_enabled_server (boolean, n/a:r) | |
---|---|
Default: "" | |
Shows whether the data channel is encrypted or not on the server-side. |
hostname (string, n/a:rw) | |
---|---|
Default: | |
The hostname of the FTP server to connect to, when inband routing is used. |
hostport (integer, n/a:rw) | |
---|---|
Default: | |
The port of the FTP server to connect to, when inband routing is used. |
max_hostname_length (integer, rw:r) | |
---|---|
Default: 128 | |
Maximum length of hostname. Used only in non-transparent mode. |
max_line_length (integer, rw:r) | |
---|---|
Default: 255 | |
Maximum length of a line that the proxy is allowed to transfer. Requests/responses exceeding this limit are dropped. |
proxy_password (string, n/a:rw) | |
---|---|
Default: | |
The password to be used for proxy authentication given by the user, when inband authentication is used. |
proxy_username (string, n/a:rw) | |
---|---|
Default: | |
The username to be used for proxy authentication given by the user, when inband authentication is used. |
request (complex, rw:rw) | |
---|---|
Default: | |
Normative policy hash for FTP requests indexed by command name (e.g.: "USER", "PWD" etc.). See also Section 2.1, Policies for requests and responses. |
request_command (string, n/a:rw) | |
---|---|
Default: n/a | |
When a request is evaluated on the policy level, this variable contains the requested command. |
request_parameter (string, n/a:rw) | |
---|---|
Default: n/a | |
When a request is evaluated on the policy level, this variable contains the parameters of the requested command. |
request_stack (complex, rw:rw) | |
---|---|
Default: | |
Hash containing the stacking policy for the FTP commands. The hash is indexed by the FTP command (e.g. RETR, STOR). See also Section 2.3.1, Proxy stacking. |
response (complex, rw:rw) | |
---|---|
Default: | |
Normative policy hash for FTP responses indexed by command name and answer code (e.g.: "USER","331"; "PWD","200" etc.). See also Section 2.1, Policies for requests and responses. |
response_parameter (string, n/a:rw) | |
---|---|
Default: | |
When a response is evaluated on the policy level, this variable contains answer parameters. |
response_status (string, n/a:rw) | |
---|---|
Default: | |
When a response is evaluated on the policy level, this variable contains the answer code. |
response_strip_msg (boolean, rw:r) | |
---|---|
Default: FALSE | |
Strip the response message and only send the response code. |
target_port_range (string, rw:r) | |
---|---|
Default: "21" | |
The port where the client can connect through a non-transparent FtpProxy. |
timeout (integer, rw:r) | |
---|---|
Default: 300000 | |
General I/O timeout in milliseconds. When there is no specific timeout for a given operation, this value is used. |
A permitting Ftp proxy based on the AbstractFtpProxy, allowing all commands, responses, and features, including unknown ones. The connection is terminated if a response with the answer code 421
is received.
FTP proxy based on AbstractFtpProxy, enabling read-only access (i.e. only downloading) to anonymous users (uploads and usernames other than 'anonymous' or 'ftp' are disabled). Commands and return codes are strictly checked, unknown commands and responses are rejected. Every feature is accepted.
The ABOR; ACCT; AUTH; CDUP; CWD; EPRT; EPSV; FEAT; LIST; MODE; MDTM; NLST; NOOP; OPTS; PASV; PASS; PORT; PWD; QUIT; REST; RETR; SIZE; STAT; STRU; SYST; TYPE; and USER commands are permitted, the CLNT; XPWD; MACB commands are rejected.
FTP proxy based on AbstractFtpProxy, enabling full read-write access to anonymous users (the 'anonymous' and 'ftp' usernames are permitted). Commands and return codes are strictly checked, unknown commands and responses are rejected. Every feature is accepted.
The ABOR; ACCT; APPE; CDUP; CWD; DELE; EPRT; EPSV; LIST; MKD; MODE; MDTM; NLST; NOOP; OPTS; PASV; PASS; PORT; PWD; QUIT; RMD; RNFR; RNTO; REST; RETR; SIZE; STAT; STOR; STOU; STRU; SYST; TYPE; USER and FEAT commands are permitted, the AUTH; CLNT; XPWD; MACB commands are rejected.
FTP proxy based on AbstractFtpProxy, enabling read-only access to any user. Commands and return codes are strictly checked, unknown commands and responses are rejected. Every feature is accepted.
The ABOR; ACCT; AUTH; CDUP; CWD; EPRT; EPSV; FEAT; LIST; MODE; MDTM; NLST; NOOP; OPTS; PASV; PASS; PORT; PWD; QUIT; REST; RETR; SIZE; STAT; STRU; SYST; TYPE; and USER commands are permitted, the CLNT; XPWD; MACB commands are rejected.
FTP proxy based on AbstractFtpProxy, enabling full read-write access to any user. Commands and return codes are strictly checked, unknown commands and responses are rejected. Every feature is accepted.
The ABOR; ACCT; AUTH; CDUP; CWD; EPRT; EPSV; FEAT; LIST; MODE; MDTM; NLST; NOOP; OPTS; PASV; PASS; PORT; PWD; QUIT; REST; RETR; SIZE; STAT; STRU; SYST; TYPE; and USER commands are permitted, the CLNT; XPWD; MACB commands are rejected.
The Http module defines the classes constituting the proxy for the HyperText Transfer Protocol (HTTP). HTTP is the protocol the Web is based on, therefore it is the most frequently used protocol on the Internet. It is used to access different kinds of content from the Web. The type of content retrieved via HTTP is not restricted, it can range from simple text files to hypertext files and multimedia formats like pictures, videos or audio files.
HTTP is an open application layer protocol for hypermedia information systems. It basically allows an open-ended set of methods to be applied to resources identified by Uniform Resource Identifiers (URIs).
HTTP is a text based protocol where a client sends a request comprising of a METHOD, an URI and associated meta information represented as MIME-like headers, and possibly a data attachment. The server responds with a status code, a set of headers, and possibly a data attachment. Earlier protocol versions perform a single transaction in a single TCP connection, HTTP/1.1 introduces persistency where a single TCP connection can be reused to perform multiple transactions.
An HTTP method is a single word - usually spelled in capitals - instructing the server to apply a function to the resource specified by the URI. Commonly used HTTP methods are "GET", "POST" and "HEAD". HTTP method names are not restricted in any way, other HTTP based protocols (such as WebDAV) add new methods to the protocol while keeping the general syntax intact.
Headers are part of both the requests and the responses. Each header consists of a name followed by a colon (':') and a field value. These headers are used to specify content-specific and protocol control information.
The response to an HTTP request starts with an HTTP status line informing the client about the result of the operation and an associated message. The result is represented by three decimal digits, the possible values are defined in the HTTP RFCs.
The protocol has three variants, differentiated by their version number. Version 0.9 is a very simple protocol which allows a simple octet-stream to be transferred without any meta information (e.g.: no headers are associated with requests or responses).
Version 1.0 introduces MIME-like headers in both requests and responses; headers are used to control both the protocol (e.g.: the "Connection" header) and to give information about the content being transferred (e.g.: the "Content-Type" header). This version has also introduced the concept of name-based virtual hosts.
Building on the success of HTTP/1.0, version 1.1 of the protocol adds persistent connections (also referred to as "connection keep-alive") and improved proxy control.
Both requests and responses might have an associated data blob, also called an entity in HTTP terminology. The size of the entity is determined using one of three different methods:
The complete size of the entity is sent as a header (the Content-Length header).
The transport layer connection is terminated when transfer of the blob is completed (used by HTTP/0.9 and might be used in HTTP/1.1 in non-persistent mode).
Instead of specifying the complete length, smaller chunks of the complete blob are transferred, and each chunk is prefixed with the size of that specific chunk. The end of the stream is denoted by a zero-length chunk. This mode is also called chunked encoding and is specified by the Transfer-Encoding header.
The default low-level proxy implementation (AbstractHttpProxy) denies all requests by default. Different requests and/or responses can be enabled by using one of the several predefined proxy classes which are suitable for most tasks. Alternatively, a custom proxy class can be derived from AbstractHttpProxy and the requests and responses enabled individually using different attributes.
Several examples and considerations on how to enable virus filtering in the HTTP traffic are discussed in the Technical White Paper and Tutorial Virus filtering in HTTP, available at the BalaSys Documentation Page.
HttpProxy is able to operate both in transparent and non-transparent mode. In transparent mode, the client does not notice (or even know) that it is communicating through a proxy. The client communicates using normal server-style requests.
In non-transparent mode, the address and the port of the proxy server must be set on the client. In this case the client sends proxy-style requests to the proxy.
In non-transparent mode it is possible to request the use of the SSL protocol through the proxy, which means the client communicates with the proxy using the HTTP protocol, but the proxy uses HTTPS to communicate with the server. This technique is called data tunneling.
Changing the default behavior of requests is possible using the
request
attribute. This hash is indexed by the HTTP method
names (e.g.: GET or POST). The response
attribute (indexed by the request method and the response code) enables the control of HTTP responses. The possible actions are described in the following tables. See also Section 2.1, Policies for requests and responses. When looking up entries of the response
attribute hash, the lookup precedence described in Section 2.1.2, Response codes is used.
Action | Description |
---|---|
HTTP_REQ_ACCEPT |
Allow the request to pass. |
HTTP_REQ_REJECT |
Reject the request. The reason for the rejection can be specified in the optional second argument. |
HTTP_REQ_ABORT |
Terminate the connection. |
HTTP_REQ_POLICY |
Call the function specified to make a decision about the event. The function receives four arguments: self, method, url, version. See Section 2.1, Policies for requests and responses for details. |
Table 4.8. Action codes for HTTP requests
Action | Description |
---|---|
HTTP_RSP_ACCEPT | Allow the response to pass. |
HTTP_RSP_DENY | Reject the response and return a policy violation page to the client. |
HTTP_RSP_REJECT | Reject the response and return a policy violation page to the client, with error information optionally specified as the second argument. |
HTTP_RSP_POLICY | Call the function specified to make a decision about the event. The function receives five parameters: self, method, url, version, response. See Section 2.1, Policies for requests and responses for details. |
Table 4.9. Action codes for HTTP responses
Both request and response headers can be modified by the proxy during
the transfer. New header lines can be inserted, entries can be modified
or deleted. To change headers in the requests and responses use the
request_header
hash or the response_header
hash, respectively.
Similarly to the request hash, these hashes are indexed by the header name (like "User-Agent") and contain an actiontuple describing the action to take.
By default, the proxy modifies only the "Host", "Connection", "Proxy-Connection" and "Transfer-Encoding" headers. "Host" headers need to be changed when the proxy modifies the URL; "(Proxy-)Connection" is changed when the proxy turns connection keep-alive on/off; "Transfer-Enconding" is changed to enable chunked encoding.
Action | Description |
---|---|
HTTP_HDR_ABORT | Terminate the connection. |
HTTP_HDR_ACCEPT | Accept the header. |
HTTP_HDR_DROP | Remove the header. |
HTTP_HDR_POLICY | Call the function specified to make a decision about the event. The function receives three parameters: self, hdr_name, and hdr_value. |
HTTP_HDR_CHANGE_NAME | Rename the header to the name specified in the second argument. |
HTTP_HDR_CHANGE_VALUE | Change the value of the header to the value specified in the second argument. |
HTTP_HDR_CHANGE_BOTH | Change both the name and value of the header to the values specified in the second and third arguments, respectively. |
HTTP_HDR_INSERT | Insert a new header defined in the second argument. |
HTTP_HDR_REPLACE | Remove all existing occurrences of a header and replace them with the one specified in the second argument. |
Table 4.10. Action codes for HTTP headers
URLs or sets of URLs can be easily rejected or redirected to a local mirror by modifying some attributes during request processing.
When an HTTP request is received, normative policy chains are processed
(self.request
, self.request_header
). Policy callbacks for certain events can be configured with the HTTP_REQ_POLICY or HTTP_HDR_POLICY directives. Any of these callbacks may change the request_url
attribute, instructing the proxy to fetch a page different from the one specified by the browser. Please note that this is transparent
to the user and does not change the URL in the browser.
PNS differentiates between two request types: server requests and proxy request.
Server requests are sent by browsers directly communicating with HTTP servers. These requests include an URL relative to the server root (e.g.: /index.html), and a 'Host' header indicating which virtual server to use.
Proxy requests are used when the browser communicates with an HTTP proxy. These requests include a fully specified URL (e.g.: http://www.example.com/index.html).
The type of the incoming request is determined from the request URL, even if the Proxy-connection header exists. As there is no clear distinction between the two request types, the type of the request cannot always be accurately detected automatically, though all common cases are covered.
Requests are handled differently in transparent and non-transparent modes.
A transparent HTTP proxy (transparent_mode
attribute is TRUE) is
meant to be installed in front of a network where clients do not
know about the presence of the firewall. In this case the proxy
expects to see server type requests only. If clients communicate
with a real HTTP proxy through the firewall, proxy type requests
must be explicitly enabled using the permit_proxy_requests
attribute, or transparent mode has to be used.
The use of non-transparent HTTP proxies (transparent_mode
attribute is FALSE) must be configured in web browsers behind
the firewall. In this case only proxy requests are expected, and
server requests are emitted (assuming parent_proxy
is not set).
Parent proxies are non-transparent HTTP proxies used behind PNS. Two things have to be set in order to use parent proxies. First,
select a router which makes the proxy connect to the
parent proxy, this can be either InbandRouter() or
DirectedRouter(). Second, set the parent_proxy
and
parent_proxy_port
attributes in the HttpProxy class. Setting
these attributes results in proxy requests to be emitted to the
target server both in transparent and non-transparent mode.
The parent proxy attributes can be set both in the configuration phase (e.g.: config() event), or later on a per-request basis. This is possible because the proxy re-connects.
In non-transparent mode it is possible to let PNS process ftp://
URLs, effectively translating HTTP requests to FTP requests on
the fly. This behaviour can be enabled by setting
permit_ftp_over_http
parameter to TRUE and adding port 21 to
target_port_range
. Currently only passive mode
transfers are supported.
There are cases when the HTTP proxy must return an error page to
the client to indicate certain error conditions. These error
messages are stored as files in the directory specified by the
error_files_directory
attribute, and can be customized by
changing the contents of the files in this directory.
Each file contains plain HTML text, but some special macros are provided to dynamically add information to the error page. The following macros can be used:
@INFO@ -- further error information as provided by the proxy
@VERSION@ -- PNS version number
@DATE@ -- current date
@HOST@ -- hostname of PNS
It is generally recommended not to display error messages to
untrusted clients, as they may leak confidential information. To
turn error messages off, set the error_silent
attribute to TRUE, or
strip error files down to a minimum.
Note |
---|
The language of the messages can be set using the |
HTTP supports stacking proxies for both request and response
entities (e.g.: data bodies). This is controlled by the
request_stack
and response_stack
attribute hashes. See also Section 2.3.1, Proxy stacking.
There are two stacking modes available: HTTP_STK_DATA sends only the data portion to the downstream proxy, while HTTP_STK_MIME also sends all header information to make it possible to process the data body as a MIME envelope. Please note that while it is possible to change the data part in the stacked proxy, it is not possible to change the MIME headers - they can be modified only by the HTTP proxy. The possible parameters are listed in the following tables.
Action | Description |
---|---|
HTTP_STK_NONE | No additional proxy is stacked into the HTTP proxy. |
HTTP_STK_DATA | The data part of the HTTP traffic is passed to the specified stacked proxy. |
HTTP_STK_MIME | The data part including header information of the HTTP traffic is passed to the specified stacked proxy. |
Table 4.11. Constants for proxy stacking
Please note that stacking is skipped altogether if there is no body in the message.
Certain webserver applications may return data entities in 205 responses. This is explicitly prohibited by the RFCs, but such responses are permitted for interoperability reasons.
HTTP proxy offers the ‘session persistence in load balancing’ feature, further enhancing load balancing capabilities by that.
With the help of this feature, the Round Robin chainer can identify connections by their session IDs and make sure that every connection with the same session ID is always addressed to the same server, so that the session persists.
For using the ‘session persistence in load balancing’ feature, the administrator has to configure the following three attributes for the HTTP proxy:
Enable_session_persistence
You can switch on or off the ‘Session persistence in load balancing’ feature with that parameter.
Session_persistence_cookie_name
This parameter can only be configured if enable_session_persistence is set to TRUE. The administrator can provide the name of the cookie here: All incoming requests are directed to a web server and each web server sends a session ID back. The name of this session ID, that is, the cookie name, can be provided here to ensure that requests with the same session ID are directed to the same web server.
Session_persistence_cookie_salt
This parameter can only be configured if enable_session_persistence is set to TRUE. The administrator can provide the salt here, with which the IP address of the web server can be hashed before the session ID. With the help of this hashed information PNS can next time identify to which server the next connection attempt of this session has to be directed.
The integrated category-based URL filtering solution maintains a permanently updated database. During the installation of the URL filtering database the administrator can choose the size of the URL filtering database. The database can be a smaller-sized, optimized database (the recommended version) for usual scenarios, which requires 1 GB storage space and 300 MB daily update traffic, or a normal database for more extensive scenarios, which requires 6 GB storage space and 2 GB daily update traffic. Note, that during the upgrade, the 6 GB storage space usage will temporarily increase to 18-20 GB.
For an overview on how URL-filtering works, see Section How URL filtering works.
For information on installing and selecting the size of the URL filter database, see Procedure 4.1.2, Configuring the pns-common package in Proxedo Network Security Suite 2 Installation Guide.
To configure URL filtering, see Section Configuring URL filtering in HTTP.
To customize or expand the URL-database, see Section Customizing the URL database.
For the list of categories available by default, see Section List of URL-filtering categories.
The PNS URL filter checks the URL of the HTTP requests and compares them to a categorized database.
The URLs and the domains in the database are organized into thematic categories like adult
,
health
, business
, and so on. If the requested URL is listed
in the database, the categories matching the URL are assigned to the request. PNS can accept, redirect,
or reject the HTTP request based on the category it belongs to.
Typically, accessing a webpage involves several HTTP requests. URL filtering is applied to every single HTTP request, meaning that different parts of the webpage can belong to different categories. PNS can remove the parts belonging to unwanted categories, and permit access only to the remaining part. For example, this can be used to prohibit access to advertisements or videos, but to permit access to other parts of the website.
Note |
---|
URL filtering is handled by the PNS Http proxy, without the need of using CF. The URL
filtering capability of PNS is available only after purchasing the Updates to the URL database are automatically downloaded daily from the BalaSys website using the vavupdate utility. |
Prior to the update to the new URL filter, it is necessary to check whether at least 1.7 GB free
space is avaialble on the partition including the /var/lib/vela/urlfilter/
folder.
Following the update, the partition will utilize close to 850 MB space.
To enable url-filtering, follow the forthcoming steps:
Choose the proper URL filter proxy under PNS component → Proxies menu item.
Edit the self.url_category under the Attribute menu item.
You can find the categories from the previous version of the URL filter under the Key menu item. These items now belong to the 'uncategorized' group category.
Click the Edit key button and the selection of the new categories will be displayed:
Choose the new category corresponding to the old one, from the list.
For the list of categories available by default, see Section List of URL-filtering categories. It is not necessary to change all the categories at once. The remaining elements will still remain as 'uncategorized' in the background.
While searching for the categories, it might be helpful to use the Ctrl + F key combination. Alternatively, when starting typing, the findings matching the first keystrokes will pop up in a list of highlights. Among these highlighted matches we can choose with the 'up' and 'down' arrows.
After pressing the commit button, validate the changes with the check configuration option.
The update of the URL filter database is performed by the vavupdate
command,
run by the cron job, every day at 11 pm by default. Use the login name and password
necessary for accessing the apt repo as well. All these ensure a solution that can be
updated more easily.
The PNS URL database contains the following thematic categories by default.
Main category | Subcategory |
---|---|
Adult |
Abortion, Abortion Pro Choice, Abortion Pro Life, Child Inappropriate, Gambling, Gay, Lesbian, Bisexual, Lingerie, Suggestive and Pinap, Nudity, Pornography, R-Rated, Sex and Erotic, Sex Education and Pregnancy, Tobacco |
Aggressive |
Military, Violence, Weapons, Aggressive - Other |
Arts |
Fine Art, Arts - Other |
Automotive |
Auto Parts, Auto Repair, Buying/Selling Cars, Car Culture, Certified Pre-Owned, Convertible, Coupe, Crossover, Diesel, Electric Vehicle, Hatchback, Hybrid, Luxury, MiniVan, Motorcycles, Off-Road Vehicles, Performance Vehicles, Pickup, Road-Side Assistance, Sedan, Trucks & Accessories, Vintage Cars, Wagon, Automotive - Other |
Business
|
Agriculture, Biotechnology, Business Software, Construction, Forestry, Government, Green Solutions & Conservation, Home & Office Furnishings, Human Resources, Manufacturing, Marketing Services, Metals, Physical Security, Productivity, Retirement Homes & Assisted Living, Shipping & Logistics,Business - Other |
Careers |
Career Advice, Career Planning, College, Financial Aid, Job Fairs, Job Search, Nursing, Resume Writing/Advice, Scholarships, Telecommuting, U.S. Military, Careers - Other |
Criminal Activities |
Child Abuse Images, Criminal Skills, Hacking, Hate Speech, Illegal Drugs, Marijuana, Piracy & Copyright Theft, School Cheating, Self Harm, Torrent Repository, Criminal Activities - Other |
Dynamic |
Anonymizer, Chat, Community Forums, Instant Messenger, Login Screens, Personal Pages & Blogs, Photo Sharing, Professional Networking, Redirect, Social Networking, Text Messaging & SMS, Translator, Web-based Email, Web-based Greeting Card |
Education |
7-12 Education, Adult Education, Art History, College Administration, College Life, Distance Learning, Educational Institutions, Educational Materials & Studies, English as a 2nd Language, Graduate School, Homeschooling, Homework/Study Tips, K-6 Educators, Language Learning, Literature & Books, Private School, Reference Materials & Maps, Special Education, Studying Business, Tutoring, Wikis, Education - Other |
Entertainment |
Entertainment News & Celebrity Sites, Entertainment Venues & Events, Humor, Movies, Music, Streaming & Downloadable Audio, Streaming & Downloadable Video, Television, Entertainment - Other |
Family and Parenting |
Adoption, Babies and Toddlers, Daycare/Pre School, Eldercare, Family Internet, Parenting - K-6 Kids, Parenting Teens, Pregnancy, Special Needs Kids, Family & Parenting - Other |
Fashion |
Accessories, Beauty, Body Art, Clothing, Fashion, Jewelry, Swimsuits, Fashion - Other |
Finance |
Accounting, Banking, Beginning Investing, Credit/Debt & Loans, Financial News, Financial Planning, Hedge Fund, Insurance, Investing, Mutual Funds, Online Financial Tools & Quotes, Options, Retirement Planning, Stocks, Tax Planning, Finance - Other |
Food and Drink |
American Cuisine, Barbecues & Grilling, Cajun/Creole, Chinese Cuisine, Cocktails/Beer, Coffee/Tea, Cuisine-Specific, Desserts & Baking, Dining Out, Food Allergies, French Cuisine, Health/Low fat Cooking, Italian Cuisine, Japanese Cuisine, Mexican Cuisine, Vegan, Vegetarian, Winer, Food & Drink - Other |
Health |
A.D.D., AIDS/HIV, Allergies, Alternative Medicine, Arthritis, Asthma, Autism/PDD, Bipolar Disorder, Brain Tumor, Cancer, Children's Health, Cholesterol, Chronic Fatigue, Chronic Pain, Cold & Flu, Cosmetic Surgery, Deafness, Dental Care, Depression, Dermatology, Diabetes, Disorders, Epilepsy, Exercise, GERD/Acid Reflux, Headaches/Migraines, Heart Disease, Herbs for Health, Holistic Healing, IBS/Crohn’s Disease, Incest/Abuse Support, Incontinence, Infertility, Men’s Health, Nutrition & Diet, Orthopedics, Panic/Anxiety, Pediatrics, Pharmaceuticals, Physical Therapy, Psychology/PsychiatrySelf-help & Addiction, Senior Health, Sexuality, Sleep Disorders, Smoking Cessation, Supplements & Compounds, Syndrome, Thyroid Disease, Weight Loss, Women’s Health, Health - Other |
Hobbies and Interests |
Art/Technology, Arts & Crafts, Beadwork, Birdwatching, Board Games/Puzzles, Candle & Soap Making, Card Games, Cartoons, Anime & Comic Books, Chess, Cigars, Collecting, Comic Books, Drawing/Sketching, Freelance Writing, Genealogy, Getting Published, Guitar, Home Recording,Investors & Patents, Jewelry Making, Magic & Illusion, Needlework, Painting, Photography, Radio, Roleplaying Games, Sci-Fi & Fantasy, Scrapbooking, Screenwriting, Stamps & Coins, Themes, Video & Computer Games, Woodworking, Hobbies & Interests - Other |
House and Garden |
Appliances, Entertaining, Environmental Safety, Gardening, Home Repair., Home Theater, Interior Decorating, Landscaping, Remodeling & Construction, Home & Garden - Other |
Kids |
Games, Kid's Pag, Toys, Kids - Other |
Lifestyle |
Dating & Relationships, Divorce Support, Ethnic Specific, Marriage, Parks, Rec Facilities & Gyms, Senior Living, Teens, Weddings, Lifestyle - Other |
Malicious |
Ad Fraud, Botnet, Command and Control Centers, Compromised & Links To Malware, Malware Call-Home, Malware Distribution Point, Phishing/Fraud, Spam URLs, Spyware & Questionable Software |
Miscellaneous |
Content Server, No Content Found, Parked & For Sale Domains, Private IP Address, Unreachable, Miscellaneous - Other |
News, Portal and Search |
Image Search, International News, Local News, Magazines, National News, Portal Sites, Search Engines, News, Portal & Search - Other |
Online Ads |
Pay-to-Surf, Online Ads - Other |
Pets |
Aquariums, Birds, Cats, Dogs, Large Animals, Reptiles, Veterinary Medicine, Pets - Other |
Public, Government and Law |
Advocacy Groups & Trade Associations, Commentary, Government Sponsored, Immigration, Legal Issues, Philanthropic Organizations, Politics, Social & Affiliation Organizations, U.S. Government Resources, Public, Government & Law - Other |
Real Estate |
Apartments, Architects, Buying/Selling Homes, Real Estate - Other |
Religion |
Alternative Religions, Atheism & Agnosticism, Buddhism, Catholicism, Christianity, Hinduism, Islam, Judaism, Latter-Day Saints, Non-traditional Religion and Occult, Pagan/Wiccan, Religion - Other |
Science |
Anatomy, Astrology and Horoscopes, Biology, Botany, Chemistry, Weather, Geography, Geology, Paranormal Phenomena, Physics, Space/Astronomy, Science - Other |
Shopping |
Auctions & Marketplaces, Catalogs, Contests & Surveys, Shopping - Online, Engines, Product Reviews & Price Comparisons, Coupons, Shopping - Other |
Sports |
Auto Racing, Baseball, Bicycling, Bodybuilding, Boxing, Canoeing/Kayaking, Cheerleading, Climbing, Cricket, Figure Skating, Fly Fishing, Football, Freshwater Fishing, Game & Fish, Golf, Horse Racing, Horses, Inline Skating, Martial Arts, Mountain Biking, NASCAR Racing, Olympics, Sports - Other, Paintball, Power & Motorcycles, Pro Basketball, Pro Ice Hockey, Rodeo, Rugby, Running/Jogging, Sailing, Saltwater Fishing, Scuba Diving, Skateboarding, Skiing, Snowboarding, Sport Hunting, Surfing/Bodyboarding, Swimming, Table Tennis/Ping-Pong, Tennis, Volleyball, Walking, Waterski/Wakeboard, World Soccer |
Technology |
3-D Graphics, Animation, Antivirus Software, C/C++, Cameras & Camcorders, Computer Certification, Computer Networking, Computer Peripherals, Computer Reviews, Databases, Desktop Publishing, Desktop Video, File Repositories, Graphics Software, Home Video/DVD, Information Security, Internet Phone & VOIP, Internet Technology, Java, Javascript, Linux, Mac OS, Technology - Other, Mac Support, Mobile Phones, MP3/MIDI, Net Conferencing, Net for Beginners, Network Security, Palmtops/PDAs, PC Support, Peer-to-Peer, Personal Storage, Portable, Entertainment, Remote Access, Shareware/Freeware, Unix, Utilities, Visual Basic, Web Clip Art, Web Design/HTML, Web Hosting, ISP & Telco, Windows, Online Information Management |
Travel |
Adventure Travel, Africa, Air Travel, Australia & New Zealand, Bed & Breakfast, Budget Travel, Business Travel, By US Locale, Camping, Canada, Caribbean, Cruises, Eastern Europe, Europe, Travel - Other, France, Greece, Honeymoons/Getaways, Hotels, Italy, Japan, Mexico & Central America, National Parks, Navigation, South America, Spas, Theme Parks, Traveling with Kids, United Kingdom |
Table 4.12. URL filter categories
Create blacklist and whitelist if necessary.
This can be achieved with the help of free text editor, on the PNS Node → New → Text
editor → URL filter black and whitelists
path.
The choices for blacklist, whitelist or * options are also put into the category list:
The Hypertext Transfer Protocol -- HTTP/1.1 protocol is described in RFC 2616.
The Hypertext Transfer Protocol -- HTTP/1.0 protocol is described in RFC 1945.
Class | Description |
---|---|
AbstractHttpProxy | Class encapsulating the abstract HTTP proxy. |
HttpProxy | Default HTTP proxy based on AbstractHttpProxy. |
HttpProxyNonTransparent | HTTP proxy based on HttpProxy, operating in non-transparent mode. |
HttpProxyURIFilter | HTTP proxy based on HttpProxy, with URI filtering capability. |
HttpProxyURIFilterNonTransparent | HTTP proxy based on HttpProxyURIFilter, with URI filtering capability and permitting non-transparent requests. |
HttpProxyURLCategoryFilter | HTTP proxy based on HttpProxy, with URL filtering capability based on categories. |
HttpWebdavProxy | HTTP proxy based on HttpProxy, allowing WebDAV extensions. |
NontransHttpWebdavProxy | HTTP proxy based on HttpProxyNonTransparent, allowing WebDAV extension in non-transparent requests. |
Table 4.13. Classes of the Http module
This class implements an abstract HTTP proxy - it serves as a starting point for customized proxy classes, but is itself not directly usable. Service definitions should refer to a customized class derived from AbstractHttpProxy, or one of the predefined proxy classes, such as HttpProxy or HttpProxyNonTransparent. AbstractHttpProxy denies all requests by default.
auth_by_cookie (boolean, rw:r) | |
---|---|
Default: FALSE | |
Authentication informations for one-time-password mode is organized by a cookie not the address of the client. |
auth_cache_time (integer, rw:r) | |
---|---|
Default: 0 | |
Caching authentication information this amount of seconds. |
auth_realm (string, w:r) | |
---|---|
Default: "Vela HTTP auth" | |
The name of the authentication realm to be presented to the user in the dialog window during inband authentication. |
enable_session_persistence (boolean, rw:rw) | |
---|---|
Default: FALSE | |
Allow persistent load balanced connections when accessing session-aware application servers. |
enable_url_filter (boolean, rw:r) | |
---|---|
Default: FALSE | |
Enables URL filtering in HTTP requests. See Section 4.6.2.12, URL filtering in HTTP for details. |
enable_url_filter_dns (boolean, rw:r) | |
---|---|
Default: FALSE | |
Enables DNS- and reverse-DNS resolution to ensure that a domain or URL is correctly categorized even when it is listed in the database using its domain name, but the client tries to access it with its IP address (or vice-versa). See Section 4.6.2.12, URL filtering in HTTP for details. |
error_files_directory (string, rw:rw) | |
---|---|
Default: "/usr/share/vela/http" | |
Location of HTTP error messages. |
error_headers (string, n/a:rw) | |
---|---|
Default: n/a | |
A string included as a header in the error response. The string must be a valid header and must end with a " " sequence. |
error_silent (boolean, rw:rw) | |
---|---|
Default: FALSE | |
Turns off verbose error reporting to the HTTP client (makes firewall fingerprinting more difficult). |
error_status (integer, rw:rw) | |
---|---|
Default: 500 | |
If an error occurs, this value will be used as the status code of the HTTP response it generates. |
keep_persistent (boolean, rw:r) | |
---|---|
Default: FALSE | |
Try to keep the connection to the client persistent even if the server does not support it. |
language (string, rw:r) | |
---|---|
Default: "en" | |
Specifies the language of the HTTP error pages displayed to the client. English (en ) is the default. Other supported languages: de (German); hu (Hungarian).
|
max_body_length (integer, rw:rw) | |
---|---|
Default: 0 | |
Maximum allowed length of an HTTP request or response body. The default "0" value means that the length of the body is not limited. |
max_chunk_length (integer, rw:rw) | |
---|---|
Default: 0 | |
Maximum allowed length of a single chunk when using chunked transfer-encoding. The default "0" value means that the length of the chunk is not limited. |
max_header_lines (integer, rw:rw) | |
---|---|
Default: 50 | |
Maximum number of header lines allowed in a request or response. |
max_hostname_length (integer, rw:rw) | |
---|---|
Default: 256 | |
Maximum allowed length of the hostname field in URLs. |
max_line_length (integer, rw:r) | |
---|---|
Default: 4096 | |
Maximum allowed length of lines in requests and responses. This value does not affect data transfer, as data is transmitted in binary mode. |
max_url_length (integer, rw:rw) | |
---|---|
Default: 4096 | |
Maximum allowed length of an URL in a request. Note that this directly affects forms using the 'GET' method to pass data to CGI scripts. |
parent_proxy (string, rw:rw) | |
---|---|
Default: "" | |
The address or hostname of the parent proxy to be connected. Either DirectedRouter or InbandRouter has to be used when using parent proxy. |
permit_ftp_over_http (boolean, rw:r) | |
---|---|
Default: FALSE | |
Allow processing FTP URLs in non-transparent mode. |
permit_invalid_hex_escape (boolean, rw:r) | |
---|---|
Default: FALSE | |
Allow invalid hexadecimal escaping in URLs (% must be followed by two hexadecimal digits). |
permit_null_response (boolean, rw:r) | |
---|---|
Default: TRUE | |
Permit RFC incompliant responses with headers not terminated by CRLF and not containing entity body. |
permit_server_requests (boolean, rw:r) | |
---|---|
Default: TRUE | |
Allow server-type requests in non-transparent mode. |
request (complex, rw:rw) | |
---|---|
Default: empty | |
Normative policy hash for HTTP requests indexed by the HTTP method (e.g.: "GET", "PUT" etc.). See also Section 4.6.2.2, Configuring policies for HTTP requests and responses. |
request_header (complex, rw:rw) | |
---|---|
Default: empty | |
Normative policy hash for HTTP header requests indexed by the header names (e.g.: "Set-cookie"). See also Section 4.6.2.3, Configuring policies for HTTP headers. |
request_mime_type (string, n/a:r) | |
---|---|
Default: n/a | |
The MIME type of the request entity. Its value is only defined when the request is processed. |
request_stack (complex, rw:rw) | |
---|---|
Default: n/a | |
Attribute containing the request stacking policy: the hash is indexed based on method names (e.g.: GET). See Section 4.6.2.9, Stacking. |
request_url (string, n/a:rw) | |
---|---|
Default: n/a | |
The URL requested by the client. It can be modified to redirect the current request. |
request_url_proto (string, n/a:r) | |
---|---|
Default: n/a | |
Protocol specifier of the URL. This attribute is an alias for
request_url_scheme .
|
request_url_scheme (string, n/a:r) | |
---|---|
Default: n/a | |
Protocol specifier of the URL (http://, ftp://, etc.). |
response (complex, rw:rw) | |
---|---|
Default: empty | |
Normative policy hash for HTTP responses indexed by the HTTP method and the response code (e.g.: "PWD", "209" etc.). See also Section 4.6.2.2, Configuring policies for HTTP requests and responses. |
response_header (complex, rw:rw) | |
---|---|
Default: empty | |
Normative policy hash for HTTP header responses indexed by the header names (e.g.: "Set-cookie"). See also Section 4.6.2.3, Configuring policies for HTTP headers. |
response_mime_type (string, n/a:r) | |
---|---|
Default: n/a | |
The MIME type of the response entity. Its value is only defined when the response is processed. |
response_stack (complex, rw:rw) | |
---|---|
Default: n/a | |
Attribute containing the response stacking policy: the hash is indexed based on method names (e.g.: GET). See Section 4.6.2.9, Stacking. |
rewrite_host_header (boolean, rw:rw) | |
---|---|
Default: TRUE | |
Rewrite the Host header in requests when URL redirection is performed. |
server_response_time (integer, n/a:r) | |
---|---|
Default: n/a | |
This value stores the time difference between sending the request to the server and receiving the response, in milliseconds. |
session_persistence_cookie_name (string, rw:rw) | |
---|---|
Default: "JSESSIONID" | |
The name of the cookie which will be used to persist load balanced connections when accessing session-aware application servers. |
timeout (integer, rw:rw) | |
---|---|
Default: 300000 | |
General I/O timeout in milliseconds. If there is no timeout specified for a given operation, this value is used. |
timeout_request (integer, rw:rw) | |
---|---|
Default: 10000 | |
Time to wait for a request to arrive from the client. |
timeout_response (integer, rw:rw) | |
---|---|
Default: 300000 | |
Time to wait for the HTTP status line to arrive from the server. |
transparent_mode (boolean, rw:r) | |
---|---|
Default: TRUE | |
Set the operation mode of the proxy to transparent (TRUE) or non-transparent (FALSE). |
url_category (complex, rw:rw) | |
---|---|
Default: empty | |
Normative policy hash for category-based URL-filtering. The hash is indexed by the name of the category. |
url_filter_uncategorized_action (enum, rw:rw) | |
---|---|
Default: HTTP_URL_ACCEPT | |
The action applied to uncategorized (unknown) URLs when URL filtering is used.
By default, uncategorized URLs are accepted: |
Method | Description |
---|---|
getRequestHeader(self, header) | Function returning the value of a request header. |
getResponseHeader(self, header) | Function returning the value of a response header. |
setRequestHeader(self, header, new_value) | Function changing the value of a request header. |
setResponseHeader(self, header, new_value) | Function changing the value of a response header. |
Table 4.14. Method summary
This function looks up and returns the value of a header associated with the current request.
This function looks up and returns the value of a header associated with the current response.
This function looks up and changes the value of a header associated with the current request.
This function looks up and changes the value of a header associated with the current response.
HttpProxy is a default HTTP proxy based on AbstractHttpProxy. It is transparent, and enables the most commonly used HTTP methods: "GET", "POST" and "HEAD".
HTTP proxy based on HttpProxy. This class is identical to
HttpProxy
with the only difference being that it is non-transparent
(transparent_mode = FALSE
). Consequently,
clients must be explicitly configured to connect to this proxy
instead of the target server and issue proxy requests. On the server
side this proxy connects transparently to the target server.
For the correct operation the proxy must be able to set the server address on its own. This can be accomplished by using InbandRouter.
HTTP proxy based on HttpProxy, having URL filtering capability. The matcher attribute should be initialized to refer to a Matcher object. The initialization should be done in the class body as shown in the next example.
HTTP proxy based on HttpProxyURIFilter, but operating in non-transparent mode (transparent_mode = FALSE
).
HTTP proxy based on HttpProxy with enabled URL filtering (with DNS and reverse-DNS resolution) and preconfigured default category actions.
The following categories have policy action HTTP_URL_REJECT
:
Ad Fraud
Blacklist
Botnet
Child Abuse Images
Command and Control Centers
Compromised & Links To Malware
Criminal Skills
Gambling
Illegal Drugs
Malware Call-Home
Malware Distribution Point
Phishing/Fraud
Pornography
Self Harm
Sex & Erotic
Spam URLs
Spyware & Questionable Software
Violence
The following categories have policy action HTTP_URL_ACCEPT
:
Whitelist
HTTP proxy based on HttpProxy, also capable of inspecting WebDAV extensions of the HTTP protocol.
The following requests are permitted: PROPFIND; PROPPATCH; MKCOL; COPY; MOVE; LOCK; UNLOCK.
HTTP proxy based on HttpProxyNonTransparent, operating in non-transparent mode (transparent_mode = FALSE
) and capable of inspecting WebDAV extensions of the HTTP protocol.
The following requests are permitted: PROPFIND; PROPPATCH; MKCOL; COPY; MOVE; LOCK; UNLOCK.
This module defines an interface to the Plug proxy. Plug is a simple TCP or UDP circuit, which means that transmission takes place without protocol verification.
This class implements a general plug proxy, and is capable of optionally disabling data transfer in either direction. Plug proxy reads connection on the client side, then creates another connection at the server side. Arriving responses are sent back to the client. However, it is not a protocol proxy, therefore PlugProxy does not implement any protocol analysis. It offers protection to clients and servers from lower level (e.g.: IP) attacks. It is mainly used to allow traffic pass the firewall for which there is no protocol proxy available.
By default plug copies all data in both directions. To change
this behavior, set the copy_to_client
or copy_to_server
attribute
to FALSE.
Plug supports the use of secondary sessions. For details, see Section 2.2, Secondary sessions.
Note |
---|
Copying of out-of-band data is not supported. |
Plug proxy is not a protocol specific proxy module, therefore it is not specified in standards.
Class | Description |
---|---|
AbstractPlugProxy | Class encapsulating the abstract Plug proxy. |
PlugProxy | Class encapsulating the default Plug proxy. |
Table 4.15. Classes of the Plug module
An abstract proxy class for transferring data.
bandwidth_to_client (integer, n/a:r) | |
---|---|
Default: n/a | |
Read-only variable containing the bandwidth currently used in server->client direction. |
bandwidth_to_server (integer, n/a:r) | |
---|---|
Default: n/a | |
Read-only variable containing the bandwidth currently used in client->server direction. |
secondary_mask (secondary_mask, rw:r) | |
---|---|
Default: 0xf | |
Specifies which connections can be handled by the same proxy instance. See Section 2.2, Secondary sessions for details. |
secondary_sessions (integer, rw:r) | |
---|---|
Default: 10 | |
Maximum number of allowed secondary sessions within a single proxy instance. See Section 2.2, Secondary sessions for details. |
Method | Description |
---|---|
packetStats(self, client_bytes, client_pkts, server_bytes, server_pkts) | Function called when the packet_stats_interval is elapsed. |
Table 4.16. Method summary
This function is called whenever the time interval set in packet_stats_interval elapses, or a given number of packets were transmitted. This event receives packet statistics as parameters. It can be used in managing the Quality of Service of the connections; e.g.: to terminate connections with excessive bandwidth requirements (for instance to limit the impact of a covert channel opened when using plug instead of a protocol specific proxy).
The Pop3 module defines the classes constituting the proxy for the POP3 protocol.
Post Office Protocol version 3 (POP3) is usually used by mail user agents (MUAs) to download messages from a remote mailbox. POP3 supports a single mailbox only, it does not support advanced multi-mailbox operations offered by alternatives such as IMAP.
The POP3 protocol uses a single TCP connection to give access to a single mailbox. It uses a simple command/response based approach, the client issues a command and a server can respond either positively or negatively.
The basic protocol is the following: the client issues a request (also called command in POP3 terminology) and the server responds with the result. Both commands and responses are line based, each command is sent as a complete line, a response is either a single line or - in case of mail transfer commands - multiple lines.
Commands begin with a case-insensitive keyword possibly followed by one or more arguments (such as RETR or DELE).
Responses begin with a status indicator ("+OK" or "-ERR") and a possible explanation of the status code (e.g.: "-ERR Permission denied.").
Responses to certain commands (usually mail transfer commands) also contain a data attachment, such as the mail body. See the Section 4.8.1.3, Bulk transfers for further details.
The protocol begins with the server displaying a greeting message, usually containing information about the server.
After the greeting message the client takes control and the protocol enters the AUTHORIZATION state where the user has to pass credentials proving his/her identity.
After successful authentication the protocol enters TRANSACTION state where mail access commands can be issued.
When the client has finished processing, it issues a QUIT command and the connection is closed.
Responses to certain commands (such as LIST or RETR) contain a long data stream. This is transferred as a series of lines, terminated by a "CRLF '.' CRLF" sequence, just like in SMTP.
Pop3Proxy is a module built for parsing messages of the POP3 protocol. It reads and parses COMMANDs on the client side, and sends them to the server if the local security policy permits. Arriving RESPONSEs are parsed as well, and sent to the client if the local security policy permits. It is possible to manipulate both the requests and the responses.
By default, the proxy accepts all commands recommended in RFC 1939. Additionally, the following optional commands are also accepted: USER, PASS, AUTH. The proxy understands all the commands specified in RFC 1939 and the AUTH command. These additional commands can be enabled manually.
Changing the default behavior of commands can be done using the
hash named request
. The hash is indexed by the command name
(e.g.: USER or AUTH). See Section 2.1, Policies for requests and responses for details.
Action | Description |
---|---|
POP3_REQ_ACCEPT |
Accept the request without any modification. |
POP3_REQ_ACCEPT_MLINE |
Accept multiline requests without modification. Use it only if unknown commands has to be enabled (i.e. commands not specified in RFC 1939 or RFC 1734). |
POP3_REQ_REJECT |
Reject the request. The second parameter contains a string that is sent back to the client. |
POP3_REQ_POLICY |
Call the function specified to make a decision about the event. See Section 2.1, Policies for requests and responses for details. This action uses two additional tuple items, which must be callable Python functions. The first function receives two parameters: self and command. The second one is called with an answer, (if the answer is multiline, it is called with every line) and receives two parameters: self and response_param. |
POP3_REQ_ABORT |
Reject the request and terminate the connection. |
Table 4.17. Action codes for POP3 requests
As in many other protocols, POP3 also starts with a server banner. This banner contains the protocol version the server uses, the possible protocol extensions that it supports and, in many situations, the vendor and exact version number of the POP3 server.
This information is useful only if the clients connecting to the POP3 server can be trusted, as it might make bug hunting somewhat easier. On the other hand, this information is also useful for attackers when targeting this service.
To prevent this, the banner can be replaced with a neutral one.
Use the request
hash with the 'GREETING' keyword as shown in the following example.
Note |
---|
Some protocol extensions (most notably APOP) use random characters in the greeting message as salt in the authentication process, so changing the banner when APOP is used effectively prevents APOP from working properly. |
The available stacking modes for this proxy module are listed in the following table. For additional information on stacking, see Section 2.3.1, Proxy stacking.
Action | Description |
---|---|
POP3_STK_POLICY |
Call the function specified to decide which part (if any) of the traffic should be passed to the stacked proxy. |
POP3_STK_NONE |
No additional proxy is stacked into the POP3 proxy. |
POP3_STK_MIME |
The data part of the traffic including the MIME headers is passed to the specified stacked proxy. |
POP3_STK_DATA |
Only the data part of the traffic is passed to the specified stacked proxy. |
Table 4.18. Action codes for proxy stacking
When filtering messages for viruses or spam, the Content Filtering modules reject infected and spam e-mails. In such cases the POP3 proxy notifies the client about the rejected message in a special e-mail.
To reject e-mail messages using the ERR
protocol element, set the reject_by_mail
attribute to FALSE
. However, this is not recommended, because several client applications handle
ERR
responses incorrectly.
Note |
---|
Infected e-mails are put into the quarantine and deleted from the server. |
Post Office Protocol Version 3 is described in RFC 1939.
The POP3 AUTHentication command is described in RFC 1734.
Class | Description |
---|---|
AbstractPop3Proxy | Class encapsulating the abstract POP3 proxy. |
Pop3Proxy | Default POP3 proxy based on AbstractPop3Proxy. |
Pop3STLSProxy | POP3 proxy based on Pop3Proxy allowing Start TLS. |
Table 4.19. Classes of the Pop3 module
This class implements an abstract POP3 proxy - it serves as a starting point for customized proxy classes, but is itself not directly usable. Service definitions should refer to a customized class derived from AbstractPop3Proxy, or a predefined Pop3Proxy proxy class. AbstractPop3Proxy denies all requests by default.
max_request_line_length (integer, rw:r) | |
---|---|
Default: 90 | |
Maximum allowed line length for client requests, without the CR-LF line ending characters. |
max_response_line_length (integer, rw:r) | |
---|---|
Default: 512 | |
Maximum allowed line length for server responses, without the CR-LF line ending characters. |
reject_by_mail (boolean, rw:r) | |
---|---|
Default: TRUE | |
If the stacked proxy or content filtering module rejects an e-mail message, reply with a special e-mail message instead
of an ERR response. See Section 4.8.2.5, Rejecting viruses and spam for details.
|
request (complex, rw:rw) | |
---|---|
Default: | |
Normative policy hash for POP3 requests indexed by the command name (e.g.: "USER", "UIDL", etc.). See also Section 4.8.2.2, Configuring policies for POP3 commands. |
request_command (string, n/a:rw) | |
---|---|
Default: n/a | |
When a command is passed to the policy level, its value can be changed to this value. |
request_param (string, n/a:rw) | |
---|---|
Default: n/a | |
When a command is passed to the policy level, the value of its parameters can be changed to this value. |
response_stack (complex, rw:rw) | |
---|---|
Default: | |
Hash containing the stacking policy for multiline POP3 responses. The hash is indexed by the POP3 response. See also Section 4.8.2.4, Stacking. |
session_timestamp (string, n/a:r) | |
---|---|
Default: n/a | |
If the POP3 server implements the APOP command, with the greeting message it sends a timestamp, which is stored in this parameter. |
Pop3Proxy is the default POP3 proxy based on AbstractPop3Proxy, allowing the most commonly used requests.
The following requests are permitted: APOP; DELE; LIST; LAST; NOOP; PASS; QUIT; RETR; RSET; STAT; TOP; UIDL; USER; GREETING. All other requests (including CAPA) are rejected.
Pop3STLSProxy is based on Pop3Proxy, allowing the most commonly used requests.
The following requests are permitted: APOP; DELE; LIST; LAST; NOOP; PASS; QUIT; RETR; RSET; STAT; TOP; UIDL; USER; CAPA; STLS; GREETING. All other requests are rejected. The self.max_request_line_length is set to 253.
Simple Mail Transport Protocol (SMTP) is a protocol for transferring electronic mail messages from Mail User Agents (MUAs) to Mail Transfer Agents (MTAs). It is also used for exchanging mails between MTAs.
The main goal of SMTP is to reliably transfer mail objects from the client to the server. A mail transaction involves exchanging the sender and recipient information and the mail body itself.
SMTP is a traditional command based Internet protocol; the client issues command verbs with one or more arguments, and the server responds with a 3 digit status code and additional information. The response can span one or multiple lines, the continuation is indicated by an '-' character between the status code and text.
The communication itself is stateful, the client first specifies the sender via the "MAIL" command, then the recipients using multiple "RCPT" commands. Finally it sends the mail body using the "DATA" command. After a transaction finishes the client either closes the connection using the "QUIT" command, or starts a new transaction with another "MAIL" command.
Originally SMTP had a very limited set of commands (HELO, MAIL, RCPT, DATA, RSET, QUIT, NOOP) but as of RFC 1869, an extension mechanism was introduced. The initial HELO command was replaced by an EHLO command and the response to an EHLO command contains all the extensions the server supports. These extensions are identified by an IANA assigned name.
Extensions are used for example to implement inband authentication (AUTH), explicit message size limitation (SIZE) and explicit queue run initiation (ETRN). Each extension might add new command verbs, but might also add new arguments to various SMTP commands. The SMTP proxy has built in support for the most important SMTP extensions, further extensions can be added through customization.
The Smtp module implements the SMTP protocol as specified in RFC 2821. The proxy supports the basic SMTP protocol plus five extensions, namely: PIPELINING, SIZE, ETRN, 8BITMIME, and STARTTLS. All other ESMTP extensions are filtered by dropping the associated token from the EHLO response. If no connection can be established to the server, the request is rejected with an error message. In this case the proxy tries to connect the next mail exchange server.
The abstract SMTP proxy rejects all commands and responses by default. Less restrictive proxies are available as derived classes (e.g.: SmtpProxy), or can be customized as required.
Changing the default behavior of commands can be done by
using the hash attribute request
. These hashes are indexed by the command name (e.g.: MAIL or DATA). Policies for responses can be configured using the response
attribute, which is indexed by the command name and the response code. The possible actions are shown in the tables below. See Section 2.1, Policies for requests and responses for details. When looking up entries of the response
attribute hash, the lookup precedence described in Section 2.1.2, Response codes is used.
Action | Description |
---|---|
SMTP_REQ_ACCEPT | Accept the request without any modification. |
SMTP_REQ_REJECT | Reject the request. The second parameter contains an SMTP status code, the third one an associated parameter which will be sent back to the client. |
SMTP_REQ_ABORT | Reject the request and terminate the connection. |
Table 4.20. Action codes for SMTP requests
Action | Description |
---|---|
SMTP_RSP_ACCEPT | Accept the response without any modification. |
SMTP_RSP_REJECT | Reject the response. The second parameter contains an SMTP status code, the third one an associated parameter which will be sent back to the client. |
SMTP_RSP_ABORT | Reject the response and terminate the connection. |
Table 4.21. Action codes for SMTP responses
SMTP extensions can be controlled using the extension
hash, which is indexed by the extension name. The supported extensions (SMTP_EXT_PIPELINING; SMTP_EXT_SIZE; SMTP_EXT_ETRN; SMTP_EXT_8BITMIME) can be accepted or dropped (SMTP_EXT_ACCEPT or SMTP_EXT_DROP) individually or all at once using the SMTP_EXT_ALL index value.
The available stacking modes for this proxy module are listed in the following table. For additional information on stacking, see Section 2.3.1, Proxy stacking.
Action | Description |
---|---|
SMTP_STK_NONE | No additional proxy is stacked into the SMTP proxy. |
SMTP_STK_MIME | The data part including header information of the traffic is passed to the specified stacked proxy. |
Table 4.22. Stacking options for SMTP
Simple Mail Transfer Protocol is described in RFC 2821.
SMTP Service Extensions are described in the obsoleted RFC 1869.
The STARTTLS extension is described in RFC 3207.
Class | Description |
---|---|
AbstractSmtpProxy | Class encapsulating the abstract SMTP proxy. |
SmtpProxy | Default SMTP proxy based on AbstractSmtpProxy. |
Table 4.23. Classes of the Smtp module
This class implements an abstract SMTP proxy - it serves as a starting point for customized proxy classes, but is itself not directly usable. Service definitions should refer to a customized class derived from AbstractSmtpProxy, or one of the predefined proxy classes.
The following requests are permitted: HELO; MAIL; RCPT; DATA; RSET; QUIT; NOOP; EHLO; AUTH; ETRN. The following extensions are permitted: PIPELINING; SIZE; ETRN; 8BITMIME; STARTTLS.
active_extensions (integer, n/a:r) | |
---|---|
Default: n/a | |
Active extension bitmask, contains bits defined by the constants 'SMTP_EXT_*' |
add_received_header (boolean, rw:rw) | |
---|---|
Default: FALSE | |
Add a Received: header into the email messages transferred by the proxy. |
append_domain (string, rw:rw) | |
---|---|
Default: | |
Domain to append to email addresses which do not specify domain name. An address is rejected if it does not contain a domain and append_domain is empty. |
domain_name (string, rw:rw) | |
---|---|
Default: | |
If you want to set a fix domain name into the added Receive line, set this. Only takes effect if add_received_header is TRUE. |
interval_transfer_noop (integer, rw:rw) | |
---|---|
Default: 600000 | |
The interval between two NOOP commands sent to the server while waiting for the results of stacked proxies. |
max_auth_request_length (integer, rw:r) | |
---|---|
Default: 256 | |
Maximum allowed length of a request during SASL style authentication. |
request (complex, rw:rw) | |
---|---|
Default: | |
Normative policy hash for SMTP requests indexed by the command name (e.g.: "USER", "UIDL", etc.). See also Section 4.9.2.2, Configuring policies for SMTP commands and responses. |
request_command (string, n/a:rw) | |
---|---|
Default: n/a | |
When a command is passed to the policy level, its value can be changed to this value. |
request_param (string, n/a:rw) | |
---|---|
Default: n/a | |
When a command is passed to the policy level, the value of its parameter can be changed to this value. |
request_stack (complex, rw:rw) | |
---|---|
Default: | |
Attribute containing the stacking policy for SMTP commands. See Section 4.9.2.3, Stacking. |
require_crlf (boolean, rw:r) | |
---|---|
Default: TRUE | |
Specifies whether the proxy should enforce valid CRLF line terminations. |
resolve_host (boolean, rw:rw) | |
---|---|
Default: FALSE | |
Resolve the client host from the IP address and add it to the Received line. Only takes effect if add_received_header is TRUE. |
response (complex, rw:rw) | |
---|---|
Default: | |
Normative policy hash for SMTP responses indexed by the command name and the response code. See also Section 4.9.2.2, Configuring policies for SMTP commands and responses. |
response_value (string, n/a:rw) | |
---|---|
Default: n/a | |
When a response is passed to the policy level, its value can be changed to this value. (It has effect only when the return value is not SMTP_*_ACCEPT.) |
timeout (integer, rw:r) | |
---|---|
Default: 600000 | |
Timeout in milliseconds. If no packet arrives within this in interval, the connection is dropped. |
SmtpProxy implements a basic SMTP Proxy based on AbstractSmtpProxy, with relay checking and sender/recipient check restrictions. (Exclamation marks and percent signs are not allowed in the e-mail addresses.)
permit_exclamation_mark (boolean, rw:rw) | |
---|---|
Default: FALSE | |
Allow the '!' sign in the local part of e-mail addresses. |
permit_percent_hack (boolean, rw:rw) | |
---|---|
Default: FALSE | |
Allow the '%' sign in the local part of e-mail addresses. |
recipient_matcher (class, rw:rw) | |
---|---|
Default: | |
Matcher class (e.g.: SmtpInvalidRecipientMatcher) used to check and filter recipient e-mail addresses. |
relay_domains_matcher (class, rw:r) | |
---|---|
Default: | |
Domains mails are accepted for based on a matcher (e.g.: RegexpFileMatcher). |
The Telnet module defines the classes constituting the proxy for the TELNET protocol.
The Telnet protocol was designed to remotely login to computers via the network. Although its main purpose is to access a remote standard terminal, it can be used for many other functions as well.
The protocol follows a simple scenario. The client opens a TCP connection to the server at the port 23. The server authenticates the client and opens a terminal. At the end of the session the server closes the connection. All data is sent in plain text format whithout any encryption.
The communication is based on the network virtual terminal (NVT). Its goal is to map a character terminal so neither the "server" nor "user" hosts need to keep information about the characteristics of each other's terminals and terminal handling conventions. NVT uses 7 bit code ASCII characters as the display device. An end of line is transmitted as a CRLF (carriage return followed by a line feed). NVT ASCII is used by many other protocols as well.
NVT defines three mandatory control codes which must be understood by the participants: NULL, CR (Carriage Return), which moves the printer to the left margin of the current line and LF (Line Feed), which moves the printer to the next line keeping the current horizontal position.
NVT also contains some optional commands which are useful. These are the following:
BELL is an audible or visual sign.
BS (Back Space) moves the printer back one position and deletes a character.
HT (Horizontal Tab) moves the printer to the next horizontal tabular stop.
VT Vertical Tab moves the printer to the next vertical tabular stop.
FF (Form Feed) moves the printer to the top of the next page.
The protocol uses several commands that control the method and various details of the interaction between the client and the server. These commands can be either mandatory commands or extensions. During the session initialization the client and the server negotiates the connection parameters with these commands. Sub-negotiation is a process during the protocol which is for exchanging extra parameters of a command (e.g.: sending the window size). The commands of the protocol are:
Request/Response | Description |
---|---|
SE | End of sub-negotiation parameters. |
NOP | No operation. |
DM | Data mark - Indicates the position of Sync event within the data stream. |
BRK | Break - Indicates that a break or attention key was hit. |
IP | Suspend, interrupt or abort the process. |
AO | Abort output - Run a command without sending the output back to the client. |
AYT | Are you there - Request a visible evidence that the AYT command has been received. |
EC | Erase character - Delete the character last received from the stream. |
EL | Erase line - Erase a line without a CRLF. |
GA | Go Ahead - Instruct the other machine to start the transmission. |
SB | Sub-negotiation starts here. |
WILL | Will (option code) - Indicates the desire to begin performing the indicated option, or confirms that it is being performed. |
WONT | Will not (option code) - Indicates the refusal to perform, or continue performing, the indicated option. |
DO | Do (option code) - Indicates the request that the other party perform, or confirmation that the other party is expected to perform, the indicated option. |
DONT | Do not (option code) - Indicates the request that the other party stop performing the indicated option, or confirmation that its performing is no longer expected. |
IAC | Interpret as command. |
Table 4.24. Telnet protocol commands
TelnetProxy is a module built for parsing TELNET protocol commands and the negotiation process. It reads and parses COMMANDs on the client side, and sends them to the server if the local security policy permits. Arriving RESPONSEs are parsed as well and sent to the client if the local security policy permits. It is possible to manipulate options by using TELNET_OPT_POLICY. It is also possible to accept or deny certain options and suboptions.
The Telnet shell itself cannot be controlled, thus the commands issued by the users cannot be monitored or modified.
The low level abstract Telnet proxy denies every option and suboption negotiation sequences by default. The different options can be enabled either manually in a derived proxy class, or the predefined TelnetProxy class can be used.
The Telnet proxy can enable/disable the use of the options and their suboptions within the session. Changing the default policy
can be done using the option
multi-dimensional hash,
indexed by the option and the suboption (optional). If the suboption is specified, the lookup precedence described in Section 2.1.2, Response codes is used.
The possible action codes are listed in the table below.
Action | Description |
---|---|
TELNET_OPT_ACCEPT |
Allow the option. |
TELNET_OPT_DROP |
Reject the option. |
TELNET_OPT_ABORT |
Reject the option and terminate the Telnet session. |
TELNET_OPT_POLICY |
Call the function specified to make a decision about the event. The function receives two parameters: self, and option (an integer). See Section 2.1, Policies for requests and responses for details. |
Table 4.25. Action codes for Telnet options
Constants have been defined for the easier use of TELNET options and suboptions. These are listed in Table A.1, TELNET options and suboptions.
Policy callback functions can be used to make decisions based on the
content of the suboption negotiation sequence. For example, the suboption negotiation sequences of the Telnet
Environment option transfer environment
variables. The low level proxy implementation parses these variables, and
passes their name and value to the callback function one-by-one. These
values can also be manipulated during transfer, by changing the current_var_name
and
current_var_value
attributes of the proxy class.
In the Telnet protocol, options and the actual commands are represented on one byte. In order to be able to use a command in a session, the option (and its suboptions if there are any) corresponding to the command has to be negotiated between the client and the server. Usually the command and the option is represented by the same value, e.g.: the TELNET_STATUS
command and option are both represented by the value "5". However, this is not always the case. The negotiation
hash is indexed by the code of the command, and contains the code of the option to be negotiated for the given command (or the TELNET_NEG_NONE
when no negotation is needed).
Currently the only command where the code of the command differs from the related option is self.negotiation["239"] = int(TELNET_EOR)
.
The Telnet protocol is described in RFC 854. The different options of the protocol are described in various other RFCs, listed in Table A.1, TELNET options and suboptions.
Class | Description |
---|---|
AbstractTelnetProxy | Class encapsulating the abstract Telnet proxy. |
TelnetProxy | Default Telnet proxy based on AbstractTelnetProxy. |
TelnetProxyStrict | Telnet proxy based on AbstractTelnetProxy, allowing only the minimal command set. |
Table 4.26. Classes of the Telnet module
This class implements the Telnet protocol (as described in RFC 854) and its most common extensions. Although not all possible options are checked by the low level proxy, it is possible to filter any option and suboption negotiation sequences using policy callbacks. AbstractTelnetProxy serves as a starting point for customized proxy classes, but is itself not directly usable. Service definitions should refer to a customized class derived from AbstractTelnetProxy, or one of the predefined TelnetProxy proxy classes. AbstractTelnetProxy denies all options by default.
current_var_value (string, n/a:rw) | |
---|---|
Default: n/a | |
Value of the variable being negotiated (e.g.: value of an environment variable, an X display location value, etc.). |
negotiation (complex, rw:rw) | |
---|---|
Default: | |
Normative hash listing which options must be negotiated for a given command. See Section Option negotiation for details. |
option (complex, rw:rw) | |
---|---|
Default: n/a | |
Normative policy hash for Telnet options indexed by the option and (optionally) the suboption. See also Section 4.10.2.2, Configuring policies for the TELNET protocol. |
TelnetProxy is a proxy class based on AbstractTelnetProxy, allowing the use of all Telnet options.
TelnetProxyStrict is a proxy class based on AbstractTelnetProxy, allowing the use of the options minimally required for a useful Telnet session.
The following options are permitted: ECHO; SUPPRESS_GO_AHEAD; TERMINAL_TYPE; NAWS; EOR; TERMINAL_SPEED; X_DISPLAY_LOCATION; ENVIRONMENT. All other options are rejected.
Internet Message Access Protocol (IMAP) is a protocol to access electronic mailboxes via a reliable TCP connection between the client and the server.
IMAP is a standard IETF protocol to access mail folders stored on a remote mail server. Unlike POP3 which gives only limited access to a single INBOX, IMAP permits manipulation of a remote mail store in a way that is functionally equivalent to local mailboxes.
Unlike many common IETF protocols, IMAP is not a one-request/one-response protocol. The client might issue one or more actions to be performed in parallel, thus responses to those commands can arrive in an order independent from the order they were issued. Requests and the appropriate responses are paired by a unique request identifier called 'tag'. There is one exception to this rule: the server might return untagged responses, when more than a single response is associated with a single command. In this case the server responds with one or more untagged responses and at the end a tagged response to indicate the end of the processing.
The syntax of the IMAP protocol is strictly defined, both the client and the server is either reading a complete line or a sequence of octets prefixed with the length of the sequence.
Request lines start with the tag, followed by a command verb identifying the operation. Each command might have one or more arguments separated by spaces. Each argument has an associated type, one of: ATOM, LITERAL, STRING, LIST. The type further specifies the syntax how these arguments are represented.
A response from the server might be sent directly in response to a request, or unilaterally whenever the server implementation feels it appropriate. The response includes a response verb with zero or more arguments. Note that there might be more response verbs returned for a single command and the response verbs have no direct relationship with the request verb.
Content (e.g.: mail bodies) are transferred as literals embedded in commands and responses. There is no separate bulk transfer mode in the protocol like in POP3 or SMTP. This results in extremely large request/response sizes.
Each message might have one or more associated message flags like '\Deleted' or '\Seen'.
IMAP defines four protocol states. Most commands are valid only in certain states. IMAP has the following states:
Non-Authenticated State: This state is at the beginning of the protocol flow before the client authenticates him/herself.
Authenticated State: In this state the client is authenticated and MUST select a mailbox to access before commands that affect messages are be permitted.
Selected State: In this state, a mailbox is selected for access. The protocol enters this state when a mailbox has been successfully selected.
Logout State: In this state the connection is being terminated and the server will close the connection.
IMAP is similar to other protocols in the sense that a connection is authenticated once, at the beginning of the communication. Before authentication is performed only a limited set of commands can be issued, for example AUTHENTICATE and LOGIN.
Each IMAP operation requires a current mailbox which is similar to the current working directory on UNIX systems. Without a selected mailbox, only a limited set of commands can be issued, for example SELECT, CREATE or REMOVE.
Once a mailbox is selected using the SELECT command, further operations become available, like FETCH or STORE.
Responses to IMAP requests come in two types: tagged and untagged. When a client issues a request, the server responds with a single tagged response, which may be preceeded by a number of untagged response lines. In the example above, the client issues a tagged A001 CAPABILITY command to ask the server for the supported capabilities. The server replies with the untagged * CAPABILITY IMAP4 ... line, listing the capabilities, and the tagged A001 OK Completed line, indicating that the request was successfully completed.
ImapProxy is a module built for parsing requests and responses of the IMAP protocol. It reads all the REQUESTs at the client side, parses them and - if the local security policy permits - sends them to the server one-by-one. When the RESPONSEs arrive they are parsed by the proxy and sent to the client one by one if the local security policy permits it. Simple greeting rewriting is supported to hide the version of the server. ImapProxy also implements the NAMESPACE, RLIST and RLSUB commands and the LOGIN authentication method. Other authentication methods are not supported and are denied (the proxy does not send them to the policy level).
Changing the default behaviour of requests is possible using the
request
attribute. This hash is indexed by the IMAP command
name.
The response
attribute is indexed as follows:
The response
attribute hash is a three-dimensional hash, indexed by the command name for which the response is sent; the type of the response (TAGGED or UNTAGGED); and the response name. Untagged responses are accepted when there is a command in the pending queue (i.e. no tagged response arrived to it yet). The following constants are defined for the response types:
Name | Value |
---|---|
IMAP_TAG_UNTAGGED | Untagged responses. |
IMAP_TAG_ALL | Both types of responses. |
IMAP_TAG_TAGGED | Tagged responses. |
Table 4.27. Constants for IMAP response types
The proxy looks up the hash value corresponding to the IMAP command name as the key. If the hash contains no entry for a command, the "*" entry is used. If there is no "*" entry in the hash, the command is denied.
The possible actions are described in the following tables.
Action | Description |
---|---|
IMAP_REQ_ACCEPT | Allow the command to pass. |
IMAP_REQ_REJECT | Reject the command and send an error message to the client. |
IMAP_REQ_DROP | Silently drop the command - reject the command without sending an error message. |
IMAP_REQ_ABORT | Terminate the connection. |
IMAP_REQ_POLICY | Call the function specified in the argument to make a decision about the event. See Section 4.11.2.1, Configuring policies for IMAP requests and responses for details. |
IMAP_REQ_REWRITE | Replace the request with a predefined one. See the example below. |
IMAP_REQ_RESPOND | Respond to the request instead of the server. The request is not sent to the server. This action requires two arguments: a string containing a tagged response for the request, and a string list containing the optional untagged responses. |
Table 4.28. Action codes for IMAP requests
Action | Description |
---|---|
IMAP_RSP_ACCEPT | Allow the response to pass. |
IMAP_RSP_REJECT | Reject the response and send an error message to the client. |
IMAP_RSP_DROP | Silently drop the response. |
IMAP_RSP_ABORT | Terminate the connection. |
IMAP_RSP_POLICY | Call the function specified to make a decision about the event. See Section 4.11.2.1, Configuring policies for IMAP requests and responses for details. |
IMAP_RSP_REWRITE | Replace the response containing the greeting string with a predefined one. See the example below. |
Table 4.29. Action codes for IMAP responses
For calling a method, the hash must contain a tuple containing two values. The first value is IMAP_REQ_POLICY and the second is the function to call. The function must return with one of the IMAP_REQ_* values (excluding IMAP_*_POLICY), displayed in the table above.
The function is called with three arguments (apart from 'self'): the command tag, the command name, and its arguments. The representation of arguments used by IMAP is described in Section 4.11.2.4, The IMAP command structure in policies.
If the proxy is to answer instead of the server, the action tuples must contain the following three items: The value IMAP_REQ_RESPOND; the STRING to be sent back followed by a command tag, and a LIST containing untagged lines to be sent back to the client.
For example, to reply to every CAPABILITY request on behalf of the server:
Example 4.22. Rewriting IMAP capability response |
---|
self.request["CAPABILITY"] = (IMAP_REQ_RESPOND, "OK CAPABILITY completed", ("[IMAP4rev1]", )) |
There are other methods to control which CAPABILITYs are known by the client. There is a separate capability hash for this, indexed by the name of the capabilities. The valid values are listed below.
Action | Description |
---|---|
IMAP_CAP_ACCEPT | Allow use of the capability. |
IMAP_CAP_DROP | Reject the capability. |
Table 4.30. Action codes for IMAP capabilities
This hash has nothing to do with capabilities known by the proxy; it defines which answers can arrive to the client for a CAPABILITY command.
The IMAP greeting string can be modified (rewritten) by the proxy to hide sensitive information about the server. This can be realized as a rule defined as a tuple containing the following three items:
The value IMAP_REQ_REWRITE;
a default return value (e.g.: IMAP_REQ_ACCEPT);
and a string.
In IMAP there are some defined states, and some commands are allowed only in certain states.
On the policy level these states may be examined and modified if necessary. This can be accomplished by setting two attributes, imap_state_old
and imap_state_new
. The possible values for these variables are listed in the following table.
Name | Value |
---|---|
IMAP_IS_INITIAL | Before any command arrived. |
IMAP_IS_NONAUTH | Before authentication. |
IMAP_IS_AUTHENTICATING | Authentication is in progress. |
IMAP_IS_AUTH | Authentication performed. |
IMAP_IS_SELECTED | A mailbox is selected. |
IMAP_IS_QUIT | Logged out. |
Table 4.31. IMAP states
In the IMAP protocol the user can assign flags to mails (or other objects). For example, a flag is assigned to a message to indicate that it has been read (\Seen), it can be marked as important mail or it can be indicated that it has already been answered (\Answered). The usable flags are not predefined in the protocol, IMAP clients can assign any flags they desire.
Flags can be controlled similarly to requests and responses using the flag
hash. It is a
normative hash indexed by the name of the flag (case sensitive).
The common practice is to accept any flags by default and explicitly drop
unneeded flags. The possible actions related to flags are shown in the table below.
Action | Description |
---|---|
IMAP_FLAG_ACCEPT | Accept the flag. |
IMAP_FLAG_REJECT | Reject the flag, including the entire command or response. |
IMAP_FLAG_DROP | Drop the flag silently, but accept the rest of the command. If the command contains only the flag that is dropped, the entire command is dropped. |
Table 4.32. Action codes for IMAP flags
When using functions in policies to evaluate IMAP commands, the commands are represented as a recursive tuple of tuples having the following structure. Every command is a tuple of length 3, containing the tag of the command, the name of the command and a tuple containing the arguments.
The following values are possible as arguments (IMAP command structure in the policy layer):
(int, string) -- Integer
(int, int) -- Range
<LITERAL> -- Literal Literals (the actual messages) in the requests/responses are represented by a string having the 'Literal' value. The reason for this is that literals can be very large, therefore they are not sent to (thus not available) the policy level.
string -- A string or an atom
(",", a1, a2...) -- Comma-separated list
("[", a1, a2...) -- Bracketed list
("(", a1, a2...) -- Parenthesized list
Of course, lists can contain other lists recursively.
When processing IMAP responses where a number argument precedes the response name (e.g.: 1094 EXISTS), the number counts as the first argument.
Below are some examples how the different argument types are used in the IMAP protocol.
IMAP supports stacking proxies into different levels of the IMAP communication.
Stacking is controlled by the
stack
attribute hash. See also Section 2.3.1, Proxy stacking.
There are three stacking modes available, described in the table below.
Name | Value |
---|---|
IMAP_BODY_FULL | Pass the complete IMAP messages to the stacked proxy or program. |
IMAP_BODY_PART | Pass only the body part of IMAP messages to the stacked proxy or program. |
IMAP_BODY_TEXT | Pass only the text part of IMAP messages to the stacked proxy or program. |
Table 4.33. Body part selection for stacking
Internet Message Access Protocol (v4rev1) is described in RFC 3501.
IMAP4 Binary Content Extension is described in RFC 3516.
The IMAP UNSELECT command is described in RFC 3691.
The IMAP MULTIAPPEND Extension is described in RFC 3502.
The IMAP4 ID Extension is described in RFC 2971.
IMAP4 Namespace is described in RFC 2342.
IMAP4 Login Referrals are described in RFC 2221.
IMAP4 Mailbox Referrals are described in RFC 2193.
The IMAP4 QUOTA Extension is described in RFC 2087.
The IMAP4 ACL Extension is described in RFC 2086.
IMAP/POP AUTHorize Extension for Simple Challenge/Response is described in RFC 2195.
Class | Description |
---|---|
AbstractImapProxy | Class encapsulating the abstract IMAP proxy. |
ImapProxy | Default IMAP proxy based on AbstractImapProxy. |
ImapProxyStrict | IMAP proxy based on AbstractImapProxy, allowing only the minimal command set. |
Table 4.34. Classes of the Imap module
This class implements an abstract IMAP proxy - it serves as a starting point for customized proxy classes, but is itself not directly usable. Service definitions should refer to a customized class derived from AbstractImapProxy, or one of the predefined proxy classes, such as ImapProxy or ImapProxyStrict. AbstractImapProxy denies every command, response, etc. by default.
capability (complex, rw:rw) | |
---|---|
Default: | |
Normative hash defining the capabilities accepted by the proxy. See Section 4.11.2.2, Calling methods. |
flag (complex, rw:rw) | |
---|---|
Default: | |
Normative hash controlling flag values accepted by the proxy. See Section 4.11.2.3, Configuring acceptable flags. |
imap_state_new (enum, n/a:rw) | |
---|---|
Default: n/a | |
Protocol state after processing the line, one of the IMAP_IS_* constants. See Section 4.11.2.2, Calling methods. |
imap_state_old (enum, n/a:rw) | |
---|---|
Default: n/a | |
Protocol state before the command arrived, one of the IMAP_IS_* constants. See Section 4.11.2.2, Calling methods. |
max_literal_count (integer, rw:rw) | |
---|---|
Default: 32 | |
Maximum number of literals allowed in one command or answer. |
max_literal_length (integer, rw:rw) | |
---|---|
Default: 65536 | |
Maximum allowed literal length (e.g.: e-mail bodies are sent as literals). |
max_respond_lines (integer, rw:rw) | |
---|---|
Default: 2 | |
Maximum number of untagged lines that may be sent back to the client from policy. |
request (complex, rw:rw) | |
---|---|
Default: | |
Normative policy hash for IMAP requests indexed by command name. See also Section 2.1, Policies for requests and responses. |
response (complex, rw:rw) | |
---|---|
Default: | |
Normative policy hash for IMAP responses, indexed by command name, response type and response name. See Section 4.11.2.1, Configuring policies for IMAP requests and responses. |
stack (complex, rw:rw) | |
---|---|
Default: | |
Attribute containing the stacking policy for IMAP messages. See Section 4.11.2.5, Stacking for details. |
ImapProxy is the default proxy for the IMAP protocol, based on AbstractImapProxy.
All requests, responses and flags are permitted, as well as the following capabilities: IMAP4; IMAP4rev1; ACL; QUOTA; NAMESPACE; X-NON-HIERARCHICAL-RENAME; NO_ATOMIC_RENAME; UNSELECT; MAILBOX-REFERRALS; LOGIN-REFERRALS; AUTH=LOGIN; ID; CHILDREN; MULTIAPPEND; SORT; THREAD=ORDEREDSUBJECT; THREAD=REFERENCES; LISTEXT; LIST-SUBSCRIBED; ANNOTATEMORE.
IMAP proxy based on AbstractImapProxy, allowing only the minimal command set.
All flags are accepted. The following commands are permitted: AUTHENTICATE; CAPABILITY; CHECK; CLOSE; EXAMINE; FETCH; FIND; GETACL; LIST; LOGIN; LOGOUT; LSUB; NAMESPACE; NOOP; RLIST; RLSUB; SELECT; STATUS; UID; EXPUNGE; STORE.
The permitted capabilities are the following IMAP4; IMAP4rev1; ACL; QUOTA; NAMESPACE; X-NON-HIERARCHICAL-RENAME; NO_ATOMIC_RENAME; UNSELECT; MAILBOX-REFERRALS; LOGIN-REFERRALS; AUTH=LOGIN.
The Ldap module defines the classes constituting the proxy for the LDAP protocol.
Lightweight Directory Access Protocol (LDAP) is designed to provide access to X.500 directory services (i.e. to maintain directory databases). It is frequently used to distribute public key certificates, address book information, and user authentication information. Clients can be controlled by individuals (via an application, called LDAP browser) or an agent (e.g.: authentication module or any other application).
X.500 represents information in a hierarchical directory structure. Every entry in the tree is identified with a unique distinguished name (DN) and contains several attributes. A DN looks like the following:
uid=username,ou=administrators,ou=some-department,ou=some-part-of-the-company,dc=company,dc=net
A schema defines sets of attribute entries in an ObjectClass. Every container can have different ObjectClasses, with each ObjectClass having mandatory and optional entries. The following example defines a user with several attributes from five ObjectClasses.
LDAP is a request/response based binary protocol. The client can connect to the server on a channel at TCP/389 port and send REQUESTs. The client can request several operations in parallel. The following operations can be performed:
Bind: Identify the client and optionally perform authentication.
Unbind: Terminate a protocol session.
Search: Search for entries using filters.
Modify: Modify tree entries and attributes.
Add: Request the addition of an entry into the directory.
Delete: Request the deletion of an entry from the directory.
Modify DN: Change the leftmost component of the name of an entry in the directory, or to move a subtree of entries to a new location in the directory.
Compare: Compare an assertion provided with an entry in the directory.
Abandon: Request the server to cancel an outstanding operation.
Extended: This operation is for additional operations to be defined for services not available elsewhere in the protocol.
The protocol operates according to the following general scheme:
The client opens a connection at TCP/389 and binds to an object in the directory tree. The server authenticates the client to this object. If authentication is not required, the client can use the given tree anonymously.
If the authentication process is successful the client can perform requests (i.e. the above mentioned operations: modify, add, delete etc.).
Finally the client unbinds and closes the connection.
The LDAP protocol is described using ASN.1 (Abstract Syntax Notation), and is typically transferred using the Basic Encoding Rules, a subset of ASN.1.
LdapProxy is a module built for parsing the LDAP protocol version v2 and v3. It reads and parses the REQUESTs at the client side and - if the local security policy permits - sends them to the server. It parses the arriving RESPONSE and - if the local security policy permits - forwards it to the client. LdapProxy can parse the following requests and responses, consequently, these requests can be accepted or denied:
Request/Response | Description |
---|---|
BindRequest | Request for binding as an object. |
BindResponse | Response to BindRequests. |
UnbindRequest | Request for unbinding. |
SearchRequest | Request for submitting an LDAP query. |
SearchResultEntry | Response to SearchRequests. |
SearchResultDone | Response indicating the SearchRequest was performed. |
ModifyRequest | Request to modify an entry. |
ModifyResponse | Response to ModifyRequests. |
AddRequest | Request to add a new entry. |
AddResponse | Response to AddRequests. |
DelRequest | Request to delete an LDAP entry. |
DelResponse | Response to DelRequests. |
ModifyDNRequest | Request to modify a DN object. |
ModifyDNResponse | Response to ModifyDNRequests. |
CompareRequest | Request to compare the provided assertion with an entry in the directory. |
CompareResponse | Response to CompareRequests. |
AbandonRequest | Request to cancel a request. |
SearchResultReference | Response referring to another LDAP server. |
ExtendedRequest | Request reserved for further queries. |
ExtendedResponse | Response to ExtendedRequests. |
Table 4.35. Parsed LDAP operations
Changing the default behavior of requests can be done
using the hash attribute request
. The hash is indexed by the request name. The possible values of these hashes are shown in the tables below. See Section 2.1, Policies for requests and responses for details.
Action | Description |
---|---|
LDAP_REQ_ACCEPT | Allow the request to pass. |
LDAP_REQ_REJECT | Reject the request. |
LDAP_REQ_ABORT | Terminate the connection. |
Table 4.36. Action codes for LP requests
Simple Authentication and Security Layer (SASL) is a framework for authentication and data security in Internet protocols. It is also used by Microsoft Active directory. Please note that support for the SASL security layer is a work in progress - currently LDAP protocol analysis is effectively disabled for SASL wrapped requests.
Lightweight Directory Access Protocol (v3) is described in RFC 2251.
The LDAP URL Format is described in RFC 2255.
Using Domains in LDAP/X.500 Distinguished Names is described in RFC 2247.
Lightweight Directory Access Protocol (v3): Technical Specification is in RFC 3377.
Class | Description |
---|---|
AbstractLdapProxy | Class encapsulating the abstract Ldap proxy. |
LdapProxy | Default Ldap proxy based on AbstractLdapProxy. |
LdapProxyRO | Ldap proxy enabling only read-only access. |
Table 4.37. Classes of the Ldap module
This class implements an abstract LDAP proxy - it serves as a starting point for customized proxy classes, but is itself not directly usable. Service definitions should refer to a customized class derived from AbstractLdapProxy, or one of the predefined proxy classes. AbstractLdapProxy denies all requests by default.
permit_sasl_transport (boolean, rw:r) | |
---|---|
Default: FALSE | |
Permit the use of the Simple Authentication and Security Layer (SASL) on LDAP messages. See Section 4.12.4, Simple Authentication and Security Layer (SASL) on LDAP messages for details. |
request (complex, rw:r) | |
---|---|
Default: n/a | |
Normative policy hash for LDAP requests indexed by the request. See also Section 4.12.3, Configuring policies for LDAP requests. |
LdapProxy is a default proxy for the LDAP protocol based on AbstractLdapProxy. All syntactically correct operation is permitted.
This module defines the classes representing the MIME proxy.
Multipurpose Internet Mail Extensions (MIME) is a complex representation of multiple type of message bodies, and refers to an official Internet standard that defines how messages must be formatted. It makes possible for different types of e-mail systems to exchange messages successfully. MIME is a flexible format which allows to include different type of messages in a single e-mail message. It redefines message format to allow:
text messages in different character sets;
extensible set of non-text format messages;
multiple message types in one message body;
text header information.
The content of the message is shown by the MIME header, which indicates the type and number of parts the message contains. The header also contains encoding system and version information. MIME supports the following body-types:
Body-type | Description |
---|---|
text | The primary type of MIME content. The main subtype is plain. |
multipart | The message contains different types of data. |
message | Indicates an encapsulated text message. |
image | Indicates that the message contains image file. |
audio | Indicates that the message contains audio data. |
video | Indicates that the message contains video data. |
Table 4.38. MIME body-types
To make sure message contents arrive without corruption, non-text messages must be encoded to printable ASCII characters. Older UNIX systems use uuencode/uudecode transformation. MIME encoding provides base64 to encode any attachment as text.
MIME indicates the parameters of the message in the header field, which can be the following:
MIME header | Description |
---|---|
MIME-Version | Indicates the exact version of the MIME message. |
Content-Type | Indicates the type of the data contained in the body. The default content type is 'text/plain; charset=us-ascii'. |
Content-Transfer-Encoding | Indicates the encoding used in the message part. It is also possible to create private transfer encoding, which can be indicated by X-My-Private-Transfer-Encoding. |
Content-ID | Unique identifier of the MIME object. |
Content-Description | Extra comments added to the message by the user. |
Additional MIME Header Fields | Extra fields to be used by the developers in the future. |
Table 4.39. MIME headers
Note |
---|
MIME headers do not guarantee that the message really contains the type of content indicated in the header. |
MimeProxy is a module built for parsing MIME messages. Since MIME is not a communication protocol in itself, the MIME proxy cannot be used on its own. It can only inspect data received from a protocol proxy (e.g.: a HTTP proxy, POP3 proxy, etc. that stacks the MimeProxy). MimeProxy reads the data received from the other proxy and handles message headers and bodies if there are any. If the message conforms to the RFC standard it is accepted, otherwise the content is rejected. It is also possible to stack a further proxy into the Mime module (e.g.: a virus filtering module).
Configuring the default behavior for MIME objects is possible using the
header
and body_type
attributes.
MimeProxy parses MIME headers first. See Table 4.39, MIME headers and Table 4.38, MIME body-types for the available headers and body-types. The following table shows the possible actions on MIME headers. Headers may be accepted or dropped, or the entire object can be rejected. Subobjects (i.e. MIME objects embedded into other MIME objects) cannot be dropped or rejected individually, the entire object must be rejected/dropped.
Action | Description |
---|---|
MIME_HDR_ACCEPT | Accept header. |
MIME_HDR_DROP | Drop the header, but do not reject the entire MIME object. |
MIME_HDR_ABORT | Reject the entire connection. |
MIME_HDR_POLICY | Call the function specified to make a decision about the header. See Section 4.13.2.1, Configuring policies for MIME headers and content types for details. Put header line into policy level. |
Table 4.40. Action codes for MIME headers
Second, MimeProxy parses MIME content (or body) types.
The following table shows the possible actions on MIME types (body_type
). Stacking another module is possible using the MIME_TPE_STACK action.
Action | Description |
---|---|
MIME_TPE_ACCEPT | Accept the MIME type. |
MIME_TPE_DROP | Drop the entire MIME object. |
MIME_TPE_DROP_ONE | Drop the MIME object. This does not affect other objects in the object. |
MIME_TPE_CHANGE | Modify the type of the object to the one specified in the second argument. |
MIME_TPE_ABORT | Abort the connection and reject the entire MIME object. |
MIME_TPE_STACK | Pass the content to be inspected by another proxy. |
MIME_TPE_POLICY | Call the function specified to make a decision about the event. See Section 4.13.2.1, Configuring policies for MIME headers and content types for details. |
Table 4.41. Action codes for MIME content types
If all contents and headers are acceptable by the local security policy, MimeProxy rebuilds the MIME message and passes it back to the parent proxy.
RFC 2045: MIME Part One: Format of Internet Message Bodies
RFC 2046: MIME Part Two: Media Types
RFC 2047: MIME Part Three: Message Header Extensions for Non-ASCII Text
RFC 2048: MIME Part Four: Registration Procedures
RFC 2049: MIME Part Five: Conformance Criteria and Example
Class | Description |
---|---|
AbstractMimeProxy | Class encapsulating the abstract MIME proxy. |
MimeProxy | Default MIME proxy based on AbstractMimeProxy. |
Table 4.42. Classes of the Mime module
This class implements an abstract MIME proxy - it serves as a starting point for customized proxy classes, but is itself not directly usable. Service definitions should refer to a customized class derived from AbstractMimeProxy, or the predefined MimeProxy proxy class. AbstractMimeProxy rejects all headers and body-types by default.
append_object (string, rw:r) | |
---|---|
Default: "" | |
Appends the specified file (e.g.: /tmp/attachment ) as a new attachment. Requires the permit_empty_headers parameter to be set to TRUE .
|
body_type (complex, rw:r) | |
---|---|
Default: | |
Multi-dimensional policy hash for body-types, indexed by body-type name (major and minor parts of the body type). See Section 4.13.2.1, Configuring policies for MIME headers and content types. |
error (complex, rw:rw) | |
---|---|
Default: n/a | |
An alias of the error_action
parameter. Obsolete, use error_action instead.
|
error_action (complex, rw:rw) | |
---|---|
Default: n/a | |
With this normative hash you can control the action taken when
some error occurs. For compatibility reasons, the error
parameter refers to the same hash.
|
header (complex, rw:r) | |
---|---|
Default: | |
Normative policy hash for MIME header types, indexed by the header type. See Section 4.13.2.1, Configuring policies for MIME headers and content types. |
max_header_line_length (integer, rw:r) | |
---|---|
Default: 1000 | |
The maximum length of a single header line. A header may be split into multiple lines, this value limits the length of a single line. |
max_multipart_level (integer, rw:r) | |
---|---|
Default: 10 | |
The maximum recursion level the proxy should check. If the number of levels in an object exceeds the allowed limit, the object is rejected. |
mime_message_path (string, rw:r) | |
---|---|
Default: "/usr/share/vela/mime" | |
Path to the directory where the custom error messages are stored. |
Class | Description |
---|---|
AbstractModbusProxy | Class encapsulating the abstract MODBUS proxy. |
ModbusProxy | Default Modbus proxy based on AbstractModbusProxy. |
Table 4.43. Classes of the Modbus module
This class implements an abstract MODBUS proxy - it serves as a starting point for customized proxy classes, but is itself not directly usable. Service definitions should refer to a customized class derived from AbstractModbusProxy, or one of the predefined proxy classes. AbstractModbusProxy denies all requests by default.
buffer_size (integer) | |
---|---|
Default: 8192 | |
Size of the request/response buffer in bytes. Must be larger than the maximum size of a MODBUS ADU (260 bytes) |
default_accept (boolean) | |
---|---|
Default: FALSE | |
Allow all funcion requests by default, which are not specified in the request policy. |
Remote Procedure Call (RPC) is a protocol for calling procedures on remote machines.
The RPC protocol consists of two phases: negotiating an access point to a service and communicating with the service itself. On the server side the negotiation is performed by a special service called 'Endpoint Mapper' (EPM), which listens on the TCP/UDP port 135. The protocol of the communication is specified in the DCE RPC Specification. If the client is allowed to use the requested service, the EPM passes its address and IP in its response, and the client may connect to it and make any data transfer it wishes. The protocol format varies from service to service, so with maintained transparent forwarding facilities between the client and the service, only the communication between the client and the EPM is filtered.
The filtering of the traffic between the client and the EPM means that requests can be approved or rejected for services specified by their UUID. The denial of a service is implemented as if the EPM had refused it, the approval is transparent in a way that the resulting service access point has the same IP as in the original EPM request: only the port is altered to point to the dedicated forwarder facility.
The timing parameters of the communication may also be limited by specifying the maximal allowed duration of the requests/responses; the idle timeout between requests/responses and the maximal delay between the service approval and the connection to the approved service.
The MSRpc proxy is a module supporting version 2 of the MSRPC protocol.
Changing the default behavior for services can be accomplished via the self.interface
hash attribute. This hash is indexed
by the service UUID, and each item in this hash is an action code
defining proxy behavior for the given command. The available action codes are shown in the following table:
Name | Value |
---|---|
MSRPC_UUID_ACCEPT | Allow access to the requested service. |
MSRPC_UUID_REJECT | Reject access to the requested service. |
MSRPC_UUID_DROP | Drop the request without further notice. |
Table 4.44. Action codes for MSRpc requests.
Currently the proxy handles only TCP connections, and tracks/filters only the traffic toward the EPM service. Since this does not cover the protocols used by either the standardized or the proprietary DCOM services, some applications may not work properly through this proxy. Some remote management applications that use the ISystemActivator service and the notification feature of Exchange are known to have issues with the MSRpc proxy.
Class | Description |
---|---|
AbstractMSRpcProxy | Class encapsulating the abstract MSRpc proxy. |
MSRpcProxy | Default MSRpc proxy based on AbstractMSRpcProxy. |
Table 4.45. Classes of the MSRpc module
This class implements an abstract MSRpc proxy, denying access to all services by default.
command_timeout (integer, rw:r) | |
---|---|
Default: 600000 | |
Command timeout in milliseconds. If a packet cannot be transmitted during this interval, the connection is dropped. |
interface (complex, rw:rw) | |
---|---|
Default: empty | |
Normative policy hash indexed by the UUID of the services, specifying the security policy about the service. See Section 4.15.2.1, Setting policies for services for details. |
secondary_port_max (integer, rw:r) | |
---|---|
Default: 0 | |
The upper limit of the port range allocated for forwarders. (Zero means no restriction.) |
The Radius module defines the classes constituting the proxy for the RADIUS protocol.
Remote Authentication Dial In User Service (RADIUS) is a client-server protocol for user authentication between the Network Access Server (NAS) and the authenticator server. The protocol has three participants:
The user requesting network access the service (e.g.: PPP, PLIP etc.).
The access point (modem pools or NAS servers), which delivers the service. The access point acts as the client in the protocol.
The server which authenticates the user.
The RadiusProxy is installed between the server and client (i.e. the access point).
During the authentication process the participants use the following protocol elements:
REQUEST: When a new connection attempt arrives to the NAS, it sends a message towards the RADIUS server requesting the authentication of the user; or it sends an accounting related message.
RESPONSE: The RADIUS server attempts to authenticate the user when an authentication REQUEST is received. The server returns the result of the process to the NAS in a RESPONSE message.
ATTRIBUTE: Both the REQUEST and RESPONSE packets contain a set of structured attribute-value pairs containing information like username, password or the type of service requested by the user. Attributes are identified by a number ranging from 0 to 255. Each attribute has an associated type specified in the RADIUS RFCs which define the range of valid values.
Note |
---|
There are also some vendor-specific RADIUS dictionaries, where certain attributes are used for internal purposes. Obviously, these are not discussed in the RFCs. |
The user initiates the authentication process when attempting to use a NAS service. When the user request arrives, the NAS sends an Access-Request message containing the attributes username, MD5-hashed password, the user IP and the port ID. The message is sent to port UDP/1812; if no response is received within a period of time, the request is re-sent a number of times.
If RADIUS is configured to use username/password based authentication, the server consults the database and if all the terms match, the server replies with an Access-Accept message. When the challenge/response method is used the server generates a challenge and sends it to the client in an Access-Challenge message. The client displays it to the user who calculates the response which is resubmitted by the NAS client in another Access-Request message with a new request ID, encrypted User-Password attribute and the State Attribute. If the response is correct the server allows the connection request in an Access-Accept message and the NAS starts to deliver the service. If the authentication process fails the server sends an Access-Reject message and the NAS denies the delivery of the service.
The user and the NAS server (technically the radius client) are authenticated separately. The user is authenticated only after the NAS has been verified via the Radius secret (i.e. password). Users can be authenticated by username/password or challenge/response methods.
Username/password authentication is a traditional authentication method where the user id identifies the user and the password authenticates him/her. During the challenge/response the user ID identifies the user itself and the client is authenticated by a one time password. The server sends an unpredictable number to the client. The user calculates it with a hardware or software tool and sends the result back. If the answer is correct, it validates the client's identity and this is the response which authenticates the user.
The Access-Accept message might deliver additional parameters to the service, such as IP address. These additional parameters are delivered as values of various attributes.
RADIUS can also be used to send Service-Start and Service-End messages for accounting purposes. While the protocol is the same as the one described above, it uses a separate port and a separate set of attributes. When the client is configured to use RADIUS Accounting, it sends an Accounting-Start message describing the type of the service and the user using it. RADIUS accounting uses the port UDP/1813. The RADIUS server returns an acknowledgment. The client repeats sending the request until it receives the acknowledgment. At the end of delivering the service, the client sends an Accounting-Stop message to the server describing the type and optionally the statistics about the connection. The server acknowledges the stop messages as well.
Note |
---|
Earlier UDP/1645 was also used by RADIUS servers, and accounting messages were sent using port UDP/1646. |
RadiusProxy is a module built for parsing the messages of the RADIUS protocol. It reads the REQUESTs at the client side and decrypts the user password with the given shared secret (known by both the client and the server). If the REQUEST and all the ATTRIBUTEs are permitted by the local security policy, it sends the message to the RADIUS server. It parses the arriving RESPONSE and validates the authenticator signature. The authenticator signature is an MD5 hash included in the RADIUS message, generated from various message parameters, including the shared secret. It is used to ensure that the response is genuine and was indeed sent by the server. If the RESPONSE is permitted by the local security policy and is authentic, the message encrypted with the secret is returned to the NAS. It is possible to keep different secrets on the two sides of the proxy (i.e. password translation is possible). RadiusProxy is able to parse both authentication and accounting messages, and it can also manipulate RESPONSEs if the secret is available. If the secret is not available, authenticator signatures cannot be validated, thus it is not possible to verify that the received response was sent to a proper request. Both the client and server side secrets are required for modifying the messages; for validating the authenticator signature, the server side secret is sufficient.
Changing the default behavior of commands can be done by
using the hash attribute request
. There is a similar attribute for responses called response
. These hashes are indexed by the type of the request/response. The possible values of these hashes are shown in the tables below. See Section 2.1, Policies for requests and responses for details.
Action | Description |
---|---|
RADIUS_REQ_ACCEPT | Allow the request to pass. |
RADIUS_REQ_REJECT | Block the request and report it to the client. |
RADIUS_REQ_ABORT | Terminate the connection. |
RADIUS_REQ_DROP | Block the request without further action. |
RADIUS_REQ_POLICY | Call the function specified to make a decision about the event. See Section 2.1, Policies for requests and responses for details. |
Table 4.46. Action codes for RADIUS requests
Action | Description |
---|---|
RADIUS_RSP_ACCEPT | Allow the response to pass. |
RADIUS_RSP_REJECT | Block the response and report it to the client. |
RADIUS_RSP_ABORT | Terminate the connection. |
RADIUS_RSP_DROP | Block the response without further action. |
RADIUS_RSP_POLICY | Call the function specified to make a decision about the event. See Section 2.1, Policies for requests and responses for details. |
Table 4.47. Action codes for RADIUS responses
Similar policies can be defined for RADIUS attributes. For easier use, predefined constants are available for the different attributes. The possible actions on the attributes are listed in the following table. The attribute constants are listed in Table A.2, RADIUS Protocol Attribute types described in RFC 2865. .
Action | Description |
---|---|
RADIUS_ATR_ACCEPT | Allow the attribute to pass. |
RADIUS_ATR_REJECT | Block the attribute and report it to the client. |
RADIUS_ATR_ABORT | Terminate the connection. |
RADIUS_ATR_DROP | Reject the entire message if it contains the specified attribute. |
RADIUS_ATR_POLICY | Call the function specified to make a decision about the event. See Section 2.1, Policies for requests and responses for details. |
RADIUS_ATR_ZERO |
An alias of RADIUS_ATR_DROP the action code.
|
RADIUS_ATR_ACCEPT_MAXONE | The message can contain zero or one of the specified attribute. |
RADIUS_ATR_ACCEPT_ONE | Accept exactly one attribute in the message. The message is rejected if it does not contain the specified attribute. This action can be used to check the existance of mandatory attributes. |
RADIUS_ATR_DROP_ONE | Drop the attribute from the message; the message itself is not rejected. |
Table 4.48. Action codes for RADIUS attributes
The RADIUS protocol does not guarantee the delivery of the messages (since it uses UDP), consequently packages are dropped if the system is overburden. Clients and servers attempt to send messages several times; allowing secondary sessions increases reliability and decreases server load. See Section 2.2, Secondary sessions for further information.
The RADIUS protocol is defined in RFC 2865.
The RADIUS Accounting protocol is defined in RFC 2866.
Class | Description |
---|---|
AbstractRadiusProxy | Class encapsulating the abstract RADIUS proxy. |
RadiusProxy | Default RADIUS proxy based on AbstractRadiusProxy. |
RadiusProxyStrict | RADIUS proxy based on AbstractRadiusProxy, allowing only a minimal command set. |
Table 4.49. Classes of the Radius module
This class implements the RADIUS protocol as described by RFC 2865.
client_secret (string, rw:r) | |
---|---|
Default: | |
Secret string (password) shared between the client (probably NAS) and Vela. Setting this value is not mandatory, but some of the proxy functions will not be available (see Section 4.16.2, Proxy behavior for details). |
permit_trailing_zeroes (boolean, rw:rw) | |
---|---|
Default: FALSE | |
Workaround for a Cisco bug (the router sometimes pads the packets with NUL bytes). |
rebuild_packets (boolean, rw:rw) | |
---|---|
Default: FALSE | |
Specifies whether to rebuild packets (requires both shared secrets to be available, see Section 4.16.2, Proxy behavior for details). |
request (complex, rw:rw) | |
---|---|
Default: | |
Normative policy hash for RADIUS request types indexed by the type of the request. See also Section 4.16.2.1, Configuring policies for RADIUS commands and responses. |
response (complex, rw:rw) | |
---|---|
Default: | |
Normative policy hash for RADIUS response types indexed by the type of the response. See also Section 4.16.2.1, Configuring policies for RADIUS commands and responses. |
secondary_mask (secondary_mask, rw:r) | |
---|---|
Default: 0xf | |
Specifies which connections can be handled by the same proxy instance (the same connection is enabled as secondary session by default). See Section 2.2, Secondary sessions for details. |
secondary_sessions (integer, rw:r) | |
---|---|
Default: 10 | |
Maximum number of allowed secondary sessions within a single proxy instance. See Section 2.2, Secondary sessions for details. |
server_secret (string, rw:r) | |
---|---|
Default: | |
Secret string (password) shared between the server and Vela. Setting this value is not mandatory, but some of the proxy functions will not be available (see Section 4.16.2, Proxy behavior for details). |
Default RADIUS proxy based on AbstractRadiusProxy allowing all well-formed RADIUS
packets (all requests, responses, and attributes) through the firewall. Secondary sessions are enabled for the same target (secondary_mask=0xC
) (maximum 10). For a stricter default configuration use the RadiusProxyStrict class.
Radius proxy strictly checking RFC compliance of the passing packets. Packets containing attributes that are not defined in the RFC are dropped.
The following requests and responses are permitted: radius_access_request; radius_access_challenge; radius_access_reject; radius_access_accept; radius_accounting_request; radius_accounting_response. All other requests and responses are rejected. The policy used for the attributes is listed in the Radius Appendix.
The Sip module defines the classes constituting the proxy for the Session Initiation Protocol (SIP).
SIP is a peer-to-peer protocol providing call processing functions and features similar to public switched telephone networks. The SIP protocol (or protocol family rather) is not a conventional Internet protocol, because it is not based on the traditional client-server model. Although there are prioritized servers for performing certain tasks, in most cases SIP phones function as both clients and servers on the network. Consequently, the protocol does not use the usual request/response based communication, and that has important consequences in perimeter defense.
The devices involved in SIP communication can have several different roles, but a single device can play the part of different roles at the same time. The most important roles are briefly summarized below:
User-agent: The phone itself. In the traditional model, this would be called client.
Registrar: The registration service. The address where a particular user-agent is accessible is registered here. It acts as a sort of a name service for the protocol.
Proxy: This device transmits the requests of the user-agents. It has nothing to do, and is not to be confused with a proxy firewall or with a web cache proxy.
Presence server: Similar to the registrar; this device stores information about the availability of the user-agents. Users can monitor if the VoIP devices of their contacts (friends, business partners, etc.) are active (i.e. on-line) via the presence server.
Back2back user-agent: This is a special proxy implementing the functions of two user-agents. On one side of a connection it acts as the caller, on the other side as the called party.
SIP is only involved in the signaling part of a communication session, and relies on other protocols to perform the actual data transfer. SIP communication takes place in multiple channels: one is the signaling channel, the other one the actual data channel used to transmit the voice and/or video data. This latter channel is opened dynamically according to parameters negotiated in the signaling channel. The negotiation uses a separate - embedded - protocol called Session Description Protocol (SDP) used to describe the channel and the type of media used in a session (i.e. the IP ports, codecs, etc.). It is essential for the firewall to understand and inspect the SDP protocol, since it contains all the information required to allow the VoIP traffic pass the firewall. The SDP traffic also has to be modified in case network address translation is performed. To transfer the actual voice, video, or other data, SIP uses the Real-time Transport Protocol (RTP). RTP defines a standardized packet format for delivering audio and video over the Internet, and is frequently used in audio/video streaming and conferencing solutions.
From the signaling point of view, it is important to note that there is no client/server hierarchy between the user-agents, only caller/called party. The signaling traffic is usually not transmitted directly between the user-agents, generally proxies and back2back user-agents are also involved. Consequently, signaling messages (for example a request and a corresponding answer) can take very different routes between two user-agents, greatly complicating the secure transmission of the protocol. On the other hand, the RTP session is built directly between the user-agents without the interaction of proxies, though back2back user-agents may still be involved in the transmission of the audio/video data. Therefore a special care must be taken when creating the access control rules of the SIP signaling and data traffic.
The SIP proxy allows SIP signaling (accepting SIP messages on the TCP port 5060) and the dynamic RTP traffic through the firewall without compromising the security of the firewall and the defended network. Ports are dynamically opened through the firewall based on information received in the signaling traffic. The signaling part of the protocol is inspected on the application level for protocol conformance: SIP proxy enforces the standards, protecting the network from attacks violating the protocol. This is especially important since SIP clients and even servers are rarely designed with security in mind and many of them have issues from a security point of view. As an application level gateway, PNS parses, checks, and rebuilds every passing signaling request and response. The actual (audio, video, etc.) communication is not inspected, it is forwarded through PNS on the kernel level using stateful package filtering. These connections are handled as related UDP connections. Furthermore, it is possible to perform NATing and connection marking (see the description of the SIP proxy classes for details).
When packets arrive to the port the SIP proxy is listening on, basic access control is performed based on the source IP address of the packets. Each and every request and response is inspected on the application level (Layer 7 in the OSI model). The requests and responses - including protocol elements like headers - are parsed and strictly checked for conformance with the SIP standards. The SIP proxy understands and enforces the SIP protocol as described in RFC 3261. The syntax and length of the various protocol elements (e.g.: length of lines, headers, requests, etc.) is checked in order to repel various attack forms based on malformed messages, such as buffer overflow attacks. The relation of the arriving packets relative to other packets and previous communication information is also inspected. Packets not conforming to the logic and workflow of the protocol (e.g.: responses without requests, etc.) are rejected. This step is important because SIP uses random ports for transferring the actual communication data (the RTP stream, e.g.: voice, video), and otherwise it would be possible to open covert channels through the firewall between machines, not only the intended VoIP communication between the two SIP endpoints (i.e. the caller and the receiver).
The payload (SDP) part of the communication is parsed as well and modified if network address translation (NAT) is used. In this case, the addresses and dynamic ports used by the RTP traffic stream have to be modified accordingly. After all these sanity checks the policy settings of the firewall are consulted. Address, and media type filtering is performed (e.g.: to allow only voice traffic to/from specific addresses). Network address translation is also performed at this step if required.
Access control on the RTP stream part of the protocol is performed separately. This is important because RTP and signaling streams can have different access control settings. If SIP servers or a SIP proxy is used on some part of the network, the signaling and the RTP streams originate from different sources. (In such situation, the signaling is originating from the proxy, but the RTP stream arrives directly from the actual client. However, such a situation could also be used to initiate covert channels.)
The proxy supports the use of secondary sessions as described in Section 2.2, Secondary sessions.
Keepalive messages in SIP are not originally part of the RFC. However, many SIP implementations actually use them, sending UDP packets (containing only whitespaces) to
maintain the connection. These packets are accepted if they are not longer than a preset value (see the max_keepalive_size
attribute of the AbstractSipProxy proxy class) and interprets them as keepalive messages. Such packets are uniformly replaced with UDP packets containing only a single line-feed.
The SIP proxy is capable of filtering the different media types in the SIP traffic based on their SDP headers using the media
hash attribute. The possible actions for the different media types are shown in the table below. See Section 2.1, Policies for requests and responses for details.
Action | Description |
---|---|
SIP_MEDIA_ACCEPT | Accept the media type. |
SIP_MEDIA_DROP | Drop the media from the list of proposed media channels but forward the message to the peer. |
SIP_MEDIA_ABORT | Drop the SIP message containing the corresponding media type. |
SIP_MEDIA_POLICY | Call the function specified to make a decision about the media type. The function receives two parameters: self, and the media type string. See Section 2.1, Policies for requests and responses for details. |
Table 4.50. Action codes for SIP media types.
Media types are the strings in SDP headers that identify the type of media sent in the channel (e.g.: audio
, video
, *
for all types, etc.). There are no predefined constants for the media types, as they are not defined in any RFCs or other standards. Typically, audio
and video
are used for voice and video streams, respectively.
The Session Initiation Protocol is described in RFC 3261.
The Session Description Protocol is described in RFC 2327.
RTP: A Transport Protocol for Real-Time Applications is described in RFC 3550.
Class | Description |
---|---|
AbstractSipProxy | Class encapsulating the abstract SIP proxy. |
SipProxy | Default SIP proxy class based on AbstractSipProxy. |
Table 4.51. Classes of the Sip module
This proxy implements the SIP protocol as specified in RFC 3261. Service definitions should refer to a customized class derived from AbstractSipProxy, or a predefined proxy class.
max_keepalive_size (integer, w:r) | |
---|---|
Default: 128 | |
Maximum size for SIP signaling keepalive messages in bytes. See Section 4.17.1.3, Keepalive messages in SIP for details. |
max_message_size (integer, w:r) | |
---|---|
Default: 65536 | |
Maximum allowed size of a SIP signaling message in bytes. |
secondary_mask (secondary_mask, rw:r) | |
---|---|
Default: 0xf | |
Specifies which connections can be handled by the same proxy instance. See Section 2.2, Secondary sessions for details. |
secondary_sessions (integer, rw:r) | |
---|---|
Default: 10 | |
Maximum number of allowed secondary sessions within a single proxy instance. See Section 2.2, Secondary sessions for details. |
This class encapsulates the default SIP proxy.
media (complex, rw:r) | |
---|---|
Default: | |
Policy hash implementing media type filtering, indexed
by the media type (as a string, e.g.: audio ). See Section 4.17.1.4, Configuring SIP policies for details.
|
The Socks module defines the classes for the proxy to inspect Socks communication.
SOCKS is a network protocol for routing packets using a proxy server between the clients and the servers. SOCKS performs at Layer 5 of the OSI model. SOCKS is typically used to proxy other, Layer 7 protocols, most often HTTP.
The proxy can authenticate the clients using passwords. GSS-API and other authentication methods supported by the SOCKSv5 protocol are not supported. The process of negotiating the authentication between the client and the Socks proxy is the following:
The client sends the list of authentication methods is supports to the SOCKS server.
The Socks proxy replies to the client on behalf of the SOCKS server, depending on the configuration of the Socks proxy:
If the client selected password-based authentication and the disable_auth_v5
option is set to FALSE
and the require_auth_v5
is set to TRUE
(which are the defaults), PNS replies that password authentication is supported.
If the require_auth_v5
is set to FALSE
, and the client supports the none
authentication method, the connection is accepted without authentication.
In other cases, the client receives an authentication error.
The Socks proxy supports inband authentication as well. For details on inband authentication, see Section 5.1.10, Class InbandAuthentication.
The SOCKS 5 protocol is defined in RFC 1928.
Class | Description |
---|---|
AbstractSocksProxy | Class encapsulating the Socks Proxy. |
SocksProxy | Default Socks proxy class based on AbstractSocksProxy. |
Table 4.52. Classes of the Socks module
This proxy validates SOCKS traffic. It serves as a starting point for customized proxy classes, but is itself not directly usable. Service definitions should refer to a customized class derived from AbstractSocksProxy, or the predefined SocksProxy proxy class.
auth (class) | |
---|---|
Default: | |
The authentication provider object used in the authentication process,
set in the authentication_policy() parameter
of the service. See Section 5.1.1, Authentication and authorization basics for details.
|
disable_auth_v5 (boolean) | |
---|---|
Default: FALSE | |
Disable authentication in the SOCKSv5 protocol. If this
option is enabled, the proxy sends only the
none authentication method to the client.
|
Method | Description |
---|---|
requestForward(self, ip, port) | Called when the SOCKS protocol reaches forward state. |
Table 4.53. Method summary
This method must determine whether to stack another proxy class into the traffic, or simply forward the traffic without analyzing. The method can raise an exception which will result in denying any traffic. The default behavior is to forward traffic without analyzing.
A default proxy for the SOCKS protocol based on AbstractSocksProxy. It serves as a starting point for customized proxy classes, but is itself not directly usable. Service definitions should refer to a customized class derived from AbstractSocksProxy, or the predefined SocksProxy proxy class. By default, the proxy rejects SOCKSv4 connections, and requires authentication from the clients.
This class implements parts of Oracle TNS (Transparent Network Substrate) to enable clients to communicate with Oracle servers behind firewalls using port TCP/1521. This module is especially needed when tnslsnr (the TNS listener) is in Multi-threaded Server (MTS) mode.
The SQL*Net proxy does not analyze the whole protocol stream, as the data protocol of Oracle operates on top of TNS.
An example for the SQL*Net connection string is provided in Example A.1, An example for the SQL*Net connection string .
SQLNetProxy is a module built for parsing messages of the SQL*Net protocol. It reads and parses QUERYs on the client side, and sends them to the server if the local security policy permits.
In MTS mode Oracle returns a redirect packet specifying where the client should connect to. The proxy processes this packet and initiates a new connection to the address specified; all packets sent by the client will be automatically redirected to this new address. This functionality is completely transparent to the clients. To accomplish this, either InbandRouter has to be used, or the overridable option has to be set for DirectedRouter and TransparentRouter.
SQLNet proxy is able to parse connect_string
and connection_data
containing the address
and port of the target server and information on the database.
When the connection is established the SQLNetProxy inspects TNS headers, but does not inspect the layers above TNS.
Class | Description |
---|---|
AbstractSQLNetProxy | Class encapsulating the abstract SQLNet proxy. |
SQLNetProxy | Default SQLNet proxy class based on AbstractSQLNetProxy. |
Table 4.54. Classes of the SQLNet module
AbstractSQLNetProxy is a default proxy for the SQL*Net protocol - it serves as a starting point for customized proxy classes, but is itself not directly usable. Service definitions should refer to a customized class derived from AbstractSQLNetProxy, or the predefined proxy class.
connect_data (string, n/a:rw) | |
---|---|
Default: n/a | |
The TNS connect string as sent by the client, or as modified by the policy. |
split_connect_threshold (integer, rw:rw) | |
---|---|
Default: 231 | |
CONNECT data that is larger than this value will be split into smaller DATA packets. |
Method | Description |
---|---|
connectRequest(self, connect_data) | Function called when the client issues a CONNECT request. |
Table 4.55. Method summary
This function is called when the client issues a CONNECT request,
to have a chance to validate and change the CONNECT string sent by
the client. The connect string can be found
in the parameter connect_data
. The function has to return a logical TRUE
or FALSE
value, i.e. SQLNET_ACCEPT
or SQLNET_ABORT
.
A transparent SQL*Net proxy based on AbstractSQLNetProxy.
In transparent mode the client addresses directly the server, so the target address is readily available; while in nontransparent mode the client connects directly to Vela, and Vela receives the address of the server within the protocol.
Secure Shell (SSH) is a protocol designed to remotely access (login and execute commands) on a computer connected to the network. SSH was aimed to replace the earlier unencrypted protocols (e.g.: rlogin, TELNET and rsh), and provides secure encrypted communication between two hosts over an insecure network. Users of SSH can also use it for tunneling, forwarding arbitrary TCP ports and X11 connections over the resultant secure channel; and can transfer files using the embedded SFTP or SCP protocols.
One of the main features of the SSH protocol is that almost the entire communication between the client and the server is encrypted - including the authentication of the user. (Naturally, the negotiation of the encryption method to be used is in plain text). During the initialization of the session server authentication is performed and parameters for encryption, data compression and integrity verification of the data transferred are negotiated. The protocol enforces user authentication and is capable of authenticating the user via various methods: password, RSA key, Challenge/Response schemes like S/Key and OPIE, etc.
The typical uses of SSH include the following:
Remotely administer a computer via an interactive terminal console. This is one of the most widespread uses of SSH.
Execute commands on the remote machine. Remote command execution can also result in significant data transfer, for example when performing scheduled or manual tasks such as file copying (scp), data or file synchronization (rsync), creating archive backups (tar), etc.
It is possible to tunnel any TCP/IP connection from the client or from the server into the encrypted SSH channel. It can also be used to forward communication otherwise not allowed, such as the access of ports banned by the security policy. This allows to secure any - normally unencrypted - data transfer and is frequently used as an easy way to secure connections between the hosts without the need to set up full VPN connections.
Securely transfer files using SFTP.
Applications running on the server and requiring graphical interface (X Window) appear on the client's monitor, but run on the server in all other respect, thus it is possible to work with them remotely.
Transfer authentication requests to the client machine.
The original version of the protocol (SSH-1, dated 1995) has been revised in 1996, and SSH-2 was created offering improved security and new features. The two versions of the protocol are incompatible with each other. Since SSH-1 has inherent design flaws and is vulnerable to attacks, it is now generally considered obsolete and its use should not be permitted. Practically all server and client applications today support SSH-2, however, software not supporting SSH-2 may still be in use by some organizations, posing a considerable security vulnerability to them.
The SSH proxy supports only the SSHv2 protocol (SECSH).
SSH proxy uses man-in-the-middle technique to decrypt and terminate the SSH connections on the firewall. It separates the connections into two parts and inspects all traffic, so that no data can be directly transferred between the server and the client. Only the SSH-2 protocol is supported exclusively, but owing to the widespread use and availability of SSH-2 implementations, this does not mean any hindrance. The general capabilities of SSH proxy are summarized below.
Protocol inspection : All traffic is inspected and only permitted across the firewall if it fully complies to the SSH-2 protocol. This feature provides effective protection against a great number of attacks exploiting vulnerabilities of server and client applications, including buffer overflow vulnerabilities.
Verify encryption method : The internal parameters of the connections can also be controlled, allowing the proxy to enforce the use of selected encryption methods (cipher type, key length, etc.), thus provide protection against downgrade attacks.
Control user authentication : The different authentication methods can be separately enabled or disabled, e.g.: it is possible to enforce the use of strong authentication methods by completely disabling password based authentication. User-level filtering and access control can also be performed. Although this can obviously be done on the servers themselves, PNS as an external device provides these features reliably even if the server or the client machines get compromised.
Control of SSH channels : There is full control over the SSH channels, i.e. it can be specified which channels are allowed to and from a given server or in a given connection. For instance, file transfer, port forwarding, or X forwarding can be separately enabled/disabled based on various criteria.
Disable agent forwarding : Agent forwarding can be disabled, thus prevent that the keys used in the internal network become accessible on external machines.
Control remote command execution : The SSH protocol can be fully inspected, thus it can be specified which commands are allowed, which ones are disabled. More sophisticated decisions can also be made based on the parameters of the session, e.g.: to allow the execution of a command only to certain users, etc.
The opening of SSH channels from the server and the client side is possible
using the server_channel
and
client_channel
hashes. These hashes are indexed by the
channel type (e.g.: session
). The available channel types
are listed in the following table.
Name | Value |
---|---|
session | Channels for terminal shells, remote execution requests (e.g.: scp), and SFTP. |
direct-tcpip | Channels for client-to-server forwarded connections. |
forwarded-tcpip | Channels for server-to-client forwarded connections. |
auth-agent | Channels for forwarding authentication agents. |
auth-agent@openssh.com | Channels for forwarding authentication agents, as implemented in OpenSSH. |
x11 | Channels for forwarding graphical interfaces. |
Table 4.56. The list of available channel types.
The possible actions are described in the following table. See also Section 2.1, Policies for requests and responses.
Action | Description |
---|---|
SSH_CHAN_ACCEPT | Accept the request without any modification. |
SSH_CHAN_REJECT | Reject the channel opening request. |
SSH_CHAN_POLICY | Call the function specified to make a decision about the channel opening request. |
SSH_CHAN_ABORT | Reject the channel opening request and terminate the connection. |
Table 4.57. Action codes for SSH channel open requests.
Changing the default behavior of requests arriving from the server and the
client side is possible using the server_request
and
client_request
attributes. All
requests specified in the RFCs are supported. The index of these hashes
is composed of the channel type (e.g.:
session
, see Section 4.20.2.1, Configuring policies for SSH channels for a detailed list), a single
hyphen, and the request name as defined by the SSH protocol specification. E.g.:
session-x11-req
. The possible actions are described
in the following table. See also Section 2.1, Policies for requests and responses.
Action | Description |
---|---|
SSH_REQ_ACCEPT | Accept the request without any modification. |
SSH_REQ_REJECT | Reject the request. |
SSH_REQ_POLICY | Call the function specified to make a decision about the request. |
SSH_REQ_ABORT | Reject the request and terminate the connection. |
Table 4.58. Action codes for SSH channel and global requests.
For complex decisions that are based on the parameters of the requests,
you have to use the SSH_REQ_POLICY
parameter
and create a function within the proxy class that examines and
optionally modifies the parameters.
This custom function can receive the following four attributes:
self
side
The side of the connection relative to PNS:
0
for the client side, 1
for the server side.
index
The name of the request, e.g., x11
,
subsystem
, etc.
request
A structure that has fields containing the parameters of the request. See Section 4.20.2.3, Parameters of the SSH requests for details on the different request parameters.
See the following example.
Example 4.36. Enabling only SFTP connections |
---|
The following proxy class accepts SFTP connections.
SFTP is a subsystem of SSH, therefore the parameters of the
class SFtponlySshProxy(SshProxy): def config(self): SshProxy.config(self) self.client_channel["session"] = (SSH_CHAN_ACCEPT) self.client_request["session-subsystem"] = (SSH_REQ_POLICY, self.permitSFTPOnly) self.client_request["session-pty-req"] = (SSH_REQ_REJECT) self.client_request["session-shell"] = (SSH_REQ_REJECT) self.client_request["session-exec"] = (SSH_REQ_REJECT) def permitSFTPOnly(self, side, index, request): if request.subsystem == "sftp": return SSH_REQ_ACCEPT return SSH_REQ_REJECT |
SSH requests can be controlled using the server_request
and
client_request
hashes. These hashes are indexed by the
channel type (e.g.: session
). Some requests have
additional parameters that are also listed. Some channels (e.g., the X11 channel)
require two request messages to open, the first message requests the channel,
while the second message actually opens the requested channel.
The following requests are available from the client side. For examples on local and remote forwarding,
see Section 4.20.2.4, Configuring local and remote forwarding.
window-change | |
---|---|
When the window (terminal) size changes on the client side a message may be sent to inform the server of the new window dimensions. Parameters of the request: | |
width_cols | Width of the terminal window in characters. |
height_rows | Height of the terminal window in characters. |
width_px | Width of the terminal window in pixels. |
height_px | Height of the terminal window in pixels. |
pty-req | |
---|---|
Request a pseudo-terminal for the session. Parameters of the request: | |
term | Requests a pseudo-terminal. |
width_cols | Width of the terminal window in characters. |
height_rows | Height of the terminal window in characters. |
width_px | Width of the terminal window in pixels. |
height_px | Height of the terminal window in pixels. |
x11-req | |
---|---|
Request X11 forwarding for the session. Parameters of the request: | |
x11_auth_proto | The name of the X11 authentication method used, e.g.,
MIT-MAGIC-COOKIE-1 . |
x11_auth_cookie | |
screen_number | |
single_connection | If set to TRUE , the server forwards only a single
connection. |
x11 | |
---|---|
Open an X11 channel. Parameters of the request: | |
originator_host | IP address of the host. |
originator_port | Port number of the host. |
auth-agent-req | |
---|---|
Request the forwarding of the authentication requests. This request has no additional parameters. |
auth-agent-req@openssh.com | |
---|---|
Request the forwarding of the authentication requests, as implemented in OpenSSH. This request has no additional parameters. |
env | |
---|---|
Pass an environment variable and its value in the message. Parameters of the request: | |
name | The name of environment variable. |
value | The value of environment variable. |
shell | |
---|---|
Request a shell be started on the server side. This request has no additional parameters. |
exec | |
---|---|
Request the server to start the execution of the command sent in the message. Parameters of the request: | |
command | The command to be executed. The command may include a path. |
subsystem | |
---|---|
Request the server to execute a predefined subsystem. (Subsystems usually include a general file transfer mechanism, and possibly other features as well.) Parameters of the request: | |
subsystem | Name of the subsystem to be executed. |
signal | |
---|---|
A signal delivered to the remote process or service. Parameters of the request: | |
signal | Name of the signal to be sent. |
The following requests are available from the server side. Some requests have additional parameters that are also listed.
exit-status | |
---|---|
When the command running on the server terminates, an exit-status message can be sent to return the exit status of the command. | |
exit_status |
exit-signal | |
---|---|
A message indicating that the remote command was terminated violently due to a signal. A zero usually means that the command terminated successfully. | |
signal_name | Name of the signal. One of: ABRT ,
ALRM , FPE ,
HUP , ILL ,
INT , KILL ,
PIPE , QUIT ,
SEGV , TERM ,
USR1 , USR2 , or a custom signal
consisting of two strings and the @ character (e.g.,
signal@ example ). |
core_dumped | |
error | The text of the error message. The message may consist of multiple lines separated by CRLF (Carriage Return - Line Feed) pairs. |
lang | Language tag confirming to RFC3066. |
xon-xoff | |
---|---|
A message informing the client when it can or cannot perform flow control. | |
client_can_do |
TRUE if the client can perform flow
control. |
Remote port-forwarding transfers connections arriving to a port of
the server to the client. The client sends a
global-tcpip-forward
request to the server.
The parameters of this request tell the server which address and
port it should listen on for incoming connections (
bind_address
, bind_port
).
When the server receives a connection to this address/port pair,
it opens a forwarded-tcpip
towards the client.
The parameters of these requests are summarized in the following tables.
global-tcpip-forward | |
---|---|
Connections arriving to the specified IP address and port of the server are forwarded to the client. | |
bind_address |
The server forwards connections received on this address to the client. The following special addresses may be used:
|
bind_port | The server forwards connections received on this port to the client. |
forwarded-tcpip | |
---|---|
Opens a channel used to forward remote connections to the client. | |
connected_addr | The IP address of the server that received the connection. |
connected_port | The port of the server that received the connection. |
originator_addr | The IP address of the remote host whose connection is forwarded to the client. |
originator_port | The port of the remote host whose connection is forwarded to the client |
Local port-forwarding transfers connections arriving to the client
from a host to a remote host via the SSH server. For local port-forwarding,
the client sends a
direct-tcpip
channel opening request to the
server. The parameters of this request tell the server which host it should
forward the connection, as well as the address of the host that connects to the client
(usually localhost).
This request has the following parameters.
direct-tcpip | |
---|---|
Opens a channel used to forward remote connections to the client. | |
originator_addr | The IP address of the host whose connection is forwarded to the remote host. |
originator_port | The port of the host whose connection is forwarded to the remote host. |
host_addr | The IP address of the remote host that is the destination of the forwarded connection. |
host_port | The port of the remote host that is the destination of the forwarded connection. |
The SSH proxy is able to enforce policies on the various elements of the encrypted SSH communication, such as the MAC, key-exchange, etc. algorithms that are permitted to be used. The parameters can be set separately for the client and for the server side. The attributes are represented as comma-separated strings listing the enabled methods/algorithms, in the order of preference.
Key exchange algorithms
The permitted key exchange algorithms can be specified via the
client_kex_algos
and
server_kex_algos
attributes. The SSH proxy supports
the diffie-hellman-group16-sha512
and
diffie-hellman-group18-sha512
and
diffie-hellman-group14-sha256
and
diffie-hellman-group14-sha1
and
diffie-hellman-group1-sha1
algorithms.
Host key algorithms
The permitted host key algorithms can be specified via the
client_hostkey_algos
and
server_hostkey_algos
attributes. The supported
algorithms are ssh-rsa, rsa-sha2-256, rsa-sha2-512
and
ssh-dss
.
Note |
---|
For a hostkey algorithm to work for the clients the corresponding private
key has to be set in the |
Public key algorithms
The permitted public key algorithms can be specified via the
client_pubkey_algos
and
server_pubkey_algos
attributes. The supported
algorithms are ssh-rsa, rsa-sha2-256, rsa-sha2-512
and
ssh-dss
.
Symmetric cipher algorithms
The permitted symmetric cipher algorithms can be specified via the
client_cipher_algos
and
server_cipher_algos
attributes. The following
algorithms are supported: aes128-cbc
,
3des-cbc
, blowfish-cbc
,
cast128-cbc
, arcfour
,
aes192-cbc
, aes256-cbc
,
aes128-ctr
, aes192-ctr
,
aes256-ctr
, aes128-gcm@openssh.com
,
aes256-gcm@openssh.com
.
MAC algorithms
The permitted MAC algorithms can be specified via the
client_mac_algos
and
server_mac_algos
attributes. The supported algorithms
are: hmac-sha2-256
and
hmac-sha2-512
and hmac-sha1
and
hmac-md5
.
To successfully build the required SSH connections both towards the client
and the server, PNS has to show the appropriate keys to the client (otherwise
the client will reject the connection as the key does not match the server it
intends to connect). This problem can be easily overcome if PNS is used to
protect the servers: the server key has to be deployed on PNS as well. However,
this is not possible when protecting clients, because the private keys of all
servers that will be contacted is rarely available. In this case, SSH
proxy can be configured to automatically verify the identity of the server
using the server_hostkeys_verify
attribute. This
is similar to certificate verification in SSL connections, but in SSH there is
no certificate or other identity information attached to the host keys.
The methods supported for host key verification are shown in the following table.
Name | Value |
---|---|
SSH_HKV_ACCEPT_ANY | Accept any host key. |
SSH_HKV_ACCEPT_ONCE | Accept unknown host keys only on the first occassion. The IP address-port pair of unknown host keys is registered, later on that key is used to verify connections from that address. |
SSH_HKV_ACCEPT_KNOWN |
Accept only known host keys. Public keys can be configured for each IP address or port pair (like in case of the known_hosts file). For any unknown IP address-port pair the connection is terminated.
|
Table 4.59. SSH host key verification mode.
The SSH proxy supports the general auditing framework of PNS. The SSH
proxy can even be configured to audit only certain types of channels,
it is not necessary to fully audit all sessions (e.g.: the auditing
of large file transfers such as backups is rarely needed). The
channels to be audited can be set via the
audit_trails
attribute. The available channel
types are described in Section 4.20.2.1, Configuring policies for SSH channels.
The SSH proxy can use different keys in the server-side
connection and the client-side connection. To use this feature,
you have to derive a custom proxy class from the SshProxy class, and
override the mapUserKey
function. In the
mapUserKey
function, you can check the public
key of the client, and return the private key that will be used in the
server-side connection. Using this function you can set
every connection to use a single key on the server side, change the type
of the key from RSA to DSA, or restrict access of certain
channels only to the selected users.
The mapUserKey
function receives the
blob_type
and blob
parameters
that contain the type of the key (ssh-dss
for
DSA keys, ssh-rss
for RSA keys) and the public key of
the client. The function can return None
to reject the connection, or a key type and a private key that will
be used to authenticate on the target server.
The Secure Shell (SSH) Protocol is described in the following RFCs:Architecture is described in RFC 4251.
The Secure Shell (SSH) Protocol Architecture is described in RFC 4251.
The Secure Shell (SSH) Authentication Protocol is described in RFC 4252.
The Secure Shell (SSH) Transport Layer Protocol is described in RFC 4253.
The Secure Shell (SSH) Connection Protocol is described in RFC 4254.
Class | Description |
---|---|
AbstractSshProxy | Class encapsulating the abstract SSH proxy. |
SshProxy | Class encapsulating the abstract SSH proxy. |
SshProxySftpOnly | Ssh proxy based on SshProxy, allowing SFTP access only. |
SshSFtpProxy | Class encapsulating an SFTP proxy. |
SshScpProxy | Class encapsulating an SCP proxy. |
Table 4.60. Classes of the Ssh module
This class implements an abstract SSH proxy for the SSH2 protocol - it serves as a starting point for customized proxy classes, but is itself not directly usable. Service definitions should refer to a customized class derived from AbstractSshProxy, or one of the predefined proxy classes.
audit_channels (string, rw:r) | |
---|---|
Default: "" | |
A comma separated list of channel types to be audited. See also Section 4.20.2.7, Auditing SSH channels. |
auth_agent_forward (boolean, w:r) | |
---|---|
Default: FALSE | |
Authenticate using the data received from the agent during agent-forwarding. |
client_channel (complex, r:r) | |
---|---|
Default: | |
A normative policy hash defining the action to take when a specific channel type is opened on the client side. See Section 4.20.2.1, Configuring policies for SSH channels for details. |
client_cipher_algos (string, rw:r) | |
---|---|
Default: "aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,3des-cbc,arcfour" | |
A comma separated list of symmetric cipher algorithms permitted on the client side, in the order of preference. See Section 4.20.2.5, Configuring encryption parameters for details. |
client_comp_algos (string, rw:r) | |
---|---|
Default: | |
A comma separated list of compression algorithms, in the order of preference. Currently no compression algorithm is supported. |
client_hostkey_algos (string, rw:r) | |
---|---|
Default: "rsa-sha2-512,rsa-sha2-256,ssh-rsa,ssh-dss" | |
A comma separated list of hostkey algorithms permitted on the client side, in the order of preference. See Section 4.20.2.5, Configuring encryption parameters for details. |
client_kex_algos (string, rw:r) | |
---|---|
Default: "diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1" | |
A comma separated list of allowed key exchange algorithms permitted on the client side, in the order of preference. See Section 4.20.2.5, Configuring encryption parameters for details. |
client_mac_algos (string, rw:r) | |
---|---|
Default: "hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-md5" | |
A comma separated list of MAC algorithms, in the order of preference. See Section 4.20.2.5, Configuring encryption parameters for details. |
client_pubkey_algos (string, rw:r) | |
---|---|
Default: "rsa-sha2-512,rsa-sha2-256,ssh-rsa,ssh-dss" | |
A comma separated list of public key algorithms permitted on the client side, in the order of preference. See Section 4.20.2.5, Configuring encryption parameters for details. |
client_request (complex, r:r) | |
---|---|
Default: | |
A normative policy hash defining the action to take when a specific channel request is received from the client side. See Section 4.20.2.2, Configuring policies for SSH requests for details. |
connection_start (enum, rw:r) | |
---|---|
Default: SSH_CONN_START_IMMEDIATELY | |
Specifies when is the server-side connection started. When using agent authentication, set it to SSH_CONN_START_AFTER_PROXY_AUTH .
|
host_key_x509_dss (string, rw:r) | |
---|---|
Default: | |
The DSS host key in openssl PEM format used when communicating
with SSH clients. Either host_key_rsa
or host_key_dss is required.
|
host_key_x509_dss_certificate (string, rw:r) | |
---|---|
Default: | |
The DSS host key in openssl PEM format used when communicating
with SSH clients. Either host_key_rsa
or host_key_dss is required.
|
host_key_x509_dss_files (certificate, rw:r) | |
---|---|
Default: | |
A tuple of two file names containing the certificate and key files for the DSS host key in PEM format. |
host_key_x509_rsa (string, rw:r) | |
---|---|
Default: | |
The RSA host key in openssl PEM format used when communicating
with SSH clients. Either host_key_rsa
or host_key_dss is
required.
|
host_key_x509_rsa_certificate (string, rw:r) | |
---|---|
Default: | |
The RSA host key in openssl PEM format used when communicating
with SSH clients. Either host_key_rsa
or host_key_dss is
required.
|
host_key_x509_rsa_files (certificate, rw:r) | |
---|---|
Default: | |
A tuple of two file names containing the certificate and key files for the RSA host key in PEM format. |
max_kbdint_prompt_len (integer, rw:r) | |
---|---|
Default: 128 | |
Specifies the maximum length of a prompt in the keyboard-interactive authentication method. |
max_kbdint_prompts (integer, rw:r) | |
---|---|
Default: 10 | |
Specifies the maximum number of prompts in the keyboard-interactive authentication method. |
max_kbdint_response_len (integer, rw:r) | |
---|---|
Default: 128 | |
Specifies the maximum length of a response in the keyboard-interactive authentication method. |
server_channel (complex, r:r) | |
---|---|
Default: | |
A normative policy hash defining the action to take when a specific channel type is opened on the server side. See Section 4.20.2.1, Configuring policies for SSH channels for details. |
server_comp_algos (string, rw:r) | |
---|---|
Default: | |
A comma separated list of compression algorithms permitted on the server side, in the order of preference. Currently no compression algorithm is supported. |
server_hostkey_algos (string, rw:r) | |
---|---|
Default: "rsa-sha2-512,rsa-sha2-256,ssh-rsa,ssh-dss" | |
A comma separated list of hostkey algorithms permitted on the server side, in the order of preference. See Section 4.20.2.5, Configuring encryption parameters for details. |
server_kex_algos (string, rw:r) | |
---|---|
Default: "diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1" | |
A comma separated list of key exchange algorithms permitted on the server side, in the order of preference. See Section 4.20.2.5, Configuring encryption parameters for details. |
server_mac_algos (string, rw:r) | |
---|---|
Default: "hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-md5" | |
A comma separated list of MAC algorithms permitted on the server side, in the order of preference. See Section 4.20.2.5, Configuring encryption parameters for details. |
server_pubkey_algos (string, rw:r) | |
---|---|
Default: "rsa-sha2-512,rsa-sha2-256,ssh-rsa,ssh-dss" | |
A comma separated list of public key algorithms permitted on the server side, in the order of preference. See Section 4.20.2.5, Configuring encryption parameters for details. |
server_request (complex, r:r) | |
---|---|
Default: | |
A normative policy hash defining the action to take when a specific channel request is received from the server side. See Section 4.20.2.2, Configuring policies for SSH requests for details. |
timeout (integer, rw:r) | |
---|---|
Default: 600000 | |
I/O timeout in milliseconds. If no activity is detected within this period interval, the connection is terminated. |
This proxy implements a default SSH proxy based on
AbstractSshProxy.
A number of higher-level attributes have been defined that allow easy
configuration of the various services offered by SSH (e.g.: port-forwarding, etc.).
Port-forwarding, X11-forwarding, and agent-forwarding are disabled by default,
the clients may open only session
channels.
The following client requests are accepted in the channel:
window-change
, pty-req
,
shell
, exec
,
subsystem
, signal
,
exit-status
, exit-signal
,
and xon-xoff
. The env
request is not permitted. Only known host keys are accepted on the server side.
host_key_dss_file (certificate, rw:r) | |
---|---|
Default: "" | |
Read the DSS hostkey from the file specified. This must be DSA, not RSA. |
host_key_rsa_file (certificate, rw:r) | |
---|---|
Default: "" | |
Read the RSA hostkey from the file specified. This must be RSA, not DSA. |
server_hostkeys_verify (enum, rw:r) | |
---|---|
Default: SSH_HKV_ACCEPT_KNOWN | |
The verification mode for SSH host keys. See Section 4.20.2.6, Host key verification. |
Method | Description |
---|---|
checkUserKey(self, blob_type, blob) | None |
mapUserKey(self, blob_type, blob) | None |
Table 4.61. Method summary
This method is called by the proxy to check the publickey. It returns FALSE if it cannot be accepted, TRUE otherwise.
Ssh proxy based on SshProxy, allowing SFTP access only. Commands other than 'sftp' subsystem request are rejected.
This class implements an SFTP helper to be stacked into an SSH proxy parent.
The TFtp module defines the classes constituting the proxy for the TFTP protocol.
Trivial File Transfer Protocol (TFTP) is a very simple protocol used to transfer files over the UDP transport protocol. It is commonly used for bootstrapping diskless systems (normally workstations or routers).
The protocol follows a very simple procedure. The client sends a request to read (RRQ) or write (WRQ) a file to the server's UDP/69 port. If the server grants the request a connection is opened and the file server starts sending the file in fixed length blocks of 512 bytes. TFTP transports data in netascii encoding format (ASCII text with each line terminated by the 2-character sequence of a carriage return followed by a linefeed called CR/LF) or octet (data as 8-bit bytes with no interpretation) which is set by the mode indicator at the end of the RRQ/WRQ message. The DATA packet also contains a block number which is used later for acknowledgment. Every packet sent must be acknowledged by the receiver, which guarantees that the previous packet has been received. If a packet is lost the receiver sends a request after a timeout. The server keeps just one packet in store for retransmission until the acknowledgment arrives. A packet shorter than 512 bytes indicates the end of the transmission.
Most errors cause termination of the transfer process and are signaled by the sending of an error packet. This is neither acknowledged nor retransmitted. If an error occurred, then an ERROR packet is sent. If a network error occurred then even the ERROR packet might get lost, therefore timeout is also used to detect errors.
Normal transmission termination is started by a packet smaller than 512 bytes. The packet is acknowledged by a normal ACK packet like all the previous packet. Then the host sends the final ACK and waits for a while before it terminates the transmission. If the final ACK is not acknowledged or the the connection timed out the final ACK packet is retransmitted.
TFTP supports five types of packets, all of which have been mentioned above:
1 - Read request (RRQ)
2 - Write request (WRQ)
3 - Data (DATA)
4 - Acknowledgment (ACK)
5 - Error (ERROR), which can contain the following error messages:
0 - Not defined, see error message (if any).
1 - File not found.
2 - Access violation.
3 - Disk full or allocation exceeded.
4 - Illegal TFTP operation.
5 - Unknown transfer ID.
6 - File already exists.
7 - No such user.
TFtpProxy is a module built for parsing messages of the TFTP protocol. It reads and parses REQUESTs on the client side, and sends them to the server if the local security policy permits. The answers are similarly parsed and returned to the client if the local security policy permits. Rewriting the requested filename and encoding is supported (although transcoding is not).
One proxy instance is able to handle more than one session, if the Router and Chainer classes support fast path operation (currently this is supported in DirectedRouter). This functionality is similar to, but different from the secondary session handling used in PlugProxy and RadiusProxy. In TftpProxy the parameters of secondary sessions cannot be set, they are managed automatically based on the logic of the protocol.
Changing the default behaviour of requests is possible using the
request
attribute. This hash is indexed by the request method ("read" or
"write"), and the requested filename. If the hash contains no
entry for a given combination, the "*" entry is used. If there is
no matching entry in the hash, the command is rejected. The possible actions are described in the following table. See also Section 2.1, Policies for requests and responses.
Action | Description |
---|---|
TFTP_REQ_ACCEPT | Allow the request to pass. |
TFTP_REQ_REJECT | Reject the request and send an error message. Message code and text can be specified as second and third elements of the tuple. |
TFTP_REQ_DROP | Drop the packet. |
TFTP_REQ_POLICY | Call the function specified to make a decision about the event. The function receives four parameters: self, the method ("read"/"write"), the file name and the encoding used in the request. See Section 2.1, Policies for requests and responses for details. |
TFTP_REQ_REWRITE | Rewrite filename and/or encoding and accept the packet. See Section Rewriting the request for details. |
Table 4.62. Action codes on TFTP requests
To rewrite and accept a request, the hash value must be a tuple containing TFTP_REQ_REWRITE as the first value, and the filename and encoding to be sent to the server as the second and third values.
To respond with a user-defined error code and message, the hash value must be a tuple containing TFTP_REQ_ERROR as the first value, the error code (an integer as defined by the TFTP RFC) as the second one, and the error message as the third. The session is (obviously) terminated; the TFTP server is not notified.
Class | Description |
---|---|
AbstractTFtpProxy | Class encapsulating the abstract TFtp proxy. |
TFtpProxy | Default TFtp proxy class based on AbstractTFtpProxy. |
Table 4.63. Classes of the TFtp module
This class implements the TFTP protocol as described in RFC 1350. It serves as a starting point for customized proxy classes, but is itself not directly usable. Service definitions should refer to a customized class derived from AbstractTFtpProxy, or the predefined TFtpProxy proxy class.
request (complex, rw:rw) | |
---|---|
Default: | |
Normative policy hash for TFTP requests indexed by the request method and the filename. See also Section 4.21.2.1, Configuring policies for TFTP commands. |
VNC protocol is for accessing the desktop of remote computers.
Class | Description |
---|---|
AbstractVncProxy | Class encapsulating the abstract Vnc proxy. |
VncProxy | Default Vnc proxy based on AbstractVncProxy. |
Table 4.64. Classes of the Vnc module
This class implements the VNC protocol. AbstractVncProxy serves as a starting point for customized proxy classes, but is itself not directly usable. Service definitions should refer to a customized class derived from AbstractVncProxy, or one of the predefined VncProxy proxy classes.
This chapter provides detailed description for the core modules of PNS.
This module contains classes related to authentication and authorization. Together with the AuthDB module it implements the Authentication and Authorization framework.
User authentication verifies the identity of the user trying to access a particular network service. When performed on the connection level, that enables the full auditing of the network traffic. Authentication is often used in conjunction with authorization, allowing access to a service only to clients who have the right to do so.
Authentication is a method to ensure that certain services (access to a server, etc.) can be used only by the clients allowed to access the service. The process generally called as authentication actually consists of three distinct steps:
Identification: Determining the clients identity (e.g.: requesting a username).
Authentication: Verifying the clients identity (e.g.: requesting a password that only the real client knows).
Authorization: Granting access to the service (e.g.: verifying that the authenticated client is allowed to access the service).
Note |
---|
It is important to note that although authentication and authorization are usually used together, they can also be used independently. Authentication verifies the identity of the client. There are situations where authentication is sufficient, because all users are allowed to access the services, only the event and the user's identity has to be logged. On the other hand, authorization is also possible without authentication, for example if access to a service is time-limited (e.g.: it can only be accessed outside the normal work-hours, etc.). In such situations authentication is not needed. |
PNS can authenticate and authorize access to the services. The aim of authentication is to identify the user and the associated group memberships. When the client initiates a connection, it actually tries to use a service. PNS checks if an authentication policy is associated to the service. If an authentication policy is present, PNS contacts the authentication provider specified in the authentication policy. The type of authentication (the authentication class used, e.g., InbandAuthentication) is also specified in the authentication policy. The authentication provider connects to an authentication backend (e.g., a user database) to perform the authentication of the client - PNS itself does not directly communicate with the database.
If the authentication is successful, the client is verified if it is allowed to access the service (by evaluating the authorization policy and the identity and group memberships of the client). If the client is authorized to access the service, the server-side connection is built. The client is automatically authorized if no authorization policy is assigned to the service.
Currently only one authentication provider, the Authentication Server (AS) is available via the VAS2AuthenticationBackend class. Authentication providers are actually configured instances of the authentication backends, and it is independent from the database that the backend connects to. The authentication backend is that ties the authentication provider to the server storing the user data. For details on using AS, see the Connection authentication and authorization chapter of the PNS Administrator's Guide.
The aim of authentication is to identify
the user and resolve group memberships. The results are stored in
the in the auth_user
and auth_groups
attributes of the
session object.
Note that apart from the information required for authentication, PNS also sends session information
(e.g., the IP address of the client) to the authentication provider.
PNS provides the following authentication classes:
InbandAuthentication: Use the built-in authentication of the protocol to authenticate the client on the PNS.
ServerAuthentication: Enable the client to connect to the target server, and extract its authentication information from the protocol.
VAAuthentication: Outband authentication using the Authentication Agent.
If the authentication is successful, PNS verifies that the client is allowed to access the service (by evaluating the authorization policy). If the client is authorized to access the service, the server-side connection is built. The client is automatically authorized if no authorization policy is assigned to the service.
Each service can use an authorization policy to determine whether a client is allowed to access the service. If the authorization is based on the identity of the client, it takes place only after a successful authentication - identity-based authorization can be performed only if the client's identity is known and has been verified. The actual authorization is performed by PNS, based on the authentication information received from AS or extracted from the protocol.
PNS provides the following authorization classes:
PermitUser: Authorize listed users.
PermitGroup: Authorize users belonging to the specified groups.
PermitTime: Authorize connections in a specified time interval.
BasicAccessList: Combine other authorization policies into a single rule.
PairAuthorization: Authorize only user pairs.
NEyesAuthorization: Have another client authorize every connection.
Class | Description |
---|---|
AbstractAuthentication | Class encapsulating the abstract authentication interface. |
AbstractAuthorization | Class encapsulating the authorization interface. |
AuthCache | Class encapsulating the authentication cache. |
AuthenticationPolicy | A policy determining how the user is authenticated to access the service. |
AuthorizationPolicy | A policy determining how the user is authorized to access the service. |
BasicAccessList | Class encapsulating the authorization by access list. |
InbandAuthentication | Class encapsulating the inband authentication interface. |
NEyesAuthorization | Class encapsulating N eyes authorization. |
PairAuthorization | Class encapsulating pair-based 4 eyes authorization. |
PermitGroup | Class encapsulating the group membership based authorization. |
PermitTime | Class encapsulating time based authorization. |
PermitUser | Class encapsulating the user-name based authorization. |
ServerAuthentication | Class encapsulating the server authentication interface. |
VAAuthentication | Class encapsulating the outband authentication interface using the Authentication Agent. |
Table 5.1. Classes of the Auth module
This class encapsulates interfaces for inband and outband authentication procedures. Service definitions should refer to a customized class derived from AbstractAuthentication, or one of the predefined authentication classes, such as InbandAuthentication or VAAuthentication.
Method | Description |
---|---|
__init__(self) | Constructor to initialize an AbstractAuthentication instance. |
Table 5.2. Method summary
This class encapsulates an authorization interface. Authorization determines whether the authenticated entity is in fact allowed to access a specific service. Service definitions should refer to a customized class derived from AbstractAuthorization, or one of the predefined authorization classes, such as PermitUser or PermitGroup.
This class encapsulates an authentication cache which associates usernames with client IP addresses. The association between a username and an IP address is valid only until the specified timeout. Caching the authentication results means that the users do not need to authenticate themselves for every request: it is assumed that the same user is using the computer within the timeout. E.g.: once authenticated for an HTTP service, the client can browse the web for Timeout period, but has to authenticate again to use FTP.
To use a single authorization cache for every service request of a client, set
the service_equiv
attribute to TRUE
.
That way Vela does not make difference between the different services (protocols) used
by the client: after a successful authentication the user can use all available services
without having to perform another authentication. E.g.: if this option is enabled in the
example above, the client does not have to re-authenticate for starting an FTP
connection.
Method | Description |
---|---|
__init__(self, timeout, update_stamp, service_equiv, cleanup_threshold) | Constructor to initialize an instance of the AuthCache class. |
Table 5.3. Method summary
This constructor initializes and registers an AuthCache instance that can be referenced in authentication policies.
cleanup_threshold (integer) | |
---|---|
Default: 100 | |
When the number of entries in the cache reaches the value of
cleanup_threshold , old entries are automatically
deleted.
|
service_equiv (boolean) | |
---|---|
Default: FALSE | |
If enabled, then a single authentication of a user applies to every service from that client. |
update_stamp (boolean) | |
---|---|
Default: TRUE | |
If set to TRUE , then cached authentications increase
the validity period of the authentication cache. Otherwise, the authentication
cache expires according to the timeout value set in
attribute timeout.
|
Authentication policies determine how the user is authenticated to access
the service. The authentication_policy
attribute
of a service can reference an instance of the AuthenticationPolicy class.
Example 5.1. A simple authentication policy |
---|
The following example defines an authentication policy that can be referenced in service definitions. This policy uses inband authentication and references an authentication provider. AuthenticationPolicy(name="demo_authentication_policy", cache=None, authentication=InbandAuthentication(), provider="demo_authentication_provider") To use the authentication policy, include it in the definition of the service: Service(name="office_http_inter", proxy_class=HttpProxy, authentication_policy="demo_authentication_policy", authorization_policy="demo_authorization_policy") |
Example 5.2. Caching authentication decisions |
---|
The following example defines an authentication policy that caches the authentication decisions for ten minutes (600 seconds). For details on authentication caching, see Section 5.1.6, Class AuthCache). AuthenticationPolicy(name="demo_authentication_policy", cache=AuthCache(timeout=600, update_stamp=TRUE, service_equiv=TRUE, cleanup_threshold=100), authentication=InbandAuthentication(), provider="demo_authentication_provider") |
Method | Description |
---|---|
__init__(self, name, provider, authentication, cache) | Constructor to initialize an instance of the AuthenticationPolicy class. |
Table 5.4. Method summary
authentication (class) | |
---|---|
Default: None | |
The authentication method used in the authentication process. See Section 5.1.1, Authentication and authorization basics for details. |
provider (class) | |
---|---|
Default: n/a | |
The authentication provider object used in the authentication process. See Section 5.1.1, Authentication and authorization basics for details. |
Authorization policies determine how the user is authorized to access
the service. The authorization_policy
attribute
of a service can reference an instance of the AuthorizationPolicy class.
authorization (class) | |
---|---|
Default: n/a | |
The authorization method (e.g., PermitGroup ) used in the instance.
See Section 5.1.8, Class AuthorizationPolicy for examples. |
This class encapsulates an access list that uses any class derived from the AbstractAuthorization class. BasicAccessList allows to combine multiple access control requirements into a single decision.
BasicAccessList uses a list of rules. The rules
are evaluated sequentially. Each rule
can specify whether matching the current rule is Sufficient
or
Required
. A connection is
authorized if a Sufficient
rule matches
the connection, or all Required
rules
are fulfilled. If a Required
rule is
not met, the connection is refused.
Rules are represented as a list of Python tuples as the following example shows:
Method | Description |
---|---|
__init__(self, acl) | Constructor to initialize a BasicAccessList instance. |
Table 5.6. Method summary
This class encapsulates inband authentication. Inband
authentication is performed by the proxy using the
rules of the application-level protocol. Only the authentication methods
supported by the particular protocol can be used during inband authentication.
Authentication policies can refer to instances of the
InbandAuthentication class using the auth
parameter.
Warning |
---|
Inband authentication is currently supported only for the Http, Ftp, and Socks proxy classes. |
Method | Description |
---|---|
__init__(self) | Constructor to initialize an InbandAuthentication instance. |
Table 5.7. Method summary
This class encapsulates an N-eyes based authorization method, which means that connections are authorized if other administrators authenticate themselves within the defined timelimits.
When NEyesAuthorization
is used, the client trying to access
the service has to be authorized by another (already authorized) client (this
authorization chain can be expanded to multiple levels).
NEyesAuthorization
can only be used in conjunction with another
NEyesAuthorization
policy. One of them is the
authorizer set to authorize the authorized
policy.
In a simple 4-eyes scenario the authorizer policy points to the
authorized policy in its Authorization policy
parameter, and has
its wait_authorization
parameter
disabled. The authorized policy has an empty
Authorization policy
parameter (meaning that it is at lower the
end of an N-eyes chain), and has its wait_authorization
parameter enabled, meaning that it has to be authorized by another
policy.
For examples on using the NEyesAuthorization class, see the Proxying secure channels - SSH tutorial available from the BalsSys Documentation Page at http://www.docs.balasys.hu/.
Method | Description |
---|---|
__init__(self, authorize_policy, wait_authorization, wait_timeout) | Constructor to initialize a NEyesAuthorization instance. |
Table 5.8. Method summary
This constructor initializes an NEyesAuthorization instance.
authorize_policy (class) | |
---|---|
Default: None | |
The authorization policy authorized by the current
NEyesAuthorization policy.
|
This class encapsulates pair-based authorization
method. Only two users simultaneously accessing the
service are authorized, single users are not permitted to access the
service. Set the time (in milliseconds) Vela will wait for the
second user to access the service using
the wait_timeout
parameter.
Example 5.5. A simple PairAuthorization policy |
---|
The following example permits access to the service only if two users having different usernames authenticate successfully within one minute. AuthorizationPolicy(name="demo_pairauthorization_policy", authorization=PairAuthorization(wait_timeout=60000)) For more detailed examples, see the Proxying secure channels - SSH tutorial available from the BalaSys Documentation Page at http://www.balasys.hu/documentation/. |
Method | Description |
---|---|
__init__(self, wait_timeout) | Constructor to initialize a PairAuthorization instance. |
Table 5.9. Method summary
This constructor initializes a PairAuthorization instance.
This class encapsulates an authorization decision based on group membership. Users who authenticate as a member of a usergroup specified in the policy receive access to the service. Otherwise access is denied.
Method | Description |
---|---|
__init__(self, grouplist) | Constructor to initialize a PermitGroup instance. |
Table 5.10. Method summary
This class encapsulates an authorization decision based on the time when the connection is started. The connection is permitted if it is started in one of the permitted time periods (according to the system time of the host running Vela).
Specify the permitted time intervals as a comma-separated list, where
each element contains the beginning and ending time of the permitted interval
in HH:MM
format.
Method | Description |
---|---|
__init__(self, intervals) | Constructor to initialize a PermitTime instance. |
Table 5.11. Method summary
This class encapsulates an authorization decision based on usernames. Users who authenticate using one of the usernames specified in the policy receive access to the service. Otherwise access is denied.
Method | Description |
---|---|
__init__(self, userlist) | Constructor to initialize a PermitUser instance. |
Table 5.12. Method summary
This class encapsulates server authentication: Vela authenticates the user based on the response of the server to the user's authentication request. Server authentication is a kind of inband authentication, it is performed within the application protocol, but the target server checks the credentials of the user instead of Vela. This authentication method is useful when the server can be trusted for authentication purposes, but you need to include an authorization decision in the service definition.
Method | Description |
---|---|
__init__(self) | Constructor to initialize a ServerAuthentication instance. |
Table 5.13. Method summary
This class encapsulates outband authentication using the Authentication Agent (AA). The Authentication Agent is an application that runs on the client computers and provides an interface for the users to authenticate themselves when Vela requests authentication for accessing a service. This way any protocol, even those not supporting authentication can be securely authenticated. All communication between Vela and AA is SSL-encrypted.
Method | Description |
---|---|
__init__(self, pki, port, timeout, connect_timeout) | Constructor to initialize an instance of the VAAuthentication class. |
Table 5.14. Method summary
This constructor initializes an instance of the VAAuthentication authentication class that can be referenced in authentication policies to perform outband authentication.
connect_timeout (integer) | |
---|---|
Default: 60000 | |
Connection timeout (in milliseconds) to the Authentication Agent. |
pki (certificate) | |
---|---|
Default: None | |
A tuple containing the name of a certificate and a key file. Vela uses this certificate to encrypt the communication with the Authentication Agents. |
This module contains classes related to authentication databases. Together with the Auth module it implements the Authentication and Authorization framework. See Section 5.1.1, Authentication and authorization basics and Section 5.1.2, Authentication and authorization in PNS for details.
Class | Description |
---|---|
AbstractAuthenticationBackend | Class encapsulating the abstract authentication backend like AS. |
AuthenticationProvider | A database-independent class used by Vela to connect to an authentication backend. |
VAS2AuthenticationBackend | Class encapsulating the AS authentication backend. |
Table 5.15. Classes of the AuthDB module
This is an abstract class to encapsulate an authentication backend, which is responsible for checking authentication credentials against a backend database. In actual configurations, use one of the derived classes like VAS2AuthenticationBackend.
The interface defined here is used by various authentication methods like VAAuthentication and InbandAuthentication.
The authentication provider is an intermediate layer that mediates between Vela and the authentication backend (e.g., a user database) during connection authentication - Vela itself does not directly communicate with the database.
Example 5.10. A sample authentication provider |
---|
The following example defines an authentication provider that uses the VAS2AuthenticationBackend backend. AuthenticationProvider(name="demo_authentication_provider", backend=VAS2AuthenticationBackend(serveraddr=SockAddrInet('192.168.10.10', 1317), use_ssl=TRUE, ssl_verify_depth=3, pki_cert=("/etc/key.d/VAS_certificate/cert.pem", "/etc/key.d/VAS_certificate/key.pem"), pki_ca=("/etc/ca.d/groups/demo_trusted_group/certs/", "/etc/ca.d/groups/demo_trusted_group/crls/"))) |
Method | Description |
---|---|
__init__(self, name, backend) | Constructor to initialize an AbstractAuthorizationBackend instance. |
Table 5.16. Method summary
This class encapsulates the Authentication Server database and provides interface to other authentication classes to verify against users managed through AS. See Section 5.2.3, Class AuthenticationProvider for examples on using the VAS2AuthenticationBackend class.
Method | Description |
---|---|
__init__(self, serveraddr, use_ssl, pki_cert, pki_ca, ssl_verify_depth) | Constructor to initialize a VAS2AuthenticationProvider instance. |
Table 5.17. Method summary
This constructor creates a new VAS2AuthenticationProvider instance that can be used in authentication policies.
pki_ca (cagroup) | |
---|---|
Default: None | |
The name of a trusted CA group. When using SSL, AS must show a certificate signed by a CA that belongs to this group. |
pki_cert (certificate) | |
---|---|
Default: None | |
A tuple containing the name of a certificate and a key file. Vela shows this certificate to AS when using SSL. |
serveraddr (sockaddr) | |
---|---|
Default: n/a | |
The IP address of this AS instance. AS accepts connections on this address. |
Chainers establish a TCP or UDP connection between a proxy and a selected destination. The destination is usually a server, but the SideStackChainer connects an additional proxy before connecting the server.
The client-side and the server-side connections can use different networking protocols if needed.
The protocol
attribute of the chainer classes determines the network protocol used in the
server-side connection. By default, the same protocol is used in both connections.
The following options are available:
Name | Description |
---|---|
ZD_PROTO_AUTO | Use the protocol that is used on the client side. |
ZD_PROTO_TCP | Use the TCP protocol on the server side. |
ZD_PROTO_UDP | Use the UDP protocol on the server side. |
Table 5.18. The network protocol used in the server-side connection
Class | Description |
---|---|
AbstractChainer | Class encapsulating the abstract chainer. |
ConnectChainer | Class to establish the server-side TCP/IP connection. |
FailoverChainer | Class encapsulating the connection establishment with multiple target addresses and keeping down state between connects. FailoverChainer prefers connecting to target hosts in the order they were specified. |
MultiTargetChainer | Class encapsulating connection establishment with multiple target addresses. |
RoundRobinChainer | Class encapsulating the connection establishment with multiple target addresses and keeping down state between connects. |
SideStackChainer | Class to pass the traffic to another proxy. |
StateBasedChainer | Class encapsulating connection establishment with multiple target addresses and keeping down state between connects. |
Table 5.19. Classes of the Chainer module
AbstractChainer implements an abstract chainer that establishes a connection between the parent proxy and the selected destination. This class serves as a starting point for customized chainer classes, but is itself not directly usable. Service definitions should refer to a customized class derived from AbstractChainer, or one of the predefined chainer classes, such as ConnectChainer or FailoverChainer.
ConnectChainer is the default chainer class based on AbstractChainer. This class establishes a TCP or UDP connection between the proxy and the selected destination address.
ConnectChainer is used by default if no other chainer class is specified in the service definition.
ConnectChainer attempts to connect only a single destination address: if the connection establishment
procedure selects multiple target servers (e.g., a DNSResolver with the
multi=TRUE
parameter or a DirectedRouter with multiple
addresses), ConnectChainer will use the first address and ignore all other addresses. Use FailoverChainer to select from the destination from multiple addresses in a failover fashion, and RoundRobinChainer to distribute connections
in a roundrobin fashion.
Method | Description |
---|---|
__init__(self, protocol, timeout_connect) | Constructor to initialize an instance of the ConnectChainer class. |
Table 5.20. Method summary
This constructor creates a new ConnectChainer instance which can be associated with a Service.
protocol (enum) | |
---|---|
Default: VD_PROTO_AUTO | |
Optional parameter that specifies the network protocol used in the connection protocol. By default, the server-side communication uses the same protocol that is used on the client side. See Section 5.3.1, Selecting the network protocol for details. |
This class is based on the StateBasedChainer class and encapsulates a real TCP/IP connection establishment, and is used when a top-level proxy wants to perform chaining. In addition to ConnectChainer this class adds the capability to perform stateful, failover HA functionality across a set of IP addresses.
Note |
---|
Use FailoverChainer if you want to connect to the servers in a predefined order: i.e., connect to the first server, and only connect to the second if the first server is unavailable. If you want to distribute connections between the servers (i.e., direct every new connection to a different server to balance the load) use RoundRobinChainer . |
Method | Description |
---|---|
__init__(self, protocol, timeout_state, timeout_connect) | Constructor to initialize a FailoverChainer instance. |
Table 5.21. Method summary
This constructor initializes a FailoverChainer class by filling arguments with appropriate values and calling the inherited constructor.
protocol (enum) | |
---|---|
Default: VD_PROTO_AUTO | |
Optional, specifies connection protocol (
VD_PROTO_TCP or VD_PROTO_UDP
), when not specified it
defaults to the protocol used on the
client side.
|
This class encapsulates a real TCP/IP connection establishment, and is used when a top-level proxy wants to perform chaining. In addition to ConnectChainer, this class adds the capability to perform stateless, simple load balance server connections among a set of IP addresses.
The same mechanism is used to set multiple server addresses as
with a single destination address: the Router class sets a list
of IP addresses in the session.target_address
attribute.
Method | Description |
---|---|
__init__(self, protocol, timeout_connect) | Constructor to initialize a MultiTargetChainer instance. |
Table 5.22. Method summary
This constructor initializes a MultiTargetChainer class by filling arguments with appropriate values and calling the inherited constructor.
This class is based on the StateBasedChainer class and encapsulates a real TCP/IP connection establishment, and is used when a top-level proxy wants to perform chaining. In addition to ConnectChainer this class adds the capability to perform stateful, load balance server connections among a set of IP addresses.
This class encapsulates a special chainer. Instead of
establishing a connection to a server, it creates
a new proxy instance and connects the server side of the current (parent) proxy
to the client side of the new (child) proxy. The right_class
parameter specifies the child proxy.
It is possible to stack multiple proxies side-by-side. The final step of sidestacking is always to specify
a regular chainer via the right_chainer
parameter that connects the last proxy to the
destination server.
Tip |
---|
Proxy sidestacking is useful for example to create one-sided SSL connections. See the tutorials of the Balasys Documentation Page available at http://www.docs.balasys.hu/ for details. |
Method | Description |
---|---|
__init__(self, right_class, right_chainer) | Constructor to initialize an instance of the SideStackChainer class. |
Table 5.23. Method summary
This constructor creates a new FailoverChainer instance which can be associated with a Service.
This class encapsulates a real TCP/IP connection establishment, and is used when a top-level proxy wants to perform chaining. In addition to ConnectChainer, this class adds the capability to perform stateful, load balance server connections among a set of IP addresses.
Note |
---|
Both the FailoverChainer and RoundRobinChainer classes are derived from StateBasedChainer. |
Method | Description |
---|---|
__init__(self, protocol, timeout_connect, timeout_state) | Constructor to initialize a StateBasedChainer instance. |
Table 5.24. Method summary
This constructor initializes a StateBasedChainer class by filling arguments with appropriate values and calling the inherited constructor.
protocol (enum) | |
---|---|
Default: VD_PROTO_AUTO | |
Optional, specifies connection protocol (
VD_PROTO_TCP or VD_PROTO_UDP
), when not specified it
defaults to the same protocol used on the
client side.
|
Detectors can be used to determine if the traffic in the incoming connection uses a particular protocol (for example, HTTP, SSH), or if it has other specific characteristics (for example, it uses SSL encryption with a specific certificate). Such characteristics of the traffic can be detected, and start a specific service to inspect the traffic (for example, start a specific HttpProxy for HTTP traffic, and so on).
Class | Description |
---|---|
AbstractDetector | Class encapsulating the abstract detector. |
CertDetector | Class encapsulating a Detector that determines if an SSL/TLS-encrypted connection uses the specified certificate |
DetectorPolicy | Class encapsulating a Detector which can be used by a name. |
HttpDetector | Class encapsulating a Detector that determines if the traffic uses the HTTP protocol |
SniDetector | Class encapsulating a Detector that determines whether a client targets a specific host in a SSL/TLS-encrypted connection. |
SshDetector | Class encapsulating a Detector that determines if the traffic uses the SSHv2 protocol |
Table 5.25. Classes of the Detector module
This abstract class encapsulates a detector that determines whether the traffic in a connection belongs to a particular protocol.
This Detector determines if an SSL/TLS-encrypted connection uses the specified certificate, and rejects any other protocols and certificates.
Method | Description |
---|---|
__init__(self, certificate) | Constructor to initialize a CertDetector instance. |
Table 5.26. Method summary
DetectorPolicy instances are reusable detectors that contain configured
instances of the detector classes (for example, HttpDetector, SshDetector)
that detect if the traffic uses a particular protocol, or a
particular certificate in an SSL/TLS connection.
DetectorPolicy instances can be used in the detect
option of firewall rules.
For examples, see the specific detector classes.
This Detector determines if the traffic uses the HTTP protocol, and rejects any other protocol.
Example 5.15. HttpDetector example |
---|
The following example defines a DetectorPolicy that detects HTTP traffic. DetectorPolicy(name="http", detector=HttpDetector() |
Method | Description |
---|---|
__init__(self, **kw) | Constructor to initialize a HttpDetector instance. |
Table 5.27. Method summary
Class encapsulating a Detector that determines whether a client targets a specific host in a SSL/TLS-encrypted connection and rejects any other protocols and hostnames.
Method | Description |
---|---|
__init__(self, server_name_matcher) | Constructor to initialize a SNIDetector instance. |
Table 5.28. Method summary
The TLS framework of the proxies is in a separate entity called Encryption policy. That way, you can easily share and reuse encryption settings between different services: you have to configure the Encryption policy once, and you can use it in multiple services. The TLS framework is described in Chapter 3, The PNS SSL framework.
Note |
---|
STARTTLS support is currently available only for the Ftp proxy to support FTPS sessions and for the SMTP and the Pop3 proxies. |
Name | Value |
---|---|
TLS_CIPHERS_DEFAULT | n/a |
TLS_CIPHERS_OLD | n/a |
TLS_CIPHERS_CUSTOM | n/a |
Table 5.29. Constants for cipher selection
Name | Value |
---|---|
TLSV1_3_CIPHERS_DEFAULT | n/a |
TLSV1_3_CIPHERS_CUSTOM | n/a |
Table 5.30. Constants for TLSv1.3 cipher selection
Name | Value |
---|---|
TLS_SHARED_GROUPS_DEFAULT | n/a |
TLS_SHARED_GROUPS_CUSTOM | n/a |
Table 5.31. Constants for shared group selection
Name | Value |
---|---|
TLS_HSO_CLIENT_SERVER | Perform the TLS-handshake with the client first. |
TLS_HSO_SERVER_CLIENT | Perform the TLS-handshake with the server first. |
Table 5.32. Handshake order.
Name | Value |
---|---|
TLS_NONE | Disable encryption between Vela and the peer. |
TLS_FORCE_TLS | Require encrypted communication between Vela and the peer. |
TLS_ACCEPT_STARTTLS | Permit STARTTLS sessions. Currently supported only in the Ftp, Smtp and Pop3 proxies. |
Table 5.33. Client connection security type.
Name | Value |
---|---|
TLS_NONE | Disable encryption between Vela and the peer. |
TLS_FORCE_TLS | Require encrypted communication between Vela and the peer. |
TLS_FORWARD_STARTTLS | Forward STARTTLS requests to the server. Currently supported only in the Ftp, Smtp and Pop3 proxies. |
Table 5.34. Server connection security type.
Name | Value |
---|---|
TLS_TRUST_LEVEL_NONE | Accept invalid for example, expired certificates. |
TLS_TRUST_LEVEL_UNTRUSTED | Both trusted and untrusted certificates are accepted. |
TLS_TRUST_LEVEL_FULL | Only valid certificates signed by a trusted CA are accepted. |
Table 5.35. Constants for trust level selection.
Name | Value |
---|---|
TLS_INTERMEDIATE_REVOCATION_NONE | Ignore result of CA certificate revocation status check. |
TLS_INTERMEDIATE_REVOCATION_SOFT_FAIL | Check every CA certificate revocation state in the certificate chain. Uncertainty is tolerated. |
TLS_INTERMEDIATE_REVOCATION_HARD_FAIL | Check every CA certificate revocation state in the certificate chain. Uncertainty is not tolerated. |
Table 5.36. Constants for intermediate certificates revocation check type.
Name | Value |
---|---|
TLS_LEAF_REVOCATION_NONE | Ignore result of leaf certificate revocation status check. |
TLS_LEAF_REVOCATION_SOFT_FAIL | Check the revocation state of the leaf certificate. Uncertainty is tolerated. |
TLS_LEAF_REVOCATION_HARD_FAIL | Check the revocation state of the leaf certificate. Uncertainty is not tolerated. |
Table 5.37. Constants for leaf certificate revocation check type.
Name | Value |
---|---|
TLS_HS_ACCEPT | 0 |
TLS_HS_REJECT | 1 |
TLS_HS_POLICY | 6 |
TLS_HS_VERIFIED | 10 |
Table 5.39. Handshake policy decisions
Class | Description |
---|---|
AbstractVerifier | Class encapsulating the abstract Certificate verifier. |
Certificate | Class encapsulating a certificate and its private key, and optionally the passphrase for the private key. |
CertificateCA | Class encapsulating the certificate of a Certificate Authority (CA certificate) and its private key, and optionally the passphrase for the private key. |
ClientCertificateVerifier | Class that can be used to verify the certificate of the client-side connection. |
ClientNoneVerifier | Disables certificate verification in client-side connection. |
ClientOnlyEncryption | The ClientOnlyEncryption class handles scenarios when only the client-Vela connection is encrypted, the Vela-server connection is not |
ClientOnlyStartTLSEncryption | The client can optionally request STARTTLS encryption, but the server-side connection is always unencrypted. |
ClientTLSOptions | Class encapsulating a set of TLS options used in the client-side connection. |
DHParam | Class encapsulating DH parameters. |
DynamicCertificate | Class to perform TLS keybridging. |
DynamicServerEncryption | The DynamicServerEncryption class handles scenarios when both the client-firewall and the firewall-server connections could be encrypted but the server side encryption parameters set dynamically from proxies. |
EncryptionPolicy | Class encapsulating a named set of encryption settings. |
FakeStartTLSEncryption | The client can optionally request STARTTLS encryption, but the server-side connection is always encrypted. |
ForwardStartTLSEncryption | The ForwardStartTLSEncryption class handles scenarios when the client can optionally request STARTTLS encryption. |
PrivateKey | Class encapsulating a private key. |
SNIBasedCertificate | Class to be used for Server Name Indication (SNI) |
ServerCertificateVerifier | Class that can be used to verify the certificate of the server-side connection. |
ServerNoneVerifier | Disables certificate verification in server-side connection. |
ServerOnlyEncryption | The ServerOnlyEncryption class handles scenarios when only the Vela-server connection is encrypted, the client-Vela connection is not |
ServerTLSOptions | Class encapsulating a set of TLS options used in the server-side connection. |
StaticCertificate | Class encapsulating a static Certificate object. |
TLSOptions | Class encapsulating the abstract TLS options. |
TwoSidedEncryption | The TwoSidedEncryption class handles scenarios when both the client-Vela and the Vela-server connections are encrypted. |
Table 5.40. Classes of the Encryption module
This class includes the settings and options used to verify the certificates of the peers in TLS connections. Note that you cannot use this class directly, use an appropriate derived class, for example, ClientCertificateVerifier or ServerCertificateVerifier instead.
intermediate_revocation_check_type (enum) | |
---|---|
Default: TLS_INTERMEDIATE_REVOCATION_SOFT_FAIL | |
Specify how intermediate certificates revocation status check should work. |
leaf_revocation_check_type (enum) | |
---|---|
Default: TLS_LEAF_REVOCATION_SOFT_FAIL | |
Specify how leaf certificate revocation status check should work. |
required (boolean) | |
---|---|
Default: trusted | |
If the required is TRUE, a certificate is required from the peer.
|
trust_level (enum) | |
---|---|
Default: TLS_TRUST_LEVEL_FULL | |
Specify which certificate should be accepted as trusted. |
verify_ca_directory (string) | |
---|---|
Default: "" | |
Directory where the trusted CA certificates are stored. CA certificates are loaded on-demand from this directory when the certificate of the peer is verified. |
Method | Description |
---|---|
__init__(self, trust_level, intermediate_revocation_check_type, leaf_revocation_check_type, trusted_certs_directory, required, verify_depth, verify_ca_directory, verify_crl_directory) | Constructor to initialize an AbstractVerifier instance. |
Table 5.41. Method summary
This constructor defines an AbstractVerifier with the specified parameters.
intermediate_revocation_check_type (enum) | |
---|---|
Default: TLS_INTERMEDIATE_REVOCATION_SOFT_FAIL | |
Specify how intermediate certificates revocation status check should work. |
leaf_revocation_check_type (enum) | |
---|---|
Default: TLS_LEAF_REVOCATION_SOFT_FAIL | |
Specify how leaf certificate revocation status check should work. |
trust_level (enum) | |
---|---|
Default: TLS_TRUST_LEVEL_FULL | |
Specify which certificate should be accepted as trusted. |
verify_ca_directory (string) | |
---|---|
Default: "" | |
Directory where the trusted CA certificates are stored. CA certificates are loaded on-demand from this directory when the certificate of the peer is verified. |
The Certificate class stores a certificate, its private key, and optionally a passphrase for the private key. The certificate must be in PEM format.
When configuring Vela manually using its configuration file, use the regular constructor of the Certificate class to load a certificate from a string. To load a certificate from a file, use the Certificate.fromFile method.
Method | Description |
---|---|
__init__(self, certificate, private_key) | Load a certificate from a string, and access it using its passphrase |
fromFile(certificate_file_path, private_key) | Load a certificate from a file, and access it using its passphrase |
Table 5.42. Method summary
Initializes a Certificate instance by loading a certificate from a string, and accesses it using its passphrase. To load a certificate from a file, use the Certificate.fromFile method.
Initializes a Certificate instance by loading a certificate from a file, and accesses it using its passphrase.
The CertificateCA class stores a CA certificate, its private key, and optionally a passphrase for the private key. The certificate must be in PEM format.
Method | Description |
---|---|
__init__(self, certificate, private_key) | Load a CAcertificate from a string, and access it using its passphrase |
Table 5.43. Method summary
Initializes a CertificateCA instance by loading a CA certificate, and accesses it using its passphrase.
This class includes the settings and options used to verify the certificates of the peers in client-side TLS connections.
ca_hint_directory (string) | |
---|---|
Default: "" | |
Set directory containing certificates to provide the client the list of CA certificates (subject names) that are used for verifying the client certificate. |
intermediate_revocation_check_type (enum) | |
---|---|
Default: TLS_INTERMEDIATE_REVOCATION_SOFT_FAIL | |
Specify how intermediate certificates revocation status check should work. |
leaf_revocation_check_type (enum) | |
---|---|
Default: TLS_LEAF_REVOCATION_SOFT_FAIL | |
Specify how leaf certificate revocation status check should work. |
trust_level (enum) | |
---|---|
Default: TLS_TRUST_LEVEL_FULL | |
Specify which certificate should be accepted as trusted. |
verify_ca_directory (string) | |
---|---|
Default: "" | |
Directory where the trusted CA certificates are stored. CA certificates are loaded on-demand from this directory when the certificate of the peer is verified. |
Method | Description |
---|---|
__init__(self, trust_level, intermediate_revocation_check_type, leaf_revocation_check_type, trusted_certs_directory, required, verify_depth, verify_ca_directory, verify_crl_directory, ca_hint_directory) | Constructor to initialize a ClientCertificateVerifier instance. |
Table 5.44. Method summary
This constructor defines a ClientCertificateVerifier with the specified parameters.
ca_hint_directory (string) | |
---|---|
Default: "" | |
Set directory containing certificates to provide the client the list of CA certificates (subject names) that are used for verifying the client certificate. |
intermediate_revocation_check_type (enum) | |
---|---|
Default: TLS_INTERMEDIATE_REVOCATION_SOFT_FAIL | |
Specify how intermediate certificates revocation status check should work. |
leaf_revocation_check_type (enum) | |
---|---|
Default: TLS_LEAF_REVOCATION_SOFT_FAIL | |
Specify how leaf certificate revocation status check should work. |
trust_level (enum) | |
---|---|
Default: TLS_TRUST_LEVEL_FULL | |
Specify which certificate should be accepted as trusted. |
verify_ca_directory (string) | |
---|---|
Default: "" | |
Directory where the trusted CA certificates are stored. CA certificates are loaded on-demand from this directory when the certificate of the peer is verified. |
This class disables every certificate verification in client-side TLS connections.
The ClientOnlyEncryption class handles scenarios when only the client-Vela connection is encrypted, the Vela-server connection is not.
client_certificate_generator (class) | |
---|---|
Default: n/a | |
The class that will generate the certificate that will be showed to the client. You can use an instance of the StaticCertificate, DynamicCertificate, or SNIBasedCertificate classes. |
client_tls_options (class) | |
---|---|
Default: ClientTLSOptions() | |
The protocol-level encryption settings used on the client side. This must be a ClientTLSOptions instance. |
client_verify (class) | |
---|---|
Default: ClientCertificateVerifierGroup() | |
The settings used to verify the certificate of the client. This must be a ClientCertificateVerifier instance. |
Method | Description |
---|---|
__init__(self, client_certificate_generator, client_verify, client_tls_options) | Initializes TLS connection on the client side. |
Table 5.45. Method summary
The ClientOnlyEncryption class handles scenarios when only the client-Vela connection is encrypted, the Vela-server connection is not.
client_certificate_generator (class) | |
---|---|
Default: n/a | |
The class that will generate the certificate that will be showed to the client. You can use an instance of the StaticCertificate, DynamicCertificate, or SNIBasedCertificate classes. |
client_tls_options (class) | |
---|---|
Default: ClientTLSOptions() | |
The protocol-level encryption settings used on the client side. This must be a ClientTLSOptions instance. |
client_verify (class) | |
---|---|
Default: ClientCertificateVerifierGroup() | |
The settings used to verify the certificate of the client. This must be a ClientCertificateVerifier instance. |
Warning |
---|
If the client does not send a STARTTLS request, the client-side communication will not be encrypted at all. The server-side connection will never be encrypted. |
client_certificate_generator (class) | |
---|---|
Default: n/a | |
The class that will generate the certificate that will be showed to the client. You can use an instance of the StaticCertificate, DynamicCertificate, or SNIBasedCertificate classes. |
client_tls_options (class) | |
---|---|
Default: ClientTLSOptions() | |
The protocol-level encryption settings used on the client side. This must be a ClientTLSOptions instance. |
client_verify (class) | |
---|---|
Default: ClientCertificateVerifierGroup() | |
The settings used to verify the certificate of the client. This must be a ClientCertificateVerifier instance. |
Method | Description |
---|---|
__init__(self, client_certificate_generator, client_verify, client_tls_options) | The client can optionally request STARTTLS encryption, but the server-side connection is always unencrypted. |
Table 5.46. Method summary
Warning |
---|
If the client does not send a STARTTLS request, the client-side communication will not be encrypted at all. The server-side connection will never be encrypted. |
client_certificate_generator (class) | |
---|---|
Default: n/a | |
The class that will generate the certificate that will be showed to the client. You can use an instance of the StaticCertificate, DynamicCertificate, or SNIBasedCertificate classes. |
client_tls_options (class) | |
---|---|
Default: ClientTLSOptions() | |
The protocol-level encryption settings used on the client side. This must be a ClientTLSOptions instance. |
client_verify (class) | |
---|---|
Default: ClientCertificateVerifier() | |
The settings used to verify the certificate of the client. This must be a ClientCertificateVerifier instance. |
This class (based on the TLSOptions class) collects the TLS settings directly related to encryption, for example, the permitted protocol versions, ciphers, session reuse settings, and so on.
ciphers (enum) | |
---|---|
Default: n/a | |
Specifies the allowed ciphers. For details, see Table 5.29, Constants for cipher selection . |
ciphers_tlsv1_3 (enum) | |
---|---|
Default: n/a | |
Specifies the allowed ciphers for TLSv1.3 connections. For details, see Table 5.30, Constants for TLSv1.3 cipher selection . |
dh_params (dhparams) | |
---|---|
Default: None | |
The DH parameter used by ephemeral DH key generarion. Please be mind that this option is ignored in TLSv1.3 as it does not support custom DH parameters. |
disable_compression (boolean) | |
---|---|
Default: TRUE | |
Set this to FALSE to support TLS compression. Please be mind that this option is ignored in TLSv1.3 as it does not support compression. |
disable_renegotiation (boolean) | |
---|---|
Default: TRUE | |
Set this to TRUE to disable client initiated renegotiation. Please be mind that this option is ignored in TLSv1.3 as it does not support renegotiation. |
disable_send_root_ca (boolean) | |
---|---|
Default: FALSE | |
Inhibit sending Root CA to client, even if present in local certificate chain. |
disable_ticket (boolean) | |
---|---|
Default: TRUE | |
Session tickets are a method for TLS session reuse, described in RFC 5077. Set this option to FALSE to enable TLS session reuse using session tickets. |
prioritize_chacha (boolean) | |
---|---|
Default: FALSE | |
When cipher_server_preference is TRUE, reprioritize ChaCha20-Poly1305 cipher if it is at the top of the client cipher list. |
shared_groups (enum) | |
---|---|
Default: n/a | |
Specifies the allowed shared groups. For details, see Table 5.31, Constants for shared group selection . |
Method | Description |
---|---|
__init__(self, tls_min_version, tls_max_version, ciphers, ciphers_tlsv1_3, shared_groups, timeout, session_cache_size, disable_session_cache, disable_ticket, disable_compression, cipher_server_preference, prioritize_chacha, dh_params, disable_renegotiation, disable_send_root_ca) | Constructor to initialize a ClientTLSOptions instance. |
Table 5.47. Method summary
This constructor defines a ClientTLSOptions with the specified parameters.
ciphers (enum) | |
---|---|
Default: n/a | |
Specifies the allowed ciphers. For details, see Table 5.29, Constants for cipher selection . |
ciphers_tlsv1_3 (enum) | |
---|---|
Default: n/a | |
Specifies the allowed ciphers for TLSv1.3 connections. For details, see Table 5.30, Constants for TLSv1.3 cipher selection . |
disable_renegotiation (boolean) | |
---|---|
Default: TRUE | |
Set this to TRUE to disable client initiated renegotiation. Please be mind that this option is ignored in TLSv1.3 as it does not support renegotiation. |
disable_send_root_ca (boolean) | |
---|---|
Default: FALSE | |
Set this to TRUE to inhibit sending root ca to client, even if present in local chain. |
disable_ticket (boolean) | |
---|---|
Default: TRUE | |
Session tickets are a method for TLS session reuse, described in RFC 5077. Set this option to FALSE to enable TLS session reuse using session tickets. |
prioritize_chacha (boolean) | |
---|---|
Default: FALSE | |
When cipher_server_preference is TRUE, reprioritize ChaCha20-Poly1305 cipher if it is at the top of the client cipher list. |
shared_groups (enum) | |
---|---|
Default: n/a | |
Specifies the allowed shared groups. For details, see Table 5.31, Constants for shared group selection . |
The DHParam class stores DH parameters. The DH parameters must be in PEM format.
When configuring Vela manually using its configuration file, use the regular constructor of the DHParam class to load DH parameters key from a string. To load DH parameters key from a file, use the DHParam.fromFile method.
Method | Description |
---|---|
__init__(self, params) | Load DH parameters key from a string |
fromFile(file_path) | Load a DH parameters from a file |
Table 5.48. Method summary
Initializes a DHParam instance by loading DH parameters key from a string. To load a DH parameters from a file, use the DHParam.fromFile method.
This class is able to generate certificates mimicking another certificate, primarily used to transfer the information of a server's certificate to the client in keybridging. Can be used only in TwoSidedEncryption. For details on configuring keybridging, see Procedure 3.2.8, Configuring keybridging.
Method | Description |
---|---|
__init__(self, private_key, trusted_ca, untrusted_ca, cache_directory, extension_whitelist) | Initializes a DynamicCertificate instance to use for keybridging |
Table 5.49. Method summary
The DynamicServerEncryption class handles scenarios when both the client-firewall and the firewall-server connections could be encrypted but the server side encryption parameters set dynamically from proxies.
client_certificate_generator (class) | |
---|---|
Default: n/a | |
The class that will generate the certificate that will be showed to the client. You can use an instance of the StaticCertificate, DynamicCertificate, or SNIBasedCertificate classes. |
client_tls_options (class) | |
---|---|
Default: ClientTLSOptions() | |
The protocol-level encryption settings used on the client side. This must be a ClientTLSOptions instance. |
client_verify (class) | |
---|---|
Default: ClientCertificateVerifierGroup() | |
The settings used to verify the certificate of the client. This must be a ClientCertificateVerifier instance. |
Method | Description |
---|---|
__init__(self, client_security, client_certificate_generator, client_verify, client_tls_options) | Initializes TLS connection on the client side. |
Table 5.50. Method summary
The DynamicServerEncryption class handles scenarios when both the client-firewall and the firewall-server connections could be encrypted but the server side encryption parameters set dynamically from proxies.
client_certificate_generator (class) | |
---|---|
Default: n/a | |
The class that will generate the certificate that will be showed to the client. You can use an instance of the StaticCertificate, DynamicCertificate, or SNIBasedCertificate classes. |
client_tls_options (class) | |
---|---|
Default: ClientTLSOptions() | |
The protocol-level encryption settings used on the client side. This must be a ClientTLSOptions instance. |
client_verify (class) | |
---|---|
Default: ClientCertificateVerifierGroup() | |
The settings used to verify the certificate of the client. This must be a ClientCertificateVerifier instance. |
This class encapsulates a named set of encryption settings and an associated Encryption policy instance. Encryption policies provide a way to re-use encryption settings without having to define encryption settings for each service individually.
encryption (class) | |
---|---|
Default: n/a | |
An encryption scenario instance that will be used in the Encryption Policy.
This describes the scenario and the settings how encryption is used in the scenario, for example:
To customize the settings of a scenario (for example, to set the used certificates), derive a class from the selected scenario, set its parameters as needed for your environment, and use the customized class. |
Method | Description |
---|---|
__init__(self, name, encryption) | Constructor to create an Encryption policy. |
Table 5.51. Method summary
This constructor initializes an Encryption policy, based on the settings of the encryption
parameter.
This describes the scenario and the settings how encryption is used in the scenario, for example:
Both the client-side and the server-side connections are encrypted (TwoSidedEncryption)
Only the client-side connection is encrypted (ClientOnlyEncryption)
Only the server-side connection is encrypted (ServerOnlyEncryption)
STARTTLS is enabled (ClientOnlyStartTLSEncryption, FakeStartTLSEncryption, or ForwardStartTLSEncryption)
To customize the settings of a scenario (for example, to set the used certificates), derive a class from the selected scenario, set its parameters as needed for your environment, and use the customized class.
Warning |
---|
If the client does not send a STARTTLS request, the client-side communication will not be encrypted at all. The server-side connection will always be encrypted. |
client_certificate_generator (class) | |
---|---|
Default: n/a | |
The class that will generate the certificate that will be showed to the client. You can use an instance of the StaticCertificate, DynamicCertificate, or SNIBasedCertificate classes. |
client_tls_options (class) | |
---|---|
Default: ClientTLSOptions() | |
The protocol-level encryption settings used on the client side. This must be a ClientTLSOptions instance. |
client_verify (class) | |
---|---|
Default: ClientCertificateVerifierGroup() | |
The settings used to verify the certificate of the client. This must be a ClientCertificateVerifier instance. |
server_tls_options (class) | |
---|---|
Default: ServerTLSOptions() | |
The protocol-level encryption settings used on the server side. This must be a ServerTLSOptions instance. |
server_verify (class) | |
---|---|
Default: ServerCertificateVerifierGroup() | |
The settings used to verify the certificate of the server. This must be a ServerCertificateVerifier instance. |
Method | Description |
---|---|
__init__(self, client_certificate_generator, client_verify, server_verify, client_tls_options, server_tls_options) | Initializes a FakeStartTLSEncryption instance to handle scenarios when the client can optionally request STARTTLS encryption. |
Table 5.52. Method summary
Warning |
---|
If the client does not send a STARTTLS request, the client-side communication will not be encrypted at all. The server-side connection will always be encrypted. |
client_certificate_generator (class) | |
---|---|
Default: n/a | |
The class that will generate the certificate that will be showed to the client. You can use an instance of the StaticCertificate, DynamicCertificate, or SNIBasedCertificate classes. |
client_tls_options (class) | |
---|---|
Default: ClientTLSOptions() | |
The protocol-level encryption settings used on the client side. This must be a ClientTLSOptions instance. |
client_verify (class) | |
---|---|
Default: ClientCertificateVerifierGroup() | |
The settings used to verify the certificate of the client. This must be a ClientCertificateVerifier instance. |
server_tls_options (class) | |
---|---|
Default: ServerTLSOptions() | |
The protocol-level encryption settings used on the server side. This must be a ServerTLSOptions instance. |
server_verify (class) | |
---|---|
Default: ServerCertificateVerifierGroup() | |
The settings used to verify the certificate of the server. This must be a ServerCertificateVerifier instance. |
Warning |
---|
If the client does not send a STARTTLS request, the communication will not be encrypted at all. Both the client-Vela and the Vela-server connections will be unencrypted. |
client_certificate_generator (class) | |
---|---|
Default: n/a | |
The class that will generate the certificate that will be showed to the client. You can use an instance of the StaticCertificate, DynamicCertificate, or SNIBasedCertificate classes. |
client_tls_options (class) | |
---|---|
Default: ClientTLSOptions() | |
The protocol-level encryption settings used on the client side. This must be a ClientTLSOptions instance. |
client_verify (class) | |
---|---|
Default: ClientCertificateVerifierGroup() | |
The settings used to verify the certificate of the client. This must be a ClientCertificateVerifier instance. |
server_tls_options (class) | |
---|---|
Default: ServerTLSOptions() | |
The protocol-level encryption settings used on the server side. This must be a ServerTLSOptions instance. |
server_verify (class) | |
---|---|
Default: ServerCertificateVerifierGroup() | |
The settings used to verify the certificate of the server. This must be a ServerCertificateVerifier instance. |
Method | Description |
---|---|
__init__(self, client_certificate_generator, client_verify, server_verify, client_tls_options, server_tls_options) | Initializes a ForwardStartTLSEncryption instance to handle scenarios when the client can optionally request STARTTLS encryption. |
Table 5.53. Method summary
Warning |
---|
If the client does not send a STARTTLS request, the communication will not be encrypted at all. Both the client-Vela and the Vela-server connections will be unencrypted. |
client_certificate_generator (class) | |
---|---|
Default: n/a | |
The class that will generate the certificate that will be showed to the client. You can use an instance of the StaticCertificate, DynamicCertificate, or SNIBasedCertificate classes. |
client_tls_options (class) | |
---|---|
Default: ClientTLSOptions() | |
The protocol-level encryption settings used on the client side. This must be a ClientTLSOptions instance. |
client_verify (class) | |
---|---|
Default: ClientCertificateVerifierGroup() | |
The settings used to verify the certificate of the client. This must be a ClientCertificateVerifier instance. |
server_tls_options (class) | |
---|---|
Default: ServerTLSOptions() | |
The protocol-level encryption settings used on the server side. This must be a ServerTLSOptions instance. |
server_verify (class) | |
---|---|
Default: ServerCertificateVerifierGroup() | |
The settings used to verify the certificate of the server. This must be a ServerCertificateVerifier instance. |
The PrivateKey class stores a private key and optionally a passphrase for the private key. The private key must be in PEM format, or an URI to an external private key provider.
When configuring Vela manually using its configuration file, use the regular constructor of the PrivateKey class to load a private key from a string. To load a private key from a file, use the PrivateKey.fromFile method.
Method | Description |
---|---|
__init__(self, key, key_format, passphrase) | Load a private key from a string, and access it using its passphrase |
fromFile(key_file_path, passphrase) | Load a private key from a file, and access it using its passphrase |
fromURI(key_uri, passphrase) | Load a private key from an Universal Resource Identifier (URI) string. |
Table 5.54. Method summary
Initializes a PrivateKey instance by loading a private key from a string, and accesses it using its passphrase. To load a private key from a file, use the PrivateKey.fromFile method.
Initializes a PrivateKey instance by loading a private key from a file, and accesses it using its passphrase.
Initializes a PrivateKey instance by loading a private key from an URI. Supported URI schemes are 'file:' and 'pkcs11:' for loading a private key from an external file, or from a HSM device. URI can contain authentiction information (e.g. PIN code) also. Note, the URI string will be stored unencrypted.
This class adds support for the Server Name Indication (SNI) TLS extension, as described in RFC 6066. It stores a mapping between hostnames and certificates, and automatically selects the certificate to show to the peer if the peer has sent an SNI request.
default (complex) | |
---|---|
Default: None | |
The certificate to show to the peer if no matching hostname is found in hostname_certificate_map .
|
hostname_certificate_map (complex) | |
---|---|
Default: n/a | |
A hash containing a matcher-certificate map. Each element of the hash contains a matcher and a certificate:
if a matcher matches the hostname in the SNI request, the certificate is showed to the peer.
You can use any matcher policy, though in most cases, RegexpMatcher will be adequate.
Different elements of the hash can use different types of matchers, for example, RegexpMatcher and RegexpFileMatcher.
For details on matcher policies, see Section 5.8, Module Matcher.
hostname_certificate_map={ RegexpMatcher( match_list=("myfirstdomain.example.com", )): StaticCertificate( certificates=(Certificate.fromFile( certificate_file_path="/etc/key.d/myfirstdomain/cert.pem", private_key=PrivateKey.fromFile( "/etc/key.d/myfirstdomain/key.pem")),)),} |
default (complex) | |
---|---|
Default: None | |
The certificate to show to the peer if no matching hostname is found in hostname_certificate_map .
|
hostname_certificate_map (complex) | |
---|---|
Default: n/a | |
A matcher-certificate map that describes which certificate will be showed to the peer if the matcher part matches the hostname in the SNI request. For details on matcher policies, see Section 5.8, Module Matcher. |
This class includes the settings and options used to verify the certificates of the peers in server-side TLS connections. Note that the ServerCertificateVerifier class always requests a certificate from the server.
check_subject (boolean) | |
---|---|
Default: TRUE | |
If the check_subject parameter is TRUE,
the Subject of the server-side certificate is compared
with application-layer information (for example, it checks
whether the Subject matches the hostname in the URL).
For details, see Section 3.2.5, Certificate verification options.
|
intermediate_revocation_check_type (enum) | |
---|---|
Default: TLS_INTERMEDIATE_REVOCATION_SOFT_FAIL | |
Specify how intermediate certificates revocation status check should work. |
leaf_revocation_check_type (enum) | |
---|---|
Default: TLS_LEAF_REVOCATION_SOFT_FAIL | |
Specify how leaf certificate revocation status check should work. |
trust_level (enum) | |
---|---|
Default: TLS_TRUST_LEVEL_FULL | |
Specify which certificate should be accepted as trusted. |
verify_ca_directory (string) | |
---|---|
Default: "" | |
Directory where the trusted CA certificates are stored. CA certificates are loaded on-demand from this directory when the certificate of the peer is verified. |
Method | Description |
---|---|
__init__(self, trust_level, intermediate_revocation_check_type, leaf_revocation_check_type, trusted_certs_directory, verify_depth, verify_ca_directory, verify_crl_directory, check_subject) | Constructor to initialize a ServerCertificateVerifier instance. |
Table 5.56. Method summary
This constructor defines a ServerCertificateVerifier with the specified parameters.
check_subject (boolean) | |
---|---|
Default: TRUE | |
If the check_subject parameter is TRUE,
the Subject of the server-side certificate is compared
with application-layer information (for example, it checks
whether the Subject matches the hostname in the URL).
For details, see Section 3.2.5, Certificate verification options.
|
intermediate_revocation_check_type (enum) | |
---|---|
Default: TLS_INTERMEDIATE_REVOCATION_SOFT_FAIL | |
Specify how intermediate certificates revocation status check should work. |
leaf_revocation_check_type (enum) | |
---|---|
Default: TLS_LEAF_REVOCATION_SOFT_FAIL | |
Specify how leaf certificate revocation status check should work. |
trust_level (enum) | |
---|---|
Default: TLS_TRUST_LEVEL_FULL | |
Specify which certificate should be accepted as trusted. |
verify_ca_directory (string) | |
---|---|
Default: "" | |
Directory where the trusted CA certificates are stored. CA certificates are loaded on-demand from this directory when the certificate of the peer is verified. |
This class disables every certificate verification in server-side TLS connections.
The ServerOnlyEncryption class handles scenarios when only the Vela-server connection is encrypted, the client-Vela connection is not.
server_certificate_generator (class) | |
---|---|
Default: None | |
The class that will generate the certificate that will be showed to the server. You can use an instance of the StaticCertificate, DynamicCertificate, or SNIBasedCertificate classes. |
server_tls_options (class) | |
---|---|
Default: ServerTLSOptions() | |
The protocol-level encryption settings used on the server side. This must be a ServerTLSOptions instance. |
server_verify (class) | |
---|---|
Default: ServerCertificateVerifierGroup() | |
The settings used to verify the certificate of the server. This must be a ServerCertificateVerifier instance. |
Method | Description |
---|---|
__init__(self, server_certificate_generator, server_verify, server_tls_options) | Initializes TLS connection on the server side. |
Table 5.57. Method summary
The ServerOnlyEncryption class handles scenarios when only the Vela-server connection is encrypted, the client-Vela connection is not.
server_certificate_generator (class) | |
---|---|
Default: None | |
The class that will generate the certificate that will be showed to the server. You can use an instance of the StaticCertificate, DynamicCertificate, or SNIBasedCertificate classes. |
server_tls_options (class) | |
---|---|
Default: ServerTLSOptions() | |
The protocol-level encryption settings used on the server side. This must be a ServerTLSOptions instance. |
server_verify (class) | |
---|---|
Default: ServerCertificateVerifierGroup() | |
The settings used to verify the certificate of the server. This must be a ServerCertificateVerifier instance. |
This class (based on the TLSOptions class) collects the TLS settings directly related to encryption, for example, the permitted protocol versions, ciphers, session reuse settings, and so on.
ciphers (enum) | |
---|---|
Default: n/a | |
Specifies the allowed ciphers. For details, see Table 5.29, Constants for cipher selection . |
ciphers_tlsv1_3 (enum) | |
---|---|
Default: n/a | |
Specifies the allowed ciphers for TLSv1.3 connections. For details, see Table 5.30, Constants for TLSv1.3 cipher selection . |
disable_compression (boolean) | |
---|---|
Default: TRUE | |
Set this to FALSE to support TLS compression. Please be mind that this option is ignored in TLSv1.3 as it does not support compression. |
disable_ticket (boolean) | |
---|---|
Default: TRUE | |
Session tickets are a method for TLS session reuse, described in RFC 5077. Set this option to FALSE to enable TLS session reuse using session tickets. |
shared_groups (enum) | |
---|---|
Default: n/a | |
Specifies the allowed shared groups. For details, see Table 5.31, Constants for shared group selection . |
Method | Description |
---|---|
__init__(self, tls_min_version, tls_max_version, ciphers, ciphers_tlsv1_3, shared_groups, timeout, session_cache_size, disable_session_cache, disable_ticket, disable_compression) | Constructor to initialize a ServerTLSOptions instance. |
Table 5.58. Method summary
This constructor defines a ServerTLSOptions with the specified parameters.
ciphers (enum) | |
---|---|
Default: n/a | |
Specifies the allowed ciphers. For details, see Table 5.29, Constants for cipher selection . |
ciphers_tlsv1_3 (enum) | |
---|---|
Default: n/a | |
Specifies the allowed ciphers for TLSv1.3 connections. For details, see Table 5.30, Constants for TLSv1.3 cipher selection . |
disable_ticket (boolean) | |
---|---|
Default: TRUE | |
Session tickets are a method for TLS session reuse, described in RFC 5077. Set this option to FALSE to enable TLS session reuse using session tickets. |
shared_groups (enum) | |
---|---|
Default: n/a | |
Specifies the allowed shared groups. For details, see Table 5.31, Constants for shared group selection . |
This class encapsulates a static Certificate that can be used in TLS connections.
Method | Description |
---|---|
__init__(self, certificates) | Initializes a static Certificate object. |
Table 5.59. Method summary
This class collects the TLS settings directly related to encryption, for example, the permitted protocol versions, ciphers, session reuse settings, and so on. Note that you cannot use this class directly, use an appropriate derived class, for example, ClientTLSOptions or ServerTLSOptions instead.
ciphers (complex) | |
---|---|
Default: n/a | |
Specifies the allowed ciphers. For details, see Table 5.29, Constants for cipher selection . |
ciphers_tlsv1_3 (complex) | |
---|---|
Default: n/a | |
Specifies the allowed ciphers for TLSv1.3 connections. For details, see Table 5.30, Constants for TLSv1.3 cipher selection . |
disable_compression (boolean) | |
---|---|
Default: TRUE | |
Set this to FALSE to support TLS compression. Please be mind that this option is ignored in TLSv1.3 as it does not support compression. |
disable_ticket (boolean) | |
---|---|
Default: TRUE | |
Session tickets are a method for TLS session reuse, described in RFC 5077. Set this option to FALSE to enable TLS session reuse using session tickets. |
shared_groups (complex) | |
---|---|
Default: n/a | |
Specifies the allowed shared groups. For details, see Table 5.31, Constants for shared group selection . |
Method | Description |
---|---|
__init__(self, tls_min_version, tls_max_version, ciphers, ciphers_tlsv1_3, shared_groups, timeout, session_cache_size, disable_session_cache, disable_ticket, disable_compression) | Constructor to initialize an TLSOptions instance. |
Table 5.60. Method summary
This constructor defines an TLSOptions with the specified parameters.
ciphers (enum) | |
---|---|
Default: n/a | |
Specifies the allowed ciphers. For details, see Table 5.29, Constants for cipher selection . |
ciphers_tlsv1_3 (enum) | |
---|---|
Default: n/a | |
Specifies the allowed ciphers for TLSv1.3 connections. For details, see Table 5.30, Constants for TLSv1.3 cipher selection . |
disable_ticket (boolean) | |
---|---|
Default: TRUE | |
Session tickets are a method for TLS session reuse, described in RFC 5077. Set this option to FALSE to enable TLS session reuse using session tickets. |
shared_groups (enum) | |
---|---|
Default: n/a | |
Specifies the allowed shared groups. For details, see Table 5.31, Constants for shared group selection . |
The TwoSidedEncryption class handles scenarios when both the client-Vela and the Vela-server connections are encrypted. If you do not need encryption on the client- or the server-side, use the ServerOnlyEncryption or ClientOnlyEncryption classes, respectively. For a detailed example on keybridging, see Procedure 3.2.8, Configuring keybridging.
client_certificate_generator (class) | |
---|---|
Default: n/a | |
The class that will generate the certificate that will be showed to the client. You can use an instance of the StaticCertificate, DynamicCertificate, or SNIBasedCertificate classes. |
client_tls_options (class) | |
---|---|
Default: ClientTLSOptions() | |
The protocol-level encryption settings used on the client side. This must be a ClientTLSOptions instance. |
client_verify (class) | |
---|---|
Default: ClientCertificateVerifierGroup() | |
The settings used to verify the certificate of the client. This must be a ClientCertificateVerifier instance. |
server_certificate_generator (class) | |
---|---|
Default: None | |
The class that will generate the certificate that will be showed to the server. You can use an instance of the StaticCertificate, DynamicCertificate, or SNIBasedCertificate classes. |
server_tls_options (class) | |
---|---|
Default: ServerTLSOptions() | |
The protocol-level encryption settings used on the server side. This must be a ServerTLSOptions instance. |
server_verify (class) | |
---|---|
Default: ServerCertificateVerifierGroup() | |
The settings used to verify the certificate of the server. This must be a ServerCertificateVerifier instance. |
Method | Description |
---|---|
__init__(self, client_certificate_generator, server_certificate_generator, client_verify, server_verify, client_tls_options, server_tls_options) | Initializes TLS connection with both peers. |
Table 5.61. Method summary
The TwoSidedEncryption class handles scenarios when both the client-Vela and the Vela-server connections are encrypted.
client_certificate_generator (class) | |
---|---|
Default: n/a | |
The class that will generate the certificate that will be showed to the client. You can use an instance of the StaticCertificate, DynamicCertificate, or SNIBasedCertificate classes. |
client_tls_options (class) | |
---|---|
Default: ClientTLSOptions() | |
The protocol-level encryption settings used on the client side. This must be a ClientTLSOptions instance. |
client_verify (class) | |
---|---|
Default: ClientCertificateVerifierGroup() | |
The settings used to verify the certificate of the client. This must be a ClientCertificateVerifier instance. |
server_certificate_generator (class) | |
---|---|
Default: None | |
The class that will generate the certificate that will be showed to the server. You can use an instance of the StaticCertificate, DynamicCertificate, or SNIBasedCertificate classes. |
server_tls_options (class) | |
---|---|
Default: ServerTLSOptions() | |
The protocol-level encryption settings used on the server side. This must be a ServerTLSOptions instance. |
server_verify (class) | |
---|---|
Default: ServerCertificateVerifierGroup() | |
The settings used to verify the certificate of the server. This must be a ServerCertificateVerifier instance. |
The IDS settings of the proxies is in a separate entity called Ids policy. That way, you can easily share and reuse encryption settings between different services: you have to configure the Ids policy once, and you can use it in multiple services.
Class | Description |
---|---|
Ids | Settings needed to send data towards an IDS. |
IdsPolicy | Class encapsulating a named set of ids settings. |
Table 5.62. Classes of the Ids module
Method | Description |
---|---|
__init__(self, interface_name, mac_address) | Settings needed to send data towards an IDS. |
Table 5.63. Method summary
This class encapsulates a named set of ids settings and an associated Ids policy instance. Ids policies provide a way to re-use ids settings without having to define ids settings for each service individually.
Method | Description |
---|---|
__init__(self, name, ids) | Constructor to create an Ids policy. |
Table 5.64. Method summary
This constructor initializes an Ids policy, based on the settings of the ids
parameter.
This describes the settings to connect to the IDS
Keybridging is a method to let the client see a copy of the server's certificate (or vice versa), allowing it to inspect it and decide about its trustworthiness. Because of proxying the SSL/TLS connection, the client is not able to inspect the certificate of the server directly, therefore a certificate based on the server's certificate is generated on-the-fly. This generated certificate is presented to the client.
For details on configuring keybridging, see Procedure 3.2.8, Configuring keybridging.
In general, matcher policies can be used to find out if a parameter is included in a list (or which elements of a list correspond to a certain parameter), and influence the behavior of the proxy class based on the results. Matchers can be used for a wide range of tasks, for example, to determine if the particular IP address or URL that a client is trying to access is on a black or whitelist, or to verify that a particular e-mail address is valid.
Class | Description |
---|---|
AbstractMatcher | Class encapsulating the abstract string matcher. |
CombineMatcher | Matcher for implementing logical expressions based on other matchers. |
DNSMatcher | DNS matcher |
MatcherPolicy | Class encapsulating a Matcher which can be used by a name. |
RegexpFileMatcher | Class encapsulating Matcher which uses regular expressions stored in files for string matching. |
RegexpMatcher | Class encapsulating a Matcher which uses regular expressions for string matching. |
SmtpInvalidRecipientMatcher | Class verifying the validity of the recipient addresses in e-mails. |
WindowsUpdateMatcher | Windows Update matcher |
Table 5.65. Classes of the Matcher module
This abstract class encapsulates a string matcher that determines whether a given string is found in a backend database.
Specialized subclasses of AbstractMatcher exist such as 'RegexpFileMatcher' which use regular expressions stored in flat files to find matches.
This matcher makes it possible to combine the results of several
matchers using logical operations. CombineMatcher uses
prefix-notation in its expressions and uses the following format:
the operand, a comma, first argument, a comma, second argument.
For example, an AND expression should be formatted the following
way: (V_AND, matcher1, matcher2)
.
Expressions using more than one operands should be bracketed, e.g.,
(V_OR (V_AND, matcher1, matcher2), matcher3)
.
The following oprations are available:
V_AND : Logical AND operation.
V_OR : Logical OR operation.
V_XOR : Logical XOR operation.
V_NOT : Logical negation.
V_EQ : Logical equation.
DNSMatcher retrieves the IP addresses of domain names. This can be used in domain name based policy decisions, for example to allow encrypted connections only to trusted e-banking sites.
DNSMatcher operates as follows: it resolves the IP addresses stored in the list of domain names using the specified Domain Name Server, and compares the results to the IP address of the connection (i.e., the IP address of the server or the client). The matcher returns a true value if the IP addresses resolved from the list of domain names include the IP address of the connection.
Method | Description |
---|---|
__init__(self, hosts, server, resolve_on_init) | Constructor to initialize an instance of the DNSMatcher class. |
Table 5.66. Method summary
Matcher policies can be used to find out if a parameter is included in a list, or which elements of a list correspond to a certain parameter), and influence the behavior of the proxy class based on the results. Matchers can be used for a wide range of tasks, for example, to determine if the particular IP address or URL that a client is trying to access is on a black or whitelist, or to verify that a particular e-mail address is valid.
MatcherPolicy instances are reusable matchers that contain configured instances of the matcher classes (e.g., DNSMatcher, RegexpMatcher). For examples, see the specific matcher classes.
This class is similar to RegexpMatcher, but stores the regular expressions to match and ignore in files. For example, this class can be used for URL filtering. The matcher itself stores only the paths and the filenames to the lists. The file is automatically monitored and reloaded when it is modified. Searches are case-insensitive.
Example 5.23. RegexpFileMatcher example |
---|
MatcherPolicy(name="demo_regexpfilematcher", matcher=RegexpFileMatcher(match_fname="/tmp/match_list.txt", ignore_fname="/tmp/ignore_list.txt")) |
Method | Description |
---|---|
__init__(self, match_fname, ignore_fname) | Constructor to initialize a RegexpFileMatcher instance. |
Table 5.67. Method summary
This constructor initializes an instance of the RegexpFileMatcher class.
A simple regular expression based matcher with a match and an ignore list. Searches are case-insensitive.
Method | Description |
---|---|
__init__(self, match_list, ignore_list, ignore_case) | Constructor to initialize a RegexpMatcher instance. |
Table 5.68. Method summary
This constructor initializes a RegexpMatcher instance by setting the
match
and ignore
attributes to an
empty list.
This class encapsulates a VRFY/RCPT based validity checker to transparently verify the existence of e-mail addresses. Instead of immediately sending the e-mail to the recipient SMTP server, an independent SMTP server is queried about the existence of the recipient e-mail address.
Instances of this class can be referred to in the recipient_matcher
attribute of the SmtpProxy class. The SmtpProxy
will automatically reject unknown recipients even if the recipient SMTP
server would accept them.
Method | Description |
---|---|
__init__(self, server_name, server_port, cache_timeout, force_delivery_attempt, sender_address, bind_name) |
Table 5.69. Method summary
bind_name (string) | |
---|---|
Default: "" | |
Specifies the hostname to bind to before initiating the connection to the SMTP server. |
cache_timeout (integer) | |
---|---|
Default: 60 | |
How long will the result of an address verification be retained (in seconds). |
force_delivery_attempt (boolean) | |
---|---|
Default: FALSE | |
Force a delivery attempt even if the autodetection code otherwise would use VRFY. Useful if the server always returns success for VRFY. |
WindowsUpdateMatcher is actually a DNSMatcher used to retrieve the IP addresses currently
associated with the v5.windowsupdate.microsoft.nsatc.net
,
v4.windowsupdate.microsoft.nsatc.net
, and
update.microsoft.nsatc.net
domain names from the specified name server.
Windows Update is running
on a distributed server farm, using the DNS round robin method and a short TTL to constantly change
the set of servers currently visible, consequently the IP addresses of the servers are constantly
changing.
Example 5.26. WindowsUpdateMatcher example |
---|
MatcherPolicy(name="demo_windowsupdatematcher", matcher=WindowsUpdateMatcher()) |
Method | Description |
---|---|
__init__(self, server) | Constructor to initialize an instance of the WindowsUpdateMatcher class. |
Table 5.70. Method summary
Network Address Translation (NAT) is a technology that can be used to change source or destination addresses in a connection from one IP address to another one. This module defines the classes performing the translation for IP addresses.
Several different NAT methods are supported using different NAT classes, like GeneralNAT or StaticNAT. To actually perform network address translation in a service, you have to use a NATPolicy instance that contains a configured NAT class. NAT policies provide a way to re-use NAT instances whithout having to define NAT mappings for each service individually.
Class | Description |
---|---|
AbstractNAT | Class encapsulating the abstract NAT interface. |
FWMark | Helper class to create packet mark value from gateway index number |
GeneralNAT | Class encapsulating a general subnet-to-subnet NAT. |
HashNAT | Class which sets the address from a hash table. |
LinkAvailabilityPFNat | Class encapsulating a general subnet-to-subnet NAT. |
NAT46 | Class that performs translation from IPv4 to IPv6 addresses (NAT46) |
NAT64 | Class that performs translation from IPv6 to IPv4 addresses (NAT64) |
NATPolicy | Class encapsulating named NAT instances. |
RandomNAT | Class generating a random IP address. |
StaticNAT | Class that replaces the source or destination address with a predefined address. |
Table 5.71. Classes of the NAT module
This class encapsulates an interface for application level network address translation (NAT). This NAT is different from the NAT used by packet filters: it modifies the outgoing source/destination addresses just before Vela connects to the server.
Source and destination NATs can be specified when a Service is created.
The NAT settings are used by the ConnectChainer class just before connecting to the server.
Method | Description |
---|---|
__init__(self) | Constructor to initialize an AbstractNAT instance. |
performTranslation(self, session, addrs, nat_type) | Function that performs the address translation. |
Table 5.72. Method summary
This constructor initializes an AbstractNAT instance. Currently it does nothing, but serves as a placeholder for future extensions.
This function is called before connecting a session to the destination server. The function returns the address (a SockAddr instance) to bind to before establishing the connection.
Method | Description |
---|---|
__init__(self, gw_mark) | Constructor to initialize an FWMark instance. |
Table 5.73. Method summary
This class encapsulates a general subnet-to-subnet NAT. It
requires a list of from, to, translated to
parameters:
from: the source address of the connection.
to: the destination address of the connection.
translated to: the translated address.
If the NAT policy is used as SNAT, the translated address is used to translate the source address of the connection; if the NAT policy is used as DNAT, the translated address is used to translate the destination address of the connection. The translation occurs according to the first matching rule.
Method | Description |
---|---|
__init__(self, mapping) | Constructor to initialize a GeneralNAT instance. |
Table 5.74. Method summary
HashNAT statically maps an IP address to another using a hash table. The table is indexed by the source IP address, and the value is the translated IP address. Both IP addresses are stored in string format.
Method | Description |
---|---|
__init__(self, ip_hash, default_reject) | Constructor to initialize a HashNAT instance. |
Table 5.75. Method summary
This constructor initializes a HashNAT instance.
This class encapsulates a subnet-to-subnet NAT, which is usable in PFService only, and limited to SNAT.
It requires a list of from, to, translated to, fwmark
parameters:
from: the source address of the connection.
to: the destination address of the connection.
translated to: the translated address.
fwmark: mark the packets of the traffic.
The NAT policy could be only used as SNAT, the translated address is used to translate the source address of the connection. The translation occurs according to the first matching rule. The translation happens in POSTROUTING mangle chain. This NAT adds an extra 4 bit FWMARK to the traffic, additionally to the PNS MARK bits. This can be used for advanced routing by FWMARK.
Method | Description |
---|---|
__init__(self, mapping) | Constructor to initialize a LinkAvailabilityPFNat instance. |
Table 5.76. Method summary
NAT46 embeds and IPv4 address into a specific portion of the IPv6 address according to the NAT46 specification as described in RFC6052 (http://tools.ietf.org/html/rfc6052#section-2.2).
Method | Description |
---|---|
__init__(self, prefix, prefix_mask, suffix) | Constructor to initialize a NAT46 instance. |
Table 5.77. Method summary
This constructor initializes a NAT46 instance.
NAT64 maps specific bits of the IPv6 address to IPv4 addresses according to the NAT64 specification as described in RFC6052 (http://tools.ietf.org/html/rfc6052#section-2.2).
Method | Description |
---|---|
__init__(self, prefix_mask) | Constructor to initialize a NAT64 instance. |
Table 5.78. Method summary
This class encapsulates a name and an associated NAT instance. NAT policies provide a way to re-use NAT instances whithout having to define NAT mappings for each service individually.
Method | Description |
---|---|
__init__(self, name, nat, cacheable) | Constructor to initialize a NAT policy. |
Table 5.79. Method summary
This contructor initializes a NAT policy.
This class randomly selects an address from a list of IP addresses. This can be used for load-balancing several lines by binding each session to a different interface.
Method | Description |
---|---|
__init__(self, addresses) | Constructor to initialize a RandomNAT instance. |
Table 5.80. Method summary
This class assigns a predefined value to the address of the connection.
Method | Description |
---|---|
__init__(self, addr) | Constructor to initialize a StaticNAT instance. |
Table 5.81. Method summary
Class | Description |
---|---|
AbstractNotificationMethod | Class encapsulating the abstract notification method. |
EmailNotificationMethod | Class sending out notifications in e-mail. |
NotificationPolicy | Class encapsulating a NotificationPolicy which describes how to send out notifications. |
Table 5.82. Classes of the Notification module
This abstract class encapsulates a notification that is performed when a certain event occurs.
Specialized classes can be derived from AbstractNotification, such as the EmailNotificationMethod class.
This class encapsulates a notification handler that sends an e-mail with the given mail properties.
Method | Description |
---|---|
__init__(self, recipient) | Constructor to initialize an EmailNotification instance. |
Table 5.83. Method summary
This module encapsulates the Proxy component. The Proxy module provides a common framework for protocol-specific proxies, implementing the functions that are used by all proxies. Protocol-specific proxy modules are derived from the Proxy module, and are described in Chapter 4, Proxies.
Function | Description |
---|---|
proxyLog | Function to send a proxy-specific message to the system log. |
Table 5.84. Function summary
Class | Description |
---|---|
Proxy | Class encapsulating the abstract proxy. |
Table 5.85. Classes of the Proxy module
This function sends a message into the system log. All messages start with the
session_id
that uniquely identifies the connection.
This class serves as the abstact base class for all proxies. When an instance of the Proxy class is created, it loads and starts a protocol-specific proxy. Proxies operate in their own threads, so this constructor returns immediately.
encryption_policy (class) | |
---|---|
Default: None | |
Name of the Encryption policy instance used to encrypt the sessions and verify the certificates used. For details, see Section 5.5, Module Encryption. |
ids_policy (class) | |
---|---|
Default: None | |
Name of the Ids policy instance used to send traffic to Intrusion Detection Systems. For details, see Section 5.6, Module Ids. |
Method | Description |
---|---|
closedByAbort(self) | Function called by the proxy core when an abort has been occured. |
config(self) | Function called by the proxy core to initialize the proxy instance. |
connectServer(self) | Function called by the proxy instance to establish the server-side connection. |
getCredentials(self, method, username, domain, target, port) | Function called when proxy requires credentials for server side authentication. |
invalidPolicyCall(self) | Invalid policy function called. |
setServerAddress(self, host, port) | Function called by the proxy instance to set the address of the destination server. |
setServerSideEncryption(self) | Function called by the proxy instance to set up the server side encryption parameters dynamically. |
userAuthenticated(self, entity, groups, auth_info) | Function called when inband authentication is successful. |
Table 5.86. Method summary
This function is called when a callback gives abort or no result. It simply sets a flag that will be used for logging the reason of the proxy's ending.
This function is called during proxy startup. It sets the attributes of the proxy instance according to the configuration of the proxy.
This function is called to establish the server-side connection.
The function either connects a proxy to the destination server,
or an embedded proxy to its parent proxy. The proxy may set the
address of the destination server using the setServerAddress
function.
The connectServer
function calls the chainer
specified in the service definition to connect to the remote server
using the host name and port parameters.
The connectServer
function returns the descriptor
of the server-side data stream.
The proxy instance calls this function to
retrieve authentication credentials for authentication method
method
and the target user username
.
This function is called when invalid policy function has been called.
The proxy instance calls this function to set the
address of the destination server.
This function attempts to resolve the hostname of the server using the DNS;
the result is stored in the session.server_address
parameter.
The address of the server may be modified later by the router of the service. See
Section 5.13, Module Router for details.
Note |
---|
The |
Function called by the proxy instance when the encryption scenario is dynamic (eg.: DynamicServerEncryption) to set up the server side encryption parameters. It should return with a DynamicServerEncryptionServerParams if DynamicServerEncryption scenario used otherwise with None.
This method unconditionally raises a NotImplementedError exception to indicate that it must be overridden by descendant classes like 'Proxy'.
The proxy instance calls this function to
indicate that the inband authentication was successfully
performed. The name of the client is stored in the
entity
parameter.
This module defines the AbstractResolver interface and various derived classes to perform name lookups.
Class | Description |
---|---|
AbstractResolver | Class encapsulating the abstract Resolver interface. |
DNSResolver | Class encapsulating DNS-based name resolution. |
HashResolver | Class encapsulating hash-based name resolution. |
Table 5.87. Classes of the Resolver module
This class encapsulates an interface for application level name resolution.
DNSResolver policies query the domain name server to resolve domain names.
Method | Description |
---|---|
__init__(self, name_server, timeout, use_search_domain) | Constructor to initialize a DNSResolver instance. |
Table 5.88. Method summary
HashResolver policies are used to locally store the IP addresses belonging to a domain name. A domain name (Hostname) and one or more corresponding IP addresses (Addresses) can be stored in a hash. If the domain name to be resolved is not included in the hash, the name resolution will fail. The HashResolver can be used to direct incoming connections to specific servers based on the target domain name.
Method | Description |
---|---|
__init__(self, mapping) | Constructor to initialize a HashResolver instance. |
Table 5.89. Method summary
Routers define the target IP address and port of the destination server, based on information that is available before started. The simplest router (DirectedRouter) selects a preset destination as the server address, while the most commonly used TransparentRouter connects to the IP address requested by the client. Other routers may make more complex decisions. The destination address selected by the router may be overridden by the proxy and the DNAT classes used in the service.
Routers also define source address and port of the server-side connection. This is the IP address that is used to connect the server. The server sees that the connection originates from this address. The following two parameters determine the source address used in the server-side connection:
forge_addr
: If set to TRUE
, the client's source address is used
as the source of the server-side connection. Otherwise, the IP address of the interface connected to
the server is used.
forge_port
: This parameter defines the source port that is
used in the server-side connection. Specify a port number as an integer value, or use one of the
following options:
Name | Description |
---|---|
V_PORT_ANY | Selected a random port between 1024
and 65535 . This is the default behavior of every router.
|
V_PORT_GROUP | Select a random port in the same group as the port used by
the client. The following groups are defined:
0-513 , 514-1024 ,
1025- .
|
V_PORT_EXACT | Use the same port as the client. |
V_PORT_RANDOM | Select a random port using a cryptographically secure function. |
Table 5.90. Options defining the source port of the server-side connection
Class | Description |
---|---|
AbstractRouter | Class encapsulating the abstract router. |
DirectedRouter | Class encapsulating a Router which explicitly defines the target address. |
InbandRouter | Class encapsulating the Router which extracts the destination address from the application-level protocol. |
TransparentRouter | Class encapsulating a Router which provides transparent services. |
Table 5.91. Classes of the Router module
AbstractRouter implements an abstract router that determines the destination address of the server-side connection. Service definitions should refer to a customized class derived from AbstractRouter, or one of the predefined router classes, such as TransparentRouter or DirectedRouter. Different implementations of this interface perform Transparent routing (directing the client to its original destination), and Directed routing (directing the client to a given destination).
A proxy can override the destination selected by the router using the the setServerAddress method.
forge_addr (boolean) | |
---|---|
Default: n/a | |
If set to TRUE , the
client's source address is used as the source of the server-side connection.
|
forge_port (unknown) | |
---|---|
Default: n/a | |
Defines the source port that is used in the server-side connection. See Section 5.13.1, The source address used in the server-side connection for details. |
This class implements directed routing, which means that the destination address is a preset address for each session.
Method | Description |
---|---|
__init__(self, dest_addr, forge_addr, overrideable, forge_port) | Constructor to initialize a DirectedRouter. |
Table 5.92. Method summary
This constructor initializes an instance of the DirectedRouter class.
forge_addr (boolean) | |
---|---|
Default: FALSE | |
If set to TRUE ,
the client's source address is used as the source of the
server-side connection.
|
forge_port (complex) | |
---|---|
Default: V_PORT_ANY | |
Defines the source port that is used in the server-side connection. See Section 5.13.1, The source address used in the server-side connection for details. |
This class implements inband routing, which means that the destination address will be determined by the protocol. Inband routing works only for protocols that can send routing information within the protocol, and is mainly used for non-transparent proxying. The InbandRouter class currently supports only the HTTP and FTP protocols.
Method | Description |
---|---|
__init__(self, forge_addr, forge_port) | Constructor to initialize a InbandRouter. |
Table 5.93. Method summary
This constructor initializes an instance of the InbandRouter class.
forge_addr (boolean) | |
---|---|
Default: FALSE | |
If set to TRUE , the client's source address is used as the source of the server-side connection.
|
forge_port (complex) | |
---|---|
Default: V_PORT_ANY | |
Defines the source port that is used in the server-side connection. See Section 5.13.1, The source address used in the server-side connection for details. |
This class implements transparent routing, which means that the destination server is the original destination requested by the client.
forced_port (unknown) | |
---|---|
Default: n/a | |
Defines the source port that is used in the server-side connection. See Section 5.13.1, The source address used in the server-side connection for details. |
Method | Description |
---|---|
__init__(self, forced_port, forge_addr, overrideable, forge_port) | Constructor to initialize an instance of the TransparentRouter class. |
Table 5.94. Method summary
This constructor creates a new TransparentRouter instance which can be associated with a Service.
forced_port (integer) | |
---|---|
Default: 0 | |
Modify the destination port to this value. Default value: 0 (do not modify the target port) |
forge_addr (boolean) | |
---|---|
Default: FALSE | |
If set to TRUE , the client's source address is used as
the source of the server-side connection.
|
forge_port (complex) | |
---|---|
Default: V_PORT_ANY | |
Defines the source port that is used in the server-side connection. See Section 5.13.1, The source address used in the server-side connection for details. |
The Rule module defines the classes needed to create firewall rules.
When Application-level Gateway receives a connection request from a client, it tries to select a rule matching the parameters of the connection. The following parameters are considered.
Name in MC | Name in policy.py |
---|---|
VPN | reqid |
Source Interface | src_iface |
Source Interface Group | src_ifgroup |
Protocol | proto |
ICMP type | icmp_type |
ICMP code | icmp_code |
Source Port | src_port |
Destination Port | dst_port |
Source Subnet | src_subnet |
Source Zone | src_zone |
Destination Subnet | dst_subnet |
Destination Interface | dst_iface |
Destination Interface Group | dst_ifgroup |
Destination Zone | dst_zone |
Table 5.95. Evaluated Rule parameters
If a connections matches multiple rules, then the rule with the most-specific match is selected. Selecting the most specific rule is based on the following method.
The order of the rules is not important.
The parameters of the connection act as filters: if you do not set any parameters, the rule will match any connection.
If multiple connections would match a connection, the rule with the most-specific match is selected.
For example, you have configured two rules: the first has the Source Zone
parameter set as the office
(which is a zone covering all of your client IP addresses), the second has the Source Subnet
parameter set as 192.168.15.15/32
. The other parameters of the rules are the same. If a connection request arrives from the 192.168.15.15/32
address, Application-level Gateway will select the second rule. The first rule will match every other client request.
Application-level Gateway considers the parameters of a connection in groups. The first group is the least-specific, the last one is the most-specific. The parameter groups are listed below.
The parameter groups are linked with a logical AND operator: if parameters of multiple groups are set in a rule, the connection request must match a parameter of every group. For example, if both the Source Interface
and Destination Port
are set, the connection must match both parameters.
Parameters within the same group are linked with a logical OR operator: if multiple parameters of a group are set for a rule, the connection must match any one of the parameters. If there are multiple similar rules, the rule with the most specific parameter match for the connection will be selected.
Note |
---|
In general, avoid using multiple parameters of the same group in one rule, as it may lead to undesired side-effects. Use only the most specific parameter matching your requirements. For example, suppose that you have a rule with the |
The parameter groups are the following from the least specific to the most specific ones. Parameters within each group are listed from left to right from the least specific to the most specific ones.
Destination Zone
> Destination Interface Group
> Destination Interface
> Destination Subnet
Source Zone
> Source Subnet
Destination Port
(Note that port is more specific than port range.)
Source Port
(Note that port is more specific than port range.)
Protocol
Source Interface Group
> Source Interface
> VPN
If no matching rule is found, Application-level Gateway rejects the connection.
Note |
---|
It is possible to create rules that are very similar, making debugging difficult. |
To make the configuration file more readable and informative, you can add descriptions and tags to the rules. Descriptions can be longer texts, while tags are simple labels, for example, to identify rules that belong to the same type of traffic. Adding metadata to rules is not necessary, but can be a great help when maintaining large configurations.
To add a description to a rule, add the text of the description before the rule, enclosed between three double-quotes:
"""This rule is ..."""
To tag a rule, add a comment line before the rule that contains the list of tags applicable to the rule, separated with commas.
#Tags: tag1, tag2
Class | Description |
---|---|
PortRange | Specifies a port range for a rule |
Rule | This class implements firewall rules |
Table 5.96. Classes of the Rule module
This class specifies a port range for a firewall rule. It can be used in the src_port
and dst_port
parameters of a rule. For example: src_port=PortRange(2000, 2100)
, or src_port=(PortRange(2000, 2100), PortRange(2500, 2600))
. When listing multiple elements, ports and port ranges can be mixed, for example: src_port=(4433, PortRange(2000, 2100), PortRange(2500, 2600))
This class implements firewall rules. For details, see Section 5.14, Module Rule.
Initializes a rule
dst_port (integer) | |
---|---|
Default: n/a | |
Permit traffic only if the client targets the listed port. For example, dst_port=80 , or dst_port=(80, 443) . To specify port ranges, use the PortRange class, for example, dst_port=PortRange(2000, 2100) . |
icmp_code (integer) | |
---|---|
Default: n/a | |
If proto is set to ICMP (1), restrict further what the ICMP packet is used for.
If absent, the rule will match to any ICMP code value. |
icmp_type (integer) | |
---|---|
Default: n/a | |
If proto is set to ICMP (1), restrict further what the ICMP packet is used for.
If absent, the rule will match to any ICMP type value. |
proto (integer) | |
---|---|
Default: n/a | |
Permit only connections using the specified transport protocol. This is the transport layer (Layer 4) protocol of the OSI model, for example, TCP, UDP, ICMP, and so on. The protocol must be specified using a number: the decimal value of the "protocol" field of the IP header. This value is 6 for the TCP and 17 for the UDP protocol. For a list of protocol numbers, see the Assigned Internet Protocol Numbers page of IANA. For example: proto=(6,17) .
To permit any protocol, do not add the |
rule_id (integer) | |
---|---|
Default: n/a | |
A unique ID number for the rule. This parameter is optional, an ID number is automatically generated for the rule during startup. |
src_iface (interface) | |
---|---|
Default: n/a | |
Permit traffic only for connections received on the listed interface. For example, src_iface='eth0', or src_iface=('eth0', 'tun1'), . |
src_port (integer) | |
---|---|
Default: n/a | |
Permit traffic only if the client sends the connection request from the listed port. For example, src_port=4455 . To specify port ranges, use the PortRange class, for example, src_port=PortRange(2000, 2100) . |
This module defines classes encapsulating service descriptions. The
services define how the incoming connection requests are handled.
When a connection is accepted by a Rule, the service specified in the
Rule creates an instance of itself.
This instance handles the connection, and
proxies the traffic between the client and the server.
It also handles TLS and SSL encryption of the traffic if needed, as
configured in the encryption_policy
parameter
of the service.
The instance of the selected service is created using the 'startInstance()'
method.
A service is not usable on its own, it needs a Rule to bind the service to a network interface of the firewall and activate it when a matching connection request is received. New instances of the service are started as the Rule accepts new connections.
The name of the service must be a unique identifier; rules refer to this unique ID.
Use clear, informative, and consistent service names. Include the following information in the service name:
Source zones, indicating which clients may use the service (e.g.,
intranet
).
The protocol permitted in the traffic (e.g.,
HTTP
).
Destination zones, indicating which servers may be accessed using the service
(e.g., Internet
).
Tip |
---|
Name the service that allows internal users to browse the Web
|
Class | Description |
---|---|
AbstractService | Class encapsulating the abstract Service properties. |
DenyService | DenyService prohibits access to certain services |
PFService | Class encapsulating a packet-filter service definition. |
Service | Class encapsulating a service definition. |
Table 5.98. Classes of the Service module
AbstractService implements an abstract service. Service definitions should be based on a customized class derived from AbstractService, or on the predefined Service class.
Method | Description |
---|---|
__init__(self, name) | Constructor to initialize an instance of the AbstractService class. |
Table 5.99. Method summary
This constructor creates an AbstractService instance and sets the attributes of the instance
according to the received arguments. It also registers the Service to the
services
hash so that rules can find the service instance.
The DenyService class is a type of service that rejects connections with a predefined error code. DenyServices can be specified in the service
parameter of Rules. If the rule referencing the DenyService matches a connection request, the connection is rejected. DenyService is a replacement for the obsolete Umbrella zone concept.
ipv6_setting (complex) | |
---|---|
Default: n/a | |
Specifies how to reject IPv6 traffic. By default, the traffic is dropped without notifying the client (DenyIPv6.DROP ). The following values are available: DenyIPv6.DROP , DenyIPv6.TCP_RESET , DenyIPv6.ICMP_NO_ROUTE , DenyIPv6.ICMP_ADMIN_PROHIBITED , DenyIPv6.ICMP_ADDR_UNREACHABLE , DenyIPv6.ICMP_PORT_UNREACHABLE
|
Method | Description |
---|---|
__init__(self, name, logging, ipv4_setting, ipv6_setting, log_verbose, log_spec, limit_policy) | Constructor to initialize a DenyService instance. |
Table 5.100. Method summary
PFServices allow you to replace the forwarding rules of nftables or iptables, and configure application-level and packet-filter rules from Vela.
Note |
---|
The PFService class transfers packet-filter level services. |
Example 5.37. PFService example |
---|
The following packet-filtering service transfers TCP connections
that arrive to port PFService(name="intranet_PF5555_internet", router=TransparentRouter()) The following example defines a few classes: the client and server zones, a simple services, and a rule that starts the service. Zone('internet', ['0.0.0.0/0']) Zone('intranet', ['192.168.0.0/16']) def demo() : PFService(name="intranet_PF5555_internet", router=TransparentRouter()) Rule(dst_port=5555, src_zone='intranet', dst_zone='internet', service='PFService' ) |
dnat_policy (class) | |
---|---|
Default: n/a | |
Name of the NAT policy instance used to translate the destination addresses of the sessions. See Section 5.9, Module NAT for details. |
geoip_policy (class) | |
---|---|
Default: None | |
Name of the GeoIpPolicy instance used to restrict geographical location based of the sessions. |
limit_policy (class) | |
---|---|
Default: None | |
Name of the LimitPolicy instance used to rate limit the sessions. |
router (class) | |
---|---|
Default: n/a | |
A router instance used to determine the destination address of the server. See Section 5.13, Module Router for details. |
snat_policy (class) | |
---|---|
Default: n/a | |
Name of the NAT policy instance used to translate the source addresses of the sessions. See Section 5.9, Module NAT for details. |
Method | Description |
---|---|
__init__(self, name, router, snat_policy, dnat_policy, log_verbose, log_spec, limit_policy, geoip_policy) | Constructor to initialize a PFService instance. |
Table 5.101. Method summary
This constructor defines a packetfilter-service with the specified parameters.
A service is one of the fundamental objects. It stores the names of proxy-related parameters, and is also used for access control purposes to decide what kind of traffic is permitted.
Note |
---|
The Service class transfers application-level (proxy) services. |
Example 5.38. Service example |
---|
The following service transfers HTTP connections. Every parameter is left at its default. Service(name="demo_http, proxy_class=HttpProxy, router=TransparentRouter()) The following service handles HTTP connections. This service uses authentication and authorization, and network address translation on the client addresses (SNAT). Service(name="demo_http", proxy_class=HttpProxy, authentication_policy="demo_authentication_policy", authorization_policy="demo_permituser", snat_policy="demo_natpolicy", router=TransparentRouter()) The following example defines a few classes: the client and server zones, a simple services, and a rule that starts the service. Zone('internet', ['0.0.0.0/0']) Zone('office', ['192.168.1.0/32', '192.168.2.0/32']) def demo_instance() : Service(name="office_http_inter", proxy_class=HttpProxy, router=TransparentRouter()) Rule(src_zone='office', proto=6, dst_zone='internet', service='office_http_inter' ) |
auth_name (string) | |
---|---|
Default: n/a | |
Authentication name of the service. This string informs the users of the Authentication Agent about which service they are authenticating for. Default value: the name of the service. |
authentication_policy (class) | |
---|---|
Default: n/a | |
Name of the AuthenticationPolicy instance used to authenticate the clients. See Section 5.1, Module Auth for details. |
authorization_policy (class) | |
---|---|
Default: n/a | |
Name of the AuthorizationPolicy instance used to authorize the clients. See Section 5.1, Module Auth for details. |
chainer (class) | |
---|---|
Default: n/a | |
A chainer instance used to connect to the destination server. See Section 5.3, Module Chainer for details. |
dnat_policy (class) | |
---|---|
Default: n/a | |
Name of the NAT policy instance used to translate the destination addresses of the sessions. See Section 5.9, Module NAT for details. |
encryption_policy (class) | |
---|---|
Default: None | |
Name of the Encryption policy instance used to encrypt the sessions and verify the certificates used. For details, see Section 5.5, Module Encryption. |
keepalive (integer) | |
---|---|
Default: V_KEEPALIVE_NONE | |
The TCP keepalive option, one of the V_KEEPALIVE_NONE, V_KEEPALIVE_CLIENT, V_KEEPALIVE_SERVER, V_KEEPALIVE_BOTH values. |
limit_policy (class) | |
---|---|
Default: None | |
Name of the LimitPolicy instance used to rate limit the sessions. |
max_instances (integer) | |
---|---|
Default: n/a | |
Permitted number of concurrent instances of this service.
Usually each service instance handles
one connection. The default value is 0 ,
which allows unlimited number of instances.
|
proxy_class (class) | |
---|---|
Default: n/a | |
Name of the proxy class instance used to analyze the traffic transferred in the session. See Section 5.11, Module Proxy for details. |
resolver_policy (unknown) | |
---|---|
Default: n/a | |
Name of the ResolvePolicy instance used to resolve
the destination domain names.
See Section 5.12, Module Resolver for details.
Default value: DNSResolver
|
router (class) | |
---|---|
Default: n/a | |
A router instance used to determine the destination address of the server. See Section 5.13, Module Router for details. |
snat_policy (class) | |
---|---|
Default: n/a | |
Name of the NAT policy instance used to translate the source addresses of the sessions. See Section 5.9, Module NAT for details. |
Method | Description |
---|---|
__init__(self, name, proxy_class, router, chainer, snat_policy, dnat_policy, authentication_policy, authorization_policy, max_instances, max_sessions, auth_name, resolver_policy, keepalive, encryption_policy, limit_target_zones_to, detector_config, detector_default_service_name, session_counting, limit_policy, geoip_policy) | Constructor to initialize a Service instance. |
startInstance(self, session) | Start a service instance. |
Table 5.102. Method summary
This contructor defines a Service with the specified parameters.
auth_name (string) | |
---|---|
Default: None | |
Authentication name of the service. This string informs the users of the Authentication Agent about which service they are authenticating for. Default value: the name of the service. |
authentication_policy (class) | |
---|---|
Default: None | |
Name of the AuthenticationPolicy instance used to authenticate the clients. See Section 5.1, Module Auth for details. |
authorization_policy (class) | |
---|---|
Default: None | |
Name of the AuthorizationPolicy instance used to authorize the clients. See Section 5.1, Module Auth for details. |
chainer (class) | |
---|---|
Default: None | |
Name of the chainer instance used to connect to the destination server. Defaults to ConnectChainer if no other chainer is specified. |
dnat_policy (class) | |
---|---|
Default: None | |
Name of the NAT policy instance used to translate the destination addresses of the sessions. See Section 5.9, Module NAT for details. |
encryption_policy (class) | |
---|---|
Default: None | |
Name of the Encryption policy instance used to encrypt the sessions and verify the certificates used. For details, see Section 5.5, Module Encryption. |
geoip_policy (class) | |
---|---|
Default: None | |
Name of the GeoIpPolicy instance used to restrict geographical location based of the sessions. |
keepalive (integer) | |
---|---|
Default: V_KEEPALIVE_NONE | |
The TCP keepalive option, one of the V_KEEPALIVE_NONE, V_KEEPALIVE_CLIENT, V_KEEPALIVE_SERVER, V_KEEPALIVE_BOTH values. |
limit_policy (class) | |
---|---|
Default: None | |
Name of the LimitPolicy instance used to rate limit the sessions. |
limit_target_zones_to (complex) | |
---|---|
Default: None | |
A comma-separated list of zone names permitted as the target of the service. No restrictions are applied if the list is empty. |
max_instances (integer) | |
---|---|
Default: 0 | |
Permitted number of concurrent instances of this service. Usually each
service instance handles one connection. Default value: 0 (unlimited).
|
proxy_class (class) | |
---|---|
Default: n/a | |
Name of the proxy class instance used to analyze the traffic transferred in the session. See Section 5.11, Module Proxy for details. |
resolver_policy (class) | |
---|---|
Default: None | |
Name of the ResolvePolicy instance used to resolve the destination domain names.
See Section 5.12, Module Resolver for details.
Default value: DNSResolver .
|
router (class) | |
---|---|
Default: None | |
Name of the router instance used to determine the destination address of the server. Defaults to TransparentRouter if no other router is specified. |
snat_policy (class) | |
---|---|
Default: None | |
Name of the NAT policy instance used to translate the source addresses of the sessions. See Section 5.9, Module NAT for details. |
This module defines the abstract session interface in a class named
AbstractSession
, and two descendants MasterSession
and StackedSession
.
Sessions are hierarchically stacked into each other just like proxies.
All sessions except the master session have a parent session from which child sessions inherit variables.
Child sessions are stacked into their master sessions, so stacked sessions can inherit data from the encapsulating
proxy instances.
(Inheritance is implemented using a simple getattr
wrapper.)
Instances of the Session classes store the parameters of the client-side and server-side connections in a session object (for example, the IP addresses and zone of the server and the client, and the username and group memberships of the user when authentication is used). Other components refer to this data when making various policy-based decisions.
Class | Description |
---|---|
StackedSession | Class encapsulating a subsession. |
Table 5.103. Classes of the Session module
This class represents a stacked session, e.g., a session within the session hierarchy. Every subsession inherits session-wide parameters from its parent.
chainer (class) | |
---|---|
Default: n/a | |
The chainer used to connect to the parent proxy. If unset, the
server_stream parameter must be set.
|
server_address (class) | |
---|---|
Default: n/a | |
The IP address to connect. Most often this is the IP address requested by the client, but the client requests can be redirected to different IPs. |
server_local (class) | |
---|---|
Default: n/a | |
The server is connected from this IP address. This is either the IP address of Vela's external interface, or the IP address of the client (if Forge Port is enabled). The client's original IP address may be modified if SNAT policies are used. |
target_address (class) | |
---|---|
Default: n/a | |
The IP address to connect. Most often this is the IP address requested by the client, but the client requests can be redirected to different IPs. |
Method | Description |
---|---|
setTargetAddress(self, addr) | Set the target server address. |
Table 5.104. Method summary
This module implements inet_ntoa
and inet_aton
. The module also provides an interface
to the SockAddr services of the vela core. SockAddr is used for example to define the address of the AS server in
AuthenticationProvider policies.
Class | Description |
---|---|
SockAddrInet | Class encapsulating an IPv4 address:port pair. |
SockAddrInet6 | Class encapsulating an IPv6 address:port pair. |
SockAddrInetHostname | Class encapsulating a hostname:port pair. |
SockAddrInetRange | Class encapsulating an IPv4 address and a port range. |
SockAddrUnix | Class encapsulating a UNIX domain socket. |
Table 5.105. Classes of the SockAddr module
This class encapsulates an IPv4 address:port pair, similarly to
the sockaddr_in
struct in C. The class is implemented and exported by
the vela core. The SockAddrInet
Python class serves only
documentation purposes, and has no real connection to the
behavior implemented in C.
Example 5.39. SockAddrInet example |
---|
The following example defines an IPv4 address:port pair. SockAddrInet('192.168.10.10', 80) The following example uses SockAddrInet in a dispatcher. Dispatcher(transparent=TRUE, bindto=DBSockAddr(protocol=VD_PROTO_TCP, sa=SockAddrInet('192.168.11.11', 50080)), service="intra_HTTP_inter", backlog=255, rule_port="50080") |
This class encapsulates an IPv6 address:port pair, similarly to
the sockaddr_in
struct in C. The class is implemented and exported by
the vela core. The SockAddrInet
Python class serves only
documentation purposes, and has no real connection to the
behavior implemented in C.
Example 5.40. SockAddrInet example |
---|
The following example defines an IPv6 address:port pair. SockAddrInet('fec0::1', 80) The following example uses SockAddrInet in a dispatcher. Dispatcher(transparent=TRUE, bindto=DBSockAddr(protocol=VD_PROTO_TCP, sa=SockAddrInet('fec0::1', 50080)), service="intra_HTTP_inter", backlog=255, rule_port="50080") |
This class encapsulates a hostname:port or IPv4 address:port pair. Name resolution is only performed when creating
the SockAddrInetHostname object (that is, during startup and reload).
The class is implemented and exported by the vela core. The SockAddrInetHostname
Python class serves only documentation purposes, and has no real connection to the
behavior implemented in C.
Example 5.41. SockAddrInetHostname example |
---|
The following example defines a hostname:port or IPv4 address:port pair. SockAddrInetHostname('www.example.com', 80) SockAddrInetHostname('192.168.10.10', 80) The following example uses SockAddrInetHostname in a dispatcher. Dispatcher(transparent=TRUE, bindto=DBSockAddr(protocol=VD_PROTO_TCP, sa=SockAddrInetHostname('www.example.com', 50080)), service="intra_HTTP_inter", backlog=255, rule_port="50080") |
A specialized SockAddrInet class which allocates a new port
within the given range of ports when a dispatcher bounds to it.
The class is implemented and exported by
the vela core. The SockAddrInetRange
Python class serves only
documentation purposes, and has no real connection to the
behavior implemented in C.
This class encapsulates a UNIX domain socket endpoint.
The socket is represented by a filename. The SockAddrUnix
Python class serves only
documentation purposes, and has no real connection to the
behavior implemented in C.
Example 5.42. SockAddrUnix example |
---|
The following example defines a Unix domain socket. SockAddrUnix('/var/sample.socket') The following example uses SockAddrUnix in a DirectedRouter. Service(name="demo_service", proxy_class=HttpProxy, router=DirectedRouter(dest_addr=SockAddrUnix('/var/sample.socket'), overrideable=FALSE, forge_addr=FALSE)) |
Vela is capable of stacking, that is, handing over parts of the traffic to other modules for further inspection (e.g., to other proxies to inspect embedded protocols, to content filtering modules for virus filtering, etc.). The Stack module defines the classes required for this functionality.
Stacking in services is performed using StackingProvider policies, which reference the host that performs the stacked operations using the RemoteStackingBackend class.
Class | Description |
---|---|
AbstractStackingBackend | This is an abstract class, currently without any functionality. |
RemoteStackingBackend | Constructor to initialize an instance of the RemoteStackingBackend class. |
StackingProvider | This is a policy class that is used to reference a configured stacking provider in service definitions. |
Table 5.106. Classes of the Stack module
This is an abstract class, currently without any functionality.
This class contains the address of the host that performs the stacked
operations. It is typically used to access the Content Filtering
Server (CF) to perform virus filtering in the traffic. The remote
backend can be accessed using the TCP protocol or a local socket,
e.g., RemoteStackingBackend(addrs=(SockAddrInet('192.168.2.3', 1318),))
or RemoteStackingBackend(addrs=(SockAddrUnix('/var/run/vcf/vcf.sock'),)).
.
addrs (complex) | |
---|---|
Default: n/a | |
The address of the remote backend in SockAddrInet or SockAddrUnix format. Separate addresses with commas to list more than one address for a backend. Vela will connect to these addresses in a failover fashion. |
Instances of the StackingProvider class are policies that define which remote stacking backend a particular service uses to inspect the contents of the traffic.
Example 5.43. A simple StackingProvider class |
---|
The following class creates a simple stacking provider that
can be referenced in service definitions. The remote host that
provides the stacking services is located under the
StackingProvider(name="demo_stackingprovider", backend=RemoteStackingBackend(addrs=(SockAddrInet('192.168.12.12', 1318),))) |
Example 5.44. Using a StackingProvider in an FTP proxy |
---|
The following classes define a stacking provider that can be accesses a local CF instance using a domain socket. This service provider is then used to filter FTP traffic. The configuration of the CF (i.e., what modules it uses to filter the traffic is not discussed here). class StackingFtpProxy(FtpProxy): def config(self): super(StackingFtpProxy, self).config() self.request_stack["RETR"]=(FTP_STK_DATA, (V_STACK_PROVIDER, "demo_stackingprovider", "default_rulegroup")) StackingProvider(name="demo_stackingprovider_socket", backend=RemoteStackingBackend(addrs=(SockAddrUnix('/var/run/vcf/vcf.sock'),))) |
Method | Description |
---|---|
__init__(self, name, backend) | Constructor to initialize an instance of the StackingProvider class. |
Table 5.108. Method summary
This constructor creates a StackingProvider instance and sets the attributes of the instance according to the received arguments.
backend (class) | |
---|---|
Default: n/a | |
A configured
RemoteStackingBackend class containing the address
of the remote stacking backend, e.g.,
RemoteStackingBackend(addrs=(SockAddrInet('192.168.2.3', 1318),)) or RemoteStackingBackend(addrs=(SockAddrUnix('/var/run/vcf/vcf.sock'),)).
.
|
This module defines the Zone
class.
Zones are the basis of access control. A zone consists of a set of IP addresses, address ranges, or subnet. For example, a zone can contain an IPv4 or IPv6 subnet.
Zones are organized into a hierarchy created by the administrator. Child zones inherit the security attributes (set of permitted services etc.) from their parents. The administrative hierarchy often reflects the organization of the company, with zones assigned to the different departments.
When it has to be determined what zone a client belongs to, the most specific zone containing the searched IP address is selected. If an IP address belongs to two different zones, the most specific zone is selected.
Example 5.45. Finding IP networks |
---|
Suppose there are three zones configured: This approach is used in the service definitions as well: when a client sends a
connection request, the most specific zone containing the IP address of the
client is looked up. Suppose that the clients in |
Example 5.46. Zone examples |
---|
The following example defines a simple zone hierarchy. The following zones are defined:
Zone('internet', ['0.0.0.0/0', '::0/0']) Zone('office', ['192.168.1.0/32', '192.168.2.0/32']) Zone('management', ['192.168.3.0/32']) Zone('DMZ', ['10.50.0.0/32']) |
This class encapsulates IPv4 and IPv6 zones.
Example 5.47. Determining the zone of an IP address |
---|
An IP address always belongs to the most specific zone.
Suppose that |
Method | Description |
---|---|
__init__(self, name, addrs, hostnames, admin_parent) | Constructor to initialize a Zone instance |
Table 5.110. Method summary
This constructor initializes a Zone object.
addrs (complex) | |
---|---|
Default: n/a | |
A string representing an address range interpreted by the domain class (last argument), or a list of strings representing multiple address ranges. |
admin_parent (string) | |
---|---|
Default: n/a | |
Name of the administrative parent zone. If set, the current zone inherits the lists of permitted inbound and outbound services from its administrative parent zone. |
This chapter provides information about some of the internal PNS modules.
Caching is used throughout the policy layer to improve performance. This module includes a couple of general caching classes used by various parts of the policy code.
This module imports all public interfaces and makes it easy to use those from the user policy file by simply importing all symbols from Vela.Core.
Dispatchers bind to a specific IP address and port of the Vela firewall and wait for incoming connection requests. For each accepted connection, the Dispatcher creates a new service instance to handle the traffic arriving in the connection.
For each accepted connection, the Dispatcher creates a new service instance to handle the traffic arriving in the connection. The service started by the dispatcher depends on the type of the dispatcher:
Dispatchers start the same service for every connection.
CSZoneDispatchers start different services based on the zones the client and the destination server belong to.
Note |
---|
Only one dispatcher can bind to an IP address/port pair. |
Dispatchers can start only a predefined service. Use
CSZonedDispatchers to start different services for different connections.
CSZoneDispatchers assign different services to different client-server zone pairs.
Define the zones and the related services in the
services
parameter.
The *
wildcard matches all client or server zones.
Note |
---|
The server zone may be modified by the proxy, the router, the chainer, or the NAT policy used in the service. To select the service, CSZoneDispatcher determines the server zone from the original destination IP address of the incoming client request. Similarly, the client zone is determined from the source IP address of the original client request. |
To accept connections from the child zones of the selected client
zones, set the follow_parent
attribute
to TRUE
. Otherwise, the dispatcher accepts
traffic only from the client zones explicitly listed in the
services
attribute of the dispatcher.
Class | Description |
---|---|
CSZoneDispatcher | Class encapsulating the Dispatcher which starts a service by the client and server zone. |
Dispatcher | Class encapsulating the Dispatcher which starts a service by the client and server zone. |
Table 6.1. Classes of the Dispatch module
This class is similar to a simple Dispatcher, but instead of starting a fixed service, it chooses one based on the client and the destined server zone.
It takes a mapping of services indexed by a client and the server zone name, with an exception of the '*' zone, which matches anything.
NOTE: the server zone might change during proxy and NAT processing, therefore the server zone used here only matches the real destination if those phases leave the server address intact.
Example 6.1. CSZoneDispatcher example |
---|
The following example defines a CSZoneDispatcher that
starts the service called CSZoneDispatcher(bindto=SockAddrInet('192.168.2.1', 50080), services={("internet", "DMZ"):"internet_HTTP_DMZ"}, transparent=TRUE, backlog=255, threaded=FALSE, follow_parent=FALSE) |
Method | Description |
---|---|
__init__(self, bindto, services, **kw) | Constructor to initialize a CSZoneDispatcher instance. |
Table 6.2. Method summary
This constructor initializes a CSZoneDispatcher instance and sets its initial attributes based on arguments.
bindto (sockaddr) | |
---|---|
Default: n/a | |
An existing socket address containing the IP address and port number where the Dispatcher accepts connections. |
This class is the starting point of services. It listens on the given port, and when a connection is accepted it starts a session and the given service.
Example 6.2. Dispatcher example |
---|
The following example defines a transparent dispatcher that
starts the service called Dispatcher(bindto=SockAddrInet('192.168.2.1', 50080), service="demo_http_service", transparent=TRUE, backlog=255, threaded=FALSE) |
backlog (integer) | |
---|---|
Default: n/a | |
Applies only to TCP connections. This parameter sets the queue size (maximum number) of TCP connections that are established by the kernel, but not yet accepted by Vela. This queue stores the connections that successfully performed the three-way TCP handshake with the Vela host, until the dispatcher sends the Accept package. |
bindto (sockaddr) | |
---|---|
Default: n/a | |
An existing socket address containing the IP address and port number where the Dispatcher accepts connections. |
threaded (boolean) | |
---|---|
Default: n/a | |
Set this parameter to TRUE
to start a new thread for every client request. The proxy threads
started by the dispatcher will start from the dispatcher's thread
instead of the main thread. Incoming connections are accepted
faster and optimizes queuing if this option is enabled. This
improves user experience, but significantly increases the memory
consumption of Vela. Use it only if a
very high number of concurrent connections have to be transfered.
|
Method | Description |
---|---|
__init__(self, bindto, service, **kw) | Constructor to initialize a Dispatcher instance. |
Table 6.3. Method summary
This constructor creates a new Dispatcher instance which can be associated with a Service.
bindto (sockaddr) | |
---|---|
Default: n/a | |
An existing socket address containing the IP address and port number where the Dispatcher accepts connections. |
This module defines the Stream class, encapsulating file descriptors and related functions.
Class | Description |
---|---|
Stream | Class encapsulating the file descriptor and related functions. |
Table 6.4. Classes of the Stream module
This class encapsulates a full-duplex data tunnel, represented by
a UNIX file descriptor. Proxies communicate with its peers through
instances of this class. The client_stream
and server_stream
attributes of the Session class contain a
Stream instance.
Method | Description |
---|---|
__init__(self, fd, name) | Constructor to initialize a stream. |
Table 6.5. Method summary
The constants defined for the easier use of TELNET options and suboptions are listed in the table below. Suboptions are listed directly under the option they refer to. All suboptions have the TELNET_SB prefix. The RFC describing the given option is also shown in the table.
Name | Constant value of option/suboption | Detailed in RFC # |
---|---|---|
TELNET_BINARY | 0 | 856 |
TELNET_ECHO | 1 | 857 |
TELNET_SUPPRESS_GO_AHEAD | 3 | 858 |
TELNET_STATUS | 5 | 859 |
TELNET_SB_STATUS_SB_IS | 0 | |
TELNET_SB_STATUS_SB_SEND | 1 | |
TELNET_TIMING_MARK | 6 | 860 |
TELNET_RCTE | 7 | 726 |
TELNET_NAOCRD | 10 | 652 |
TELNET_SB_NAOCRD_DR | 0 | |
TELNET_SB_NAOCRD_DS | 1 | |
TELNET_NAOHTS | 11 | 653 |
TELNET_SB_NAOHTS_DR | 0 | |
TELNET_SB_NAOHTS_DS | 1 | |
TELNET_NAOHTD | 12 | 654 |
TELNET_SB_NAOHTD_DR | 0 | |
TELNET_SB_NAOHTD_DS | 1 | |
TELNET_NAOFFD | 13 | 655 |
TELNET_SB_NAOFFD_DR | 0 | |
TELNET_SB_NAOFFD_DS | 1 | |
TELNET_NAOVTS | 14 | 656 |
TELNET_SB_NAOVTS_DR | 0 | |
TELNET_SB_NAOVTS_DS | 1 | |
TELNET_NAOVTD | 15 | 657 |
TELNET_SB_NAOVTD_DR | 0 | |
TELNET_SB_NAOVTD_DS | 1 | |
TELNET_NAOLFD | 16 | 658 |
TELNET_SB_NAOLFD_DR | 0 | |
TELNET_SB_NAOLFD_DS | 1 | |
TELNET_EXTEND_ASCII | 17 | 698 |
TELNET_LOGOUT | 18 | 727 |
TELNET_BM | 19 | 735 |
TELNET_SB_BM_DEFINE | 1 | |
TELNET_SB_BM_ACCEPT | 2 | |
TELNET_SB_BM_REFUSE | 3 | |
TELNET_SB_BM_LITERAL | 4 | |
TELNET_SB_BM_CANCEL | 5 | |
TELNET_DET | 20 | 1043, 732 |
TELNET_SB_DET_DEFINE | 1 | |
TELNET_SB_DET_ERASE | 2 | |
TELNET_SB_DET_TRANSMIT | 3 | |
TELNET_SB_DET_FORMAT | 4 | |
TELNET_SB_DET_MOVE_CURSOR | 5 | |
TELNET_SB_DET_SKIP_TO_LINE | 6 | |
TELNET_SB_DET_SKIP_TO_CHAR | 7 | |
TELNET_SB_DET_UP | 8 | |
TELNET_SB_DET_DOWN | 9 | |
TELNET_SB_DET_LEFT | 10 | |
TELNET_SB_DET_RIGHT | 11 | |
TELNET_SB_DET_HOME | 12 | |
TELNET_SB_DET_LINE_INSERT | 13 | |
TELNET_SB_DET_LINE_DELETE | 14 | |
TELNET_SB_DET_CHAR_INSERT | 15 | |
TELNET_SB_DET_CHAR_DELETE | 16 | |
TELNET_SB_DET_READ_CURSOR | 17 | |
TELNET_SB_DET_CURSOR_POSITION | 18 | |
TELNET_SB_DET_REVERSE_TAB | 19 | |
TELNET_SB_DET_TRANSMIT_SCREEN | 20 | |
TELNET_SB_DET_TRANSMIT_UNPROTECTED | 21 | |
TELNET_SB_DET_TRANSMIT_LINE | 22 | |
TELNET_SB_DET_TRANSMIT_FIELD | 23 | |
TELNET_SB_DET_TRANSMIT_REST_SCREEN | 24 | |
TELNET_SB_DET_TRANSMIT_REST_LINE | 25 | |
TELNET_SB_DET_TRANSMIT_REST_FIELD | 26 | |
TELNET_SB_DET_TRANSMIT_MODIFIED | 27 | |
TELNET_SB_DET_DATA_TRANSMIT | 28 | |
TELNET_SB_DET_ERASE_SCREEN | 29 | |
TELNET_SB_DET_ERASE_LINE | 30 | |
TELNET_SB_DET_ERASE_FIELD | 31 | |
TELNET_SB_DET_ERASE_REST_SCREEN | 32 | |
TELNET_SB_DET_ERASE_REST_LINE | 33 | |
TELNET_SB_DET_ERASE_REST_FIELD | 34 | |
TELNET_SB_DET_ERASE_UNPROTECTED | 35 | |
TELNET_SB_DET_FORMAT_DATA | 36 | |
TELNET_SB_DET_REPEAT | 37 | |
TELNET_SB_DET_SUPPRESS_PROTECTION | 38 | |
TELNET_SB_DET_FIELD_SEPARATOR | 39 | |
TELNET_SB_DET_FN | 40 | |
TELNET_SB_DET_ERROR | 41 | |
TELNET_SUPDUP | 21 | 736, 734 |
TELNET_SUPDUP_OUTPUT | 22 | 749 |
TELNET_SEND_LOCATION | 23 | 779 |
TELNET_TERMINAL_TYPE | 24 | 1091 |
TELNET_SB_TERMINAL_TYPE_IS | 0 | |
TELNET_SB_TERMINAL_TYPE_SEND | 1 | |
TELNET_EOR | 25 | 885 |
TELNET_TUID | 26 | 927 |
TELNET_OUTMRK | 27 | 933 |
TELNET_TTYLOC | 28 946 | |
TELNET_3270_REGIME | 29 | 1041 |
TELNET_SB_3270_REGIME_IS | 0 | |
TELNET_SB_3270_REGIME_ARE | 1 | |
TELNET_X3_PAD | 30 | 1053 |
TELNET_SB_X3_PAD_SET | 0 | |
TELNET_SB_X3_PAD_RESPONSE_SET | 1 | |
TELNET_SB_X3_PAD_IS | 2 | |
TELNET_SB_X3_PAD_RESPONSE_IS | 3 | |
TELNET_SB_X3_PAD_SEND | 4 | |
TELNET_NAWS | 31 | 1073 |
TELNET_TERMINAL_SPEED | 32 | 1079 |
TELNET_SB_TERMINAL_SPEED_IS | 0 | |
TELNET_SB_TERMINAL_SPEED_SEND | 1 | |
TELNET_TOGGLE_FLOW_CONTROL | 33 | 1372 |
TELNET_SB_TOGGLE_FLOW_CONTROL_OFF | 0 | |
TELNET_SB_TOGGLE_FLOW_CONTROL_ON | 1 | |
TELNET_SB_TOGGLE_FLOW_CONTROL_RESTART_ANY | 2 | |
TELNET_SB_TOGGLE_FLOW_CONTROL_RESTART_XON | 3 | |
TELNET_LINEMODE | 34 | 1184 |
TELNET_SB_LINEMODE_MODE | 1 | |
TELNET_SB_LINEMODE_FORWARDMASK | 2 | |
TELNET_SB_LINEMODE_SLC | 3 | |
TELNET_X_DISPLAY_LOCATION | 35 | 1096 |
TELNET_SB_X_DISPLAY_LOCATION_IS | 0 | |
TELNET_SB_X_DISPLAY_LOCATION_SEND | 1 | |
TELNET_OLD_ENVIRONMENT | 36 | 1408 |
TELNET_SB_OLD_ENVIRONMENT_IS | 0 | |
TELNET_SB_OLD_ENVIRONMENT_SEND | 1 | |
TELNET_SB_OLD_ENVIRONMENT_INFO | 2 | |
TELNET_AUTHENTICATION | 37 | 2941 |
TELNET_SB_AUTHENTICATION_IS | 0 | |
TELNET_SB_AUTHENTICATION_SEND | 1 | |
TELNET_SB_AUTHENTICATION_REPLY | 2 | |
TELNET_SB_AUTHENTICATION_NAME | 3 | |
TELNET_ENCRYPT | 38 | 2946 |
TELNET_SB_ENCRYPT_IS | 0 | |
TELNET_SB_ENCRYPT_SUPPORT | 1 | |
TELNET_SB_ENCRYPT_REPLY | 2 | |
TELNET_SB_ENCRYPT_START | 3 | |
TELNET_SB_ENCRYPT_END | 4 | |
TELNET_SB_ENCRYPT_REQUEST_START | 5 | |
TELNET_SB_ENCRYPT_REQUEST_END | 6 | |
TELNET_SB_ENCRYPT_ENC_KEYID | 7 | |
TELNET_SB_ENCRYPT_DEC_KEYID | 8 | |
TELNET_ENVIRONMENT | 39 | 1572 |
TELNET_SB_ENVIRONMENT_IS | 0 | |
TELNET_SB_ENVIRONMENT_SEND | 1 | |
TELNET_SB_ENVIRONMENT_INFO | 2 | |
TELNET_TN3270E | 40 | 1647 |
TELNET_SB_TN3270E_ASSOCIATE | 0 | |
TELNET_SB_TN3270E_CONNECT | 1 | |
TELNET_SB_TN3270E_DEVICE_TYPE | 2 | |
TELNET_SB_TN3270E_FUNCTIONS | 3 | |
TELNET_SB_TN3270E_IS | 4 | |
TELNET_SB_TN3270E_REASON | 5 | |
TELNET_SB_TN3270E_REJECT | 6 | |
TELNET_SB_TN3270E_REQUEST | 7 | |
TELNET_SB_TN3270E_SEND | 8 | |
TELNET_CHARSET | 42 | 2066 |
TELNET_SB_CHARSET_REQUEST | 1 | |
TELNET_SB_CHARSET_ACCEPTED | 2 | |
TELNET_SB_CHARSET_REJECTED | 3 | |
TELNET_SB_CHARSET_TTABLE_IS | 4 | |
TELNET_SB_CHARSET_TTABLE_REJECTED | 5 | |
TELNET_SB_CHARSET_TTABLE_ACK | 6 | |
TELNET_SB_CHARSET_TTABLE_NAK | 7 | |
TELNET_COM_PORT | 44 | 2217 |
TELNET_SB_COM_PORT_CLI_SET_BAUDRATE | 1 | |
TELNET_SB_COM_PORT_CLI_SET_DATASIZE | 2 | |
TELNET_SB_COM_PORT_CLI_SET_PARITY | 3 | |
TELNET_SB_COM_PORT_CLI_SET_STOPSIZE | 4 | |
TELNET_SB_COM_PORT_CLI_SET_CONTROL | 5 | |
TELNET_SB_COM_PORT_CLI_NOTIFY_LINESTATE | 6 | |
TELNET_SB_COM_PORT_CLI_NOTIFY_MODEMSTATE | 7 | |
TELNET_SB_COM_PORT_CLI_FLOWCONTROL_SUSPEND | 8 | |
TELNET_SB_COM_PORT_CLI_FLOWCONTROL_RESUME | 9 | |
TELNET_SB_COM_PORT_CLI_SET_LINESTATE_MASK | 10 | |
TELNET_SB_COM_PORT_CLI_SET_MODEMSTATE_MASK | 11 | |
TELNET_SB_COM_PORT_CLI_PURGE_DATA | 12 | |
TELNET_SB_COM_PORT_SVR_SET_BAUDRATE | 101 | |
TELNET_SB_COM_PORT_SVR_SET_DATASIZE | 102 | |
TELNET_SB_COM_PORT_SVR_SET_PARITY | 103 | |
TELNET_SB_COM_PORT_SVR_SET_STOPSIZE | 104 | |
TELNET_SB_COM_PORT_SVR_SET_CONTROL | 105 | |
TELNET_SB_COM_PORT_SVR_NOTIFY_LINESTATE | 106 | |
TELNET_SB_COM_PORT_SVR_NOTIFY_MODEMSTATE | 107 | |
TELNET_SB_COM_PORT_SVR_FLOWCONTROL_SUSPEND | 108 | |
TELNET_SB_COM_PORT_SVR_FLOWCONTROL_RESUME | 109 | |
TELNET_SB_COM_PORT_SVR_SET_LINESTATE_MASK | 110 | |
TELNET_SB_COM_PORT_SVR_SET_MODEMSTATE_MASK | 111 | |
TELNET_SB_COM_PORT_SVR_PURGE_DATA | 112 | |
TELNET_KERMIT | 47 | 2840 |
TELNET_SB_KERMIT_START_SERVER | 0 | |
TELNET_SB_KERMIT_STOP_SERVER | 1 | |
TELNET_SB_KERMIT_REQ_START_SERVER | 2 | |
TELNET_SB_KERMIT_REQ_STOP_SERVER | 3 | |
TELNET_SB_KERMIT_SOP | 4 | |
TELNET_SB_KERMIT_RESP_START_SERVER | 8 | |
TELNET_SB_KERMIT_RESP_STOP_SERVER | 9 | |
TELNET_EXOPL | 255 | 861 |
TELNET_SUBLIMINAL_MSG | 257 | 1097 |
Table A.1. TELNET options and suboptions
The list of RADIUS attributes as defined by the RADIUS RFC with their symbolic names:
Name | Value |
---|---|
RADIUS_USER_name | "1" |
RADIUS_USER_PASSWORD | "2" |
RADIUS_CHAP_PASSWORD | "3" |
RADIUS_NAS_IP_ADDRESS | "4" |
RADIUS_NAS_PORT | "5" |
RADIUS_SERVICE_TYPE | "6" |
RADIUS_FRAMED_PROTOCOL | "7" |
RADIUS_FRAMED_IP_ADDRESS | "8" |
RADIUS_FRAMED_IP_NETMASK | "9" |
RADIUS_FRAMED_ROUTING | "10" |
RADIUS_FILTER_ID | "11" |
RADIUS_FRAMED_MTU | "12" |
RADIUS_FRAMED_COMPRESSION | "13" |
RADIUS_LOGIN_IP_HOST | "14" |
RADIUS_LOGIN_SERVICE | "15" |
RADIUS_LOGIN_TCP_PORT | "16" |
RADIUS_REPLY_MESSAGE | "18" |
RADIUS_CALLBACK_NUMBER | "19" |
RADIUS_CALLBACK_ID | "20" |
RADIUS_FRAMED_ROUTE | "22" |
RADIUS_FRAMED_IPX_NETWORK | "23" |
RADIUS_STATE | "24" |
RADIUS_CLASS | "25" |
RADIUS_VENDOR_SPECIFIC | "26" |
RADIUS_SESSION_TIMEOUT | "27" |
RADIUS_IDLE_TIMEOUT | "28" |
RADIUS_TERMINATION_ACTION | "29" |
RADIUS_CALLED_STATION_ID | "30" |
RADIUS_CALLING_STATION_ID | "31" |
RADIUS_NAS_IDENTIFIER | "32" |
RADIUS_PROXY_STATE | "33" |
RADIUS_LOGIN_LAT_SERVICE | "34" |
RADIUS_LOGIN_LAT_NODE | "35" |
RADIUS_LOGIN_LAT_GROUP | "36" |
RADIUS_FRAMED_APPLETALK_LINK | "37" |
RADIUS_FRAMED_APPLETALK_NETWORK | "38" |
RADIUS_FRAMED_APPLETALK_ZONE | "39" |
RADIUS_ACCT_STATUS_TYPE | "40" |
RADIUS_ACCT_DELAY_TIME | "41" |
RADIUS_ACCT_INPUT_OCTETS | "42" |
RADIUS_ACCT_OUTPUT_OCTETS | "43" |
RADIUS_ACCT_SESSION_ID | "44" |
RADIUS_ACCT_AUTHENTIC | "45" |
RADIUS_ACCT_SESSION_TIME | "46" |
RADIUS_ACCT_INPUT_PACKETS | "47" |
RADIUS_ACCT_OUTPUT_PACKETS | "48" |
RADIUS_ACCT_TERMINATE_CAUSE | "49" |
RADIUS_ACCT_MULTI_SESSION_ID | "50" |
RADIUS_ACCT_LINK_COUNT | "51" |
RADIUS_ACCT_INPUT_GIGAWORDS | "52" |
RADIUS_ACCT_OUTPUT_GIGAWORDS | "53" |
RADIUS_EVENT_TIMESTAMP | "55" |
RADIUS_CHAP_CHALLENGE | "60" |
RADIUS_NAS_PORT_TYPE | "61" |
RADIUS_PORT_LIMIT | "62" |
RADIUS_LOGIN_LAT_PORT | "63" |
RADIUS_TUNNEL_TYPE | "64" |
RADIUS_TUNNEL_MEDIUM_TYPE | "65" |
RADIUS_TUNNEL_CLIENT_ENDPOINT | "66" |
RADIUS_TUNNEL_SERVER_ENDPOINT | "67" |
RADIUS_ACCT_TUNNEL_CONNECTION | "68" |
RADIUS_TUNNEL_PASSWORD | "69" |
RADIUS_ARAP_PASSWORD | "70" |
RADIUS_ARAP_FEATURES | "71" |
RADIUS_ARAP_ZONE_ACCESS | "72" |
RADIUS_ARAP_SECURITY | "73" |
RADIUS_ARAP_SECURITY_DATA | "74" |
RADIUS_PASSWORD_RETRY | "75" |
RADIUS_PROMPT | "76" |
RADIUS_CONNECT_INFO | "77" |
RADIUS_CONFIGURATION_TOKEN | "78" |
RADIUS_EAP_MESSAGE | "79" |
RADIUS_MESSAGE_AUTHENTICATOR | "80" |
RADIUS_TUNNEL_PRIVATE_GROUP_ID | "81" |
RADIUS_TUNNEL_ASSIGNMENT_ID | "82" |
RADIUS_TUNNEL_PREFERENCE | "83" |
RADIUS_ARAP_CHALLENGE_RESPONSE | "84" |
RADIUS_ACCT_INTERIM_INTERVAL | "85" |
RADIUS_ACCT_TUNNEL_PACKETS_LOST | "86" |
RADIUS_NAS_PORT_ID | "87" |
RADIUS_FRAMED_POOL | "88" |
RADIUS_TUNNEL_CLIENT_AUTH_ID | "90" |
RADIUS_TUNNEL_SERVER_AUTH_ID | "91" |
Table A.2. RADIUS Protocol Attribute types described in RFC 2865.
Action | Attribute | Attribute policy |
---|---|---|
radius_access_request | radius_user_name | RADIUS_ATR_MAXONE |
radius_access_request | radius_user_password | RADIUS_ATR_MAXONE |
radius_access_request | radius_chap_password | RADIUS_ATR_MAXONE |
radius_access_request | radius_nas_ip_address | RADIUS_ATR_MAXONE |
radius_access_request | radius_nas_port | RADIUS_ATR_MAXONE |
radius_access_request | radius_service_type | RADIUS_ATR_MAXONE |
radius_access_request | radius_framed_protocol | RADIUS_ATR_MAXONE |
radius_access_request | radius_framed_ip_address | RADIUS_ATR_MAXONE |
radius_access_request | radius_framed_ip_netmask | RADIUS_ATR_MAXONE |
radius_access_request | radius_framed_routing | RADIUS_ATR_ZERO |
radius_access_request | radius_filter_id | RADIUS_ATR_ZERO |
radius_access_request | radius_framed_mtu | RADIUS_ATR_MAXONE |
radius_access_request | radius_framed_compression | RADIUS_ATR_MANY |
radius_access_request | radius_login_ip_host | RADIUS_ATR_MANY |
radius_access_request | radius_login_service | RADIUS_ATR_ZERO |
radius_access_request | radius_login_tcp_port | RADIUS_ATR_ZERO |
radius_access_request | radius_reply_message | RADIUS_ATR_ZERO |
radius_access_request | radius_callback_number | RADIUS_ATR_MAXONE |
radius_access_request | radius_callback_id | RADIUS_ATR_ZERO |
radius_access_request | radius_framed_route | RADIUS_ATR_ZERO |
radius_access_request | radius_framed_ipx_network | RADIUS_ATR_ZERO |
radius_access_request | radius_state | RADIUS_ATR_MAXONE |
radius_access_request | radius_class | RADIUS_ATR_ZERO |
radius_access_request | radius_vendor_specific | RADIUS_ATR_MANY |
radius_access_request | radius_session_timeout | RADIUS_ATR_ZERO |
radius_access_request | radius_idle_timeout | RADIUS_ATR_ZERO |
radius_access_request | radius_termination_action | RADIUS_ATR_ZERO |
radius_access_request | radius_called_station_id | RADIUS_ATR_MAXONE |
radius_access_request | radius_calling_station_id | RADIUS_ATR_MAXONE |
radius_access_request | radius_nas_identifier | RADIUS_ATR_MAXONE |
radius_access_request | radius_proxy_state | RADIUS_ATR_MANY |
radius_access_request | radius_login_lat_service | RADIUS_ATR_MAXONE |
radius_access_request | radius_login_lat_node | RADIUS_ATR_MAXONE |
radius_access_request | radius_login_lat_group | RADIUS_ATR_MAXONE |
radius_access_request | radius_framed_appletalk_link | RADIUS_ATR_ZERO |
radius_access_request | radius_framed_appletalk_network | RADIUS_ATR_ZERO |
radius_access_request | radius_framed_appletalk_zone | RADIUS_ATR_ZERO |
radius_access_request | radius_chap_challenge | RADIUS_ATR_MAXONE |
radius_access_request | radius_nas_port_type | RADIUS_ATR_MAXONE |
radius_access_request | radius_port_limit | RADIUS_ATR_MAXONE |
radius_access_request | radius_login_lat_port | RADIUS_ATR_MAXONE |
radius_access_request | radius_tunnel_type | RADIUS_ATR_MANY |
radius_access_request | radius_tunnel_medium_type | RADIUS_ATR_MANY |
radius_access_request | radius_tunnel_client_endpoint | RADIUS_ATR_MANY |
radius_access_request | radius_tunnel_server_endpoint | RADIUS_ATR_MANY |
radius_access_request | radius_tunnel_password | RADIUS_ATR_ZERO |
radius_access_request | radius_arap_password | RADIUS_ATR_MAXONE |
radius_access_request | radius_arap_features | RADIUS_ATR_ZERO |
radius_access_request | radius_arap_zone_access | RADIUS_ATR_ZERO |
radius_access_request | radius_arap_security | RADIUS_ATR_MAXONE |
radius_access_request | radius_arap_security_data | RADIUS_ATR_MANY |
radius_access_request | radius_password_retry | RADIUS_ATR_ZERO |
radius_access_request | radius_prompt | RADIUS_ATR_ZERO |
radius_access_request | radius_connect_info | RADIUS_ATR_MAXONE |
radius_access_request | radius_configuration_token | RADIUS_ATR_ZERO |
radius_access_request | radius_eap_message | RADIUS_ATR_MANY |
radius_access_request | radius_message_authenticator | RADIUS_ATR_MAXONE |
radius_access_request | radius_tunnel_private_group_id | RADIUS_ATR_MANY |
radius_access_request | radius_tunnel_assignment_id | RADIUS_ATR_ZERO |
radius_access_request | radius_tunnel_preference | RADIUS_ATR_MANY |
radius_access_request | radius_arap_challenge_response | RADIUS_ATR_ZERO |
radius_access_request | radius_acct_interim_interval | RADIUS_ATR_ZERO |
radius_access_request | radius_nas_port_id | RADIUS_ATR_MAXONE |
radius_access_request | radius_framed_pool | RADIUS_ATR_ZERO |
radius_access_request | radius_tunnel_client_auth_id | RADIUS_ATR_MANY |
radius_access_request | radius_tunnel_server_auth_id | RADIUS_ATR_MANY |
radius_access_accept | radius_user_name | RADIUS_ATR_MAXONE |
radius_access_accept | radius_user_password | RADIUS_ATR_ZERO |
radius_access_accept | radius_chap_password | RADIUS_ATR_ZERO |
radius_access_accept | radius_nas_ip_address | RADIUS_ATR_ZERO |
radius_access_accept | radius_nas_port | RADIUS_ATR_ZERO |
radius_access_accept | radius_service_type | RADIUS_ATR_MAXONE |
radius_access_accept | radius_framed_protocol | RADIUS_ATR_MAXONE |
radius_access_accept | radius_framed_ip_address | RADIUS_ATR_MAXONE |
radius_access_accept | radius_framed_ip_netmask | RADIUS_ATR_MAXONE |
radius_access_accept | radius_framed_routing | RADIUS_ATR_MAXONE |
radius_access_accept | radius_filter_id | RADIUS_ATR_MANY |
radius_access_accept | radius_framed_mtu | RADIUS_ATR_MAXONE |
radius_access_accept | radius_framed_compression | RADIUS_ATR_MANY |
radius_access_accept | radius_login_ip_host | RADIUS_ATR_MANY |
radius_access_accept | radius_login_service | RADIUS_ATR_MAXONE |
radius_access_accept | radius_login_tcp_port | RADIUS_ATR_MAXONE |
radius_access_accept | radius_reply_message | RADIUS_ATR_MANY |
radius_access_accept | radius_callback_number | RADIUS_ATR_MAXONE |
radius_access_accept | radius_callback_id | RADIUS_ATR_MAXONE |
radius_access_accept | radius_framed_route | RADIUS_ATR_MANY |
radius_access_accept | radius_framed_ipx_network | RADIUS_ATR_MAXONE |
radius_access_accept | radius_state | RADIUS_ATR_MAXONE |
radius_access_accept | radius_class | RADIUS_ATR_MANY |
radius_access_accept | radius_vendor_specific | RADIUS_ATR_MANY |
radius_access_accept | radius_session_timeout | RADIUS_ATR_MAXONE |
radius_access_accept | radius_idle_timeout | RADIUS_ATR_MAXONE |
radius_access_accept | radius_termination_action | RADIUS_ATR_MAXONE |
radius_access_accept | radius_called_station_id | RADIUS_ATR_ZERO |
radius_access_accept | radius_calling_station_id | RADIUS_ATR_ZERO |
radius_access_accept | radius_nas_identifier | RADIUS_ATR_ZERO |
radius_access_accept | radius_proxy_state | RADIUS_ATR_MANY |
radius_access_accept | radius_login_lat_service | RADIUS_ATR_MAXONE |
radius_access_accept | radius_login_lat_node | RADIUS_ATR_MAXONE |
radius_access_accept | radius_login_lat_group | RADIUS_ATR_MAXONE |
radius_access_accept | radius_framed_appletalk_link | RADIUS_ATR_MAXONE |
radius_access_accept | radius_framed_appletalk_network | RADIUS_ATR_MANY |
radius_access_accept | radius_framed_appletalk_zone | RADIUS_ATR_MAXONE |
radius_access_accept | radius_chap_challenge | RADIUS_ATR_ZERO |
radius_access_accept | radius_nas_port_type | RADIUS_ATR_ZERO |
radius_access_accept | radius_port_limit | RADIUS_ATR_MAXONE |
radius_access_accept | radius_login_lat_port | RADIUS_ATR_MAXONE |
radius_access_accept | radius_tunnel_type | RADIUS_ATR_MANY |
radius_access_accept | radius_tunnel_medium_type | RADIUS_ATR_MANY |
radius_access_accept | radius_tunnel_client_endpoint | RADIUS_ATR_MANY |
radius_access_accept | radius_tunnel_server_endpoint | RADIUS_ATR_MANY |
radius_access_accept | radius_tunnel_password | RADIUS_ATR_MANY |
radius_access_accept | radius_arap_password | RADIUS_ATR_ZERO |
radius_access_accept | radius_arap_features | RADIUS_ATR_MAXONE |
radius_access_accept | radius_arap_zone_access | RADIUS_ATR_MAXONE |
radius_access_accept | radius_arap_security | RADIUS_ATR_ZERO |
radius_access_accept | radius_arap_security_data | RADIUS_ATR_ZERO |
radius_access_accept | radius_password_retry | RADIUS_ATR_ZERO |
radius_access_accept | radius_prompt | RADIUS_ATR_ZERO |
radius_access_accept | radius_connect_info | RADIUS_ATR_ZERO |
radius_access_accept | radius_configuration_token | RADIUS_ATR_MANY |
radius_access_accept | radius_eap_message | RADIUS_ATR_MANY |
radius_access_accept | radius_message_authenticator | RADIUS_ATR_MAXONE |
radius_access_accept | radius_tunnel_private_group_id | RADIUS_ATR_MANY |
radius_access_accept | radius_tunnel_assignment_id | RADIUS_ATR_MANY |
radius_access_accept | radius_tunnel_preference | RADIUS_ATR_MANY |
radius_access_accept | radius_arap_challenge_response | RADIUS_ATR_MAXONE |
radius_access_accept | radius_acct_interim_interval | RADIUS_ATR_MAXONE |
radius_access_accept | radius_nas_port_id | RADIUS_ATR_ZERO |
radius_access_accept | radius_framed_pool | RADIUS_ATR_MAXONE |
radius_access_accept | radius_tunnel_client_auth_id | RADIUS_ATR_MANY |
radius_access_accept | radius_tunnel_server_auth_id | RADIUS_ATR_MANY |
radius_access_reject | radius_user_name | RADIUS_ATR_ZERO |
radius_access_reject | radius_user_password | RADIUS_ATR_ZERO |
radius_access_reject | radius_chap_password | RADIUS_ATR_ZERO |
radius_access_reject | radius_nas_ip_address | RADIUS_ATR_ZERO |
radius_access_reject | radius_nas_port | RADIUS_ATR_ZERO |
radius_access_reject | radius_service_type | RADIUS_ATR_ZERO |
radius_access_reject | radius_framed_protocol | RADIUS_ATR_ZERO |
radius_access_reject | radius_framed_ip_address | RADIUS_ATR_ZERO |
radius_access_reject | radius_framed_ip_netmask | RADIUS_ATR_ZERO |
radius_access_reject | radius_framed_routing | RADIUS_ATR_ZERO |
radius_access_reject | radius_filter_id | RADIUS_ATR_ZERO |
radius_access_reject | radius_framed_mtu | RADIUS_ATR_ZERO |
radius_access_reject | radius_framed_compression | RADIUS_ATR_ZERO |
radius_access_reject | radius_login_ip_host | RADIUS_ATR_ZERO |
radius_access_reject | radius_login_service | RADIUS_ATR_ZERO |
radius_access_reject | radius_login_tcp_port | RADIUS_ATR_ZERO |
radius_access_reject | radius_reply_message | RADIUS_ATR_MANY |
radius_access_reject | radius_callback_number | RADIUS_ATR_ZERO |
radius_access_reject | radius_callback_id | RADIUS_ATR_ZERO |
radius_access_reject | radius_framed_route | RADIUS_ATR_ZERO |
radius_access_reject | radius_framed_ipx_network | RADIUS_ATR_ZERO |
radius_access_reject | radius_state | RADIUS_ATR_ZERO |
radius_access_reject | radius_class | RADIUS_ATR_ZERO |
radius_access_reject | radius_vendor_specific | RADIUS_ATR_ZERO |
radius_access_reject | radius_session_timeout | RADIUS_ATR_ZERO |
radius_access_reject | radius_idle_timeout | RADIUS_ATR_ZERO |
radius_access_reject | radius_termination_action | RADIUS_ATR_ZERO |
radius_access_reject | radius_called_station_id | RADIUS_ATR_ZERO |
radius_access_reject | radius_calling_station_id | RADIUS_ATR_ZERO |
radius_access_reject | radius_nas_identifier | RADIUS_ATR_ZERO |
radius_access_reject | radius_proxy_state | RADIUS_ATR_MANY |
radius_access_reject | radius_login_lat_service | RADIUS_ATR_ZERO |
radius_access_reject | radius_login_lat_node | RADIUS_ATR_ZERO |
radius_access_reject | radius_login_lat_group | RADIUS_ATR_ZERO |
radius_access_reject | radius_framed_appletalk_link | RADIUS_ATR_ZERO |
radius_access_reject | radius_framed_appletalk_network | RADIUS_ATR_ZERO |
radius_access_reject | radius_framed_appletalk_zone | RADIUS_ATR_ZERO |
radius_access_reject | radius_chap_challenge | RADIUS_ATR_ZERO |
radius_access_reject | radius_nas_port_type | RADIUS_ATR_ZERO |
radius_access_reject | radius_port_limit | RADIUS_ATR_ZERO |
radius_access_reject | radius_login_lat_port | RADIUS_ATR_ZERO |
radius_access_reject | radius_tunnel_type | RADIUS_ATR_ZERO |
radius_access_reject | radius_tunnel_medium_type | RADIUS_ATR_ZERO |
radius_access_reject | radius_tunnel_client_endpoint | RADIUS_ATR_ZERO |
radius_access_reject | radius_tunnel_server_endpoint | RADIUS_ATR_ZERO |
radius_access_reject | radius_tunnel_password | RADIUS_ATR_ZERO |
radius_access_reject | radius_arap_password | RADIUS_ATR_ZERO |
radius_access_reject | radius_arap_features | RADIUS_ATR_ZERO |
radius_access_reject | radius_arap_zone_access | RADIUS_ATR_ZERO |
radius_access_reject | radius_arap_security | RADIUS_ATR_ZERO |
radius_access_reject | radius_arap_security_data | RADIUS_ATR_ZERO |
radius_access_reject | radius_password_retry | RADIUS_ATR_MAXONE |
radius_access_reject | radius_prompt | RADIUS_ATR_ZERO |
radius_access_reject | radius_connect_info | RADIUS_ATR_ZERO |
radius_access_reject | radius_configuration_token | RADIUS_ATR_ZERO |
radius_access_reject | radius_eap_message | RADIUS_ATR_MANY |
radius_access_reject | radius_message_authenticator | RADIUS_ATR_MAXONE |
radius_access_reject | radius_tunnel_private_group_id | RADIUS_ATR_ZERO |
radius_access_reject | radius_tunnel_assignment_id | RADIUS_ATR_ZERO |
radius_access_reject | radius_tunnel_preference | RADIUS_ATR_ZERO |
radius_access_reject | radius_arap_challenge_response | RADIUS_ATR_ZERO |
radius_access_reject | radius_acct_interim_interval | RADIUS_ATR_ZERO |
radius_access_reject | radius_nas_port_id | RADIUS_ATR_ZERO |
radius_access_reject | radius_framed_pool | RADIUS_ATR_ZERO |
radius_access_reject | radius_tunnel_client_auth_id | RADIUS_ATR_ZERO |
radius_access_reject | radius_tunnel_server_auth_id | RADIUS_ATR_ZERO |
radius_accounting_request | radius_user_name | RADIUS_ATR_MAXONE |
radius_accounting_request | radius_user_password | RADIUS_ATR_ZERO |
radius_accounting_request | radius_chap_password | RADIUS_ATR_ZERO |
radius_accounting_request | radius_nas_ip_address | RADIUS_ATR_MAXONE |
radius_accounting_request | radius_nas_port | RADIUS_ATR_MAXONE |
radius_accounting_request | radius_service_type | RADIUS_ATR_MAXONE |
radius_accounting_request | radius_framed_protocol | RADIUS_ATR_MAXONE |
radius_accounting_request | radius_framed_ip_address | RADIUS_ATR_MAXONE |
radius_accounting_request | radius_framed_ip_netmask | RADIUS_ATR_MAXONE |
radius_accounting_request | radius_framed_routing | RADIUS_ATR_MAXONE |
radius_accounting_request | radius_filter_id | RADIUS_ATR_MANY |
radius_accounting_request | radius_framed_mtu | RADIUS_ATR_MAXONE |
radius_accounting_request | radius_framed_compression | RADIUS_ATR_MANY |
radius_accounting_request | radius_login_ip_host | RADIUS_ATR_MANY |
radius_accounting_request | radius_login_service | RADIUS_ATR_MAXONE |
radius_accounting_request | radius_login_tcp_port | RADIUS_ATR_MAXONE |
radius_accounting_request | radius_reply_message | RADIUS_ATR_ZERO |
radius_accounting_request | radius_callback_number | RADIUS_ATR_MAXONE |
radius_accounting_request | radius_callback_id | RADIUS_ATR_MAXONE |
radius_accounting_request | radius_framed_route | RADIUS_ATR_MANY |
radius_accounting_request | radius_framed_ipx_network | RADIUS_ATR_MAXONE |
radius_accounting_request | radius_state | RADIUS_ATR_ZERO |
radius_accounting_request | radius_class | RADIUS_ATR_MANY |
radius_accounting_request | radius_vendor_specific | RADIUS_ATR_MANY |
radius_accounting_request | radius_session_timeout | RADIUS_ATR_MAXONE |
radius_accounting_request | radius_idle_timeout | RADIUS_ATR_MAXONE |
radius_accounting_request | radius_termination_action | RADIUS_ATR_MAXONE |
radius_accounting_request | radius_called_station_id | RADIUS_ATR_MAXONE |
radius_accounting_request | radius_calling_station_id | RADIUS_ATR_MAXONE |
radius_accounting_request | radius_nas_identifier | RADIUS_ATR_MAXONE |
radius_accounting_request | radius_proxy_state | RADIUS_ATR_MANY |
radius_accounting_request | radius_login_lat_service | RADIUS_ATR_MAXONE |
radius_accounting_request | radius_login_lat_node | RADIUS_ATR_MAXONE |
radius_accounting_request | radius_login_lat_group | RADIUS_ATR_MAXONE |
radius_accounting_request | radius_framed_appletalk_link | RADIUS_ATR_MAXONE |
radius_accounting_request | radius_framed_appletalk_network | RADIUS_ATR_MAXONE |
radius_accounting_request | radius_framed_appletalk_zone | RADIUS_ATR_MAXONE |
radius_accounting_request | radius_acct_status_type | RADIUS_ATR_ONE |
radius_accounting_request | radius_acct_delay_time | RADIUS_ATR_MAXONE |
radius_accounting_request | radius_acct_input_octets | RADIUS_ATR_MAXONE |
radius_accounting_request | radius_acct_output_octets | RADIUS_ATR_MAXONE |
radius_accounting_request | radius_acct_session_id | RADIUS_ATR_ONE |
radius_accounting_request | radius_acct_authentic | RADIUS_ATR_MAXONE |
radius_accounting_request | radius_acct_session_time | RADIUS_ATR_MAXONE |
radius_accounting_request | radius_acct_input_packets | RADIUS_ATR_MAXONE |
radius_accounting_request | radius_acct_output_packets | RADIUS_ATR_MAXONE |
radius_accounting_request | radius_acct_terminate_cause | RADIUS_ATR_MAXONE |
radius_accounting_request | radius_acct_multi_session_id | RADIUS_ATR_MANY |
radius_accounting_request | radius_acct_link_count | RADIUS_ATR_MANY |
radius_accounting_request | radius_acct_input_gigawords | RADIUS_ATR_MAXONE |
radius_accounting_request | radius_acct_output_gigawords | RADIUS_ATR_MAXONE |
radius_accounting_request | radius_event_timestamp | RADIUS_ATR_MAXONE |
radius_accounting_request | radius_chap_challenge | RADIUS_ATR_ZERO |
radius_accounting_request | radius_nas_port_type | RADIUS_ATR_MAXONE |
radius_accounting_request | radius_port_limit | RADIUS_ATR_MAXONE |
radius_accounting_request | radius_login_lat_port | RADIUS_ATR_MAXONE |
radius_accounting_request | radius_tunnel_type | RADIUS_ATR_MAXONE |
radius_accounting_request | radius_tunnel_medium_type | RADIUS_ATR_MAXONE |
radius_accounting_request | radius_tunnel_client_endpoint | RADIUS_ATR_MAXONE |
radius_accounting_request | radius_tunnel_server_endpoint | RADIUS_ATR_MAXONE |
radius_accounting_request | radius_acct_tunnel_connection | RADIUS_ATR_MAXONE |
radius_accounting_request | radius_tunnel_password | RADIUS_ATR_ZERO |
radius_accounting_request | radius_arap_password | RADIUS_ATR_ZERO |
radius_accounting_request | radius_arap_features | RADIUS_ATR_ZERO |
radius_accounting_request | radius_arap_zone_access | RADIUS_ATR_ZERO |
radius_accounting_request | radius_arap_security | RADIUS_ATR_ZERO |
radius_accounting_request | radius_arap_security_data | RADIUS_ATR_ZERO |
radius_accounting_request | radius_password_retry | RADIUS_ATR_ZERO |
radius_accounting_request | radius_prompt | RADIUS_ATR_ZERO |
radius_accounting_request | radius_connect_info | RADIUS_ATR_MANY |
radius_accounting_request | radius_configuration_token | RADIUS_ATR_ZERO |
radius_accounting_request | radius_eap_message | RADIUS_ATR_ZERO |
radius_accounting_request | radius_message_authenticator | RADIUS_ATR_ZERO |
radius_accounting_request | radius_tunnel_private_group_id | RADIUS_ATR_MAXONE |
radius_accounting_request | radius_tunnel_assignment_id | RADIUS_ATR_MAXONE |
radius_accounting_request | radius_tunnel_preference | RADIUS_ATR_ZERO |
radius_accounting_request | radius_arap_challenge_response | RADIUS_ATR_ZERO |
radius_accounting_request | radius_acct_interim_interval | RADIUS_ATR_ZERO |
radius_accounting_request | radius_acct_tunnel_packets_lost | RADIUS_ATR_MAXONE |
radius_accounting_request | radius_nas_port_id | RADIUS_ATR_MAXONE |
radius_accounting_request | radius_framed_pool | RADIUS_ATR_ZERO |
radius_accounting_request | radius_tunnel_client_auth_id | RADIUS_ATR_MAXONE |
radius_accounting_request | radius_tunnel_server_auth_id | RADIUS_ATR_MAXONE |
radius_accounting_response | radius_user_name | RADIUS_ATR_ZERO |
radius_accounting_response | radius_user_password | RADIUS_ATR_ZERO |
radius_accounting_response | radius_chap_password | RADIUS_ATR_ZERO |
radius_accounting_response | radius_nas_ip_address | RADIUS_ATR_ZERO |
radius_accounting_response | radius_nas_port | RADIUS_ATR_ZERO |
radius_accounting_response | radius_service_type | RADIUS_ATR_ZERO |
radius_accounting_response | radius_framed_protocol | RADIUS_ATR_ZERO |
radius_accounting_response | radius_framed_ip_address | RADIUS_ATR_ZERO |
radius_accounting_response | radius_framed_ip_netmask | RADIUS_ATR_ZERO |
radius_accounting_response | radius_framed_routing | RADIUS_ATR_ZERO |
radius_accounting_response | radius_filter_id | RADIUS_ATR_ZERO |
radius_accounting_response | radius_framed_mtu | RADIUS_ATR_ZERO |
radius_accounting_response | radius_framed_compression | RADIUS_ATR_ZERO |
radius_accounting_response | radius_login_ip_host | RADIUS_ATR_ZERO |
radius_accounting_response | radius_login_service | RADIUS_ATR_ZERO |
radius_accounting_response | radius_login_tcp_port | RADIUS_ATR_ZERO |
radius_accounting_response | radius_reply_message | RADIUS_ATR_ZERO |
radius_accounting_response | radius_callback_number | RADIUS_ATR_ZERO |
radius_accounting_response | radius_callback_id | RADIUS_ATR_ZERO |
radius_accounting_response | radius_framed_route | RADIUS_ATR_ZERO |
radius_accounting_response | radius_framed_ipx_network | RADIUS_ATR_ZERO |
radius_accounting_response | radius_state | RADIUS_ATR_ZERO |
radius_accounting_response | radius_class | RADIUS_ATR_ZERO |
radius_accounting_response | radius_vendor_specific | RADIUS_ATR_MANY |
radius_accounting_response | radius_session_timeout | RADIUS_ATR_ZERO |
radius_accounting_response | radius_idle_timeout | RADIUS_ATR_ZERO |
radius_accounting_response | radius_termination_action | RADIUS_ATR_ZERO |
radius_accounting_response | radius_called_station_id | RADIUS_ATR_ZERO |
radius_accounting_response | radius_calling_station_id | RADIUS_ATR_ZERO |
radius_accounting_response | radius_nas_identifier | RADIUS_ATR_ZERO |
radius_accounting_response | radius_proxy_state | RADIUS_ATR_MANY |
radius_accounting_response | radius_login_lat_service | RADIUS_ATR_ZERO |
radius_accounting_response | radius_login_lat_node | RADIUS_ATR_ZERO |
radius_accounting_response | radius_login_lat_group | RADIUS_ATR_ZERO |
radius_accounting_response | radius_framed_appletalk_link | RADIUS_ATR_ZERO |
radius_accounting_response | radius_framed_appletalk_network | RADIUS_ATR_ZERO |
radius_accounting_response | radius_framed_appletalk_zone | RADIUS_ATR_ZERO |
radius_accounting_response | radius_acct_status_type | RADIUS_ATR_ZERO |
radius_accounting_response | radius_acct_delay_time | RADIUS_ATR_ZERO |
radius_accounting_response | radius_acct_input_octets | RADIUS_ATR_ZERO |
radius_accounting_response | radius_acct_output_octets | RADIUS_ATR_ZERO |
radius_accounting_response | radius_acct_session_id | RADIUS_ATR_ZERO |
radius_accounting_response | radius_acct_authentic | RADIUS_ATR_ZERO |
radius_accounting_response | radius_acct_session_time | RADIUS_ATR_ZERO |
radius_accounting_response | radius_acct_input_packets | RADIUS_ATR_ZERO |
radius_accounting_response | radius_acct_output_packets | RADIUS_ATR_ZERO |
radius_accounting_response | radius_acct_terminate_cause | RADIUS_ATR_ZERO |
radius_accounting_response | radius_acct_multi_session_id | RADIUS_ATR_ZERO |
radius_accounting_response | radius_acct_link_count | RADIUS_ATR_ZERO |
radius_accounting_response | radius_chap_challenge | RADIUS_ATR_ZERO |
radius_accounting_response | radius_nas_port_type | RADIUS_ATR_ZERO |
radius_accounting_response | radius_port_limit | RADIUS_ATR_ZERO |
radius_accounting_response | radius_login_lat_port | RADIUS_ATR_ZERO |
radius_accounting_response | radius_tunnel_type | RADIUS_ATR_ZERO |
radius_accounting_response | radius_tunnel_medium_type | RADIUS_ATR_ZERO |
radius_accounting_response | radius_tunnel_client_endpoint | RADIUS_ATR_ZERO |
radius_accounting_response | radius_tunnel_server_endpoint | RADIUS_ATR_ZERO |
radius_accounting_response | radius_acct_tunnel_connection | RADIUS_ATR_ZERO |
radius_accounting_response | radius_tunnel_password | RADIUS_ATR_ZERO |
radius_accounting_response | radius_tunnel_private_group_id | RADIUS_ATR_ZERO |
radius_accounting_response | radius_tunnel_assignment_id | RADIUS_ATR_ZERO |
radius_accounting_response | radius_tunnel_preference | RADIUS_ATR_ZERO |
radius_accounting_response | radius_acct_tunnel_packets_lost | RADIUS_ATR_ZERO |
radius_access_challenge | radius_user_name | RADIUS_ATR_ZERO |
radius_access_challenge | radius_user_password | RADIUS_ATR_ZERO |
radius_access_challenge | radius_chap_password | RADIUS_ATR_ZERO |
radius_access_challenge | radius_nas_ip_address | RADIUS_ATR_ZERO |
radius_access_challenge | radius_nas_port | RADIUS_ATR_ZERO |
radius_access_challenge | radius_service_type | RADIUS_ATR_ZERO |
radius_access_challenge | radius_framed_protocol | RADIUS_ATR_ZERO |
radius_access_challenge | radius_framed_ip_address | RADIUS_ATR_ZERO |
radius_access_challenge | radius_framed_ip_netmask | RADIUS_ATR_ZERO |
radius_access_challenge | radius_framed_routing | RADIUS_ATR_ZERO |
radius_access_challenge | radius_filter_id | RADIUS_ATR_ZERO |
radius_access_challenge | radius_framed_mtu | RADIUS_ATR_ZERO |
radius_access_challenge | radius_framed_compression | RADIUS_ATR_ZERO |
radius_access_challenge | radius_login_ip_host | RADIUS_ATR_ZERO |
radius_access_challenge | radius_login_service | RADIUS_ATR_ZERO |
radius_access_challenge | radius_login_tcp_port | RADIUS_ATR_ZERO |
radius_access_challenge | radius_reply_message | RADIUS_ATR_MANY |
radius_access_challenge | radius_callback_number | RADIUS_ATR_ZERO |
radius_access_challenge | radius_callback_id | RADIUS_ATR_ZERO |
radius_access_challenge | radius_framed_route | RADIUS_ATR_ZERO |
radius_access_challenge | radius_framed_ipx_network | RADIUS_ATR_ZERO |
radius_access_challenge | radius_state | RADIUS_ATR_MAXONE |
radius_access_challenge | radius_class | RADIUS_ATR_ZERO |
radius_access_challenge | radius_vendor_specific | RADIUS_ATR_MANY |
radius_access_challenge | radius_session_timeout | RADIUS_ATR_MAXONE |
radius_access_challenge | radius_idle_timeout | RADIUS_ATR_MAXONE |
radius_access_challenge | radius_termination_action | RADIUS_ATR_ZERO |
radius_access_challenge | radius_called_station_id | RADIUS_ATR_ZERO |
radius_access_challenge | radius_calling_station_id | RADIUS_ATR_ZERO |
radius_access_challenge | radius_nas_identifier | RADIUS_ATR_ZERO |
radius_access_challenge | radius_proxy_state | RADIUS_ATR_MANY |
radius_access_challenge | radius_login_lat_service | RADIUS_ATR_ZERO |
radius_access_challenge | radius_login_lat_node | RADIUS_ATR_ZERO |
radius_access_challenge | radius_login_lat_group | RADIUS_ATR_ZERO |
radius_access_challenge | radius_framed_appletalk_link | RADIUS_ATR_ZERO |
radius_access_challenge | radius_framed_appletalk_network | RADIUS_ATR_ZERO |
radius_access_challenge | radius_framed_appletalk_zone | RADIUS_ATR_ZERO |
radius_access_challenge | radius_chap_challenge | RADIUS_ATR_ZERO |
radius_access_challenge | radius_nas_port_type | RADIUS_ATR_ZERO |
radius_access_challenge | radius_port_limit | RADIUS_ATR_ZERO |
radius_access_challenge | radius_login_lat_port | RADIUS_ATR_ZERO |
radius_access_challenge | radius_tunnel_type | RADIUS_ATR_ZERO |
radius_access_challenge | radius_tunnel_medium_type | RADIUS_ATR_ZERO |
radius_access_challenge | radius_tunnel_client_endpoint | RADIUS_ATR_ZERO |
radius_access_challenge | radius_tunnel_server_endpoint | RADIUS_ATR_ZERO |
radius_access_challenge | radius_tunnel_password | RADIUS_ATR_ZERO |
radius_access_challenge | radius_arap_password | RADIUS_ATR_ZERO |
radius_access_challenge | radius_arap_features | RADIUS_ATR_MAXONE |
radius_access_challenge | radius_arap_zone_access | RADIUS_ATR_ZERO |
radius_access_challenge | radius_arap_security | RADIUS_ATR_MAXONE |
radius_access_challenge | radius_arap_security_data | RADIUS_ATR_MANY |
radius_access_challenge | radius_password_retry | RADIUS_ATR_ZERO |
radius_access_challenge | radius_prompt | RADIUS_ATR_MAXONE |
radius_access_challenge | radius_connect_info | RADIUS_ATR_ZERO |
radius_access_challenge | radius_configuration_token | RADIUS_ATR_ZERO |
radius_access_challenge | radius_eap_message | RADIUS_ATR_MANY |
radius_access_challenge | radius_message_authenticator | RADIUS_ATR_MAXONE |
radius_access_challenge | radius_tunnel_private_group_id | RADIUS_ATR_ZERO |
radius_access_challenge | radius_tunnel_assignment_id | RADIUS_ATR_ZERO |
radius_access_challenge | radius_tunnel_preference | RADIUS_ATR_ZERO |
radius_access_challenge | radius_arap_challenge_response | RADIUS_ATR_MAXONE |
radius_access_challenge | radius_acct_interim_interval | RADIUS_ATR_ZERO |
radius_access_challenge | radius_nas_port_id | RADIUS_ATR_ZERO |
radius_access_challenge | radius_framed_pool | RADIUS_ATR_ZERO |
radius_access_challenge | radius_tunnel_client_auth_id | RADIUS_ATR_ZERO |
radius_access_challenge | radius_tunnel_server_auth_id | RADIUS_ATR_ZERO |
Table A.3. Default attribute policy in RadiusProxyStrict
Example A.1. An example for the SQL*Net connection string |
---|
No. Time Source Destination Protocol Info 344 48.463276 127.0.0.1 127.0.0.1 TNS Request, Connect (1), Connect Frame 344 (269 bytes on wire, 269 bytes captured) Arrival Time: Dec 20, 2005 11:10:58.166023000 Time delta from previous packet: 0.001255000 seconds Time since reference or first frame: 48.463276000 seconds Frame Number: 344 Packet Length: 269 bytes Capture Length: 269 bytes Protocols in frame: eth:ip:tcp:tns Ethernet II, Src: 00:00:00:00:00:00, Dst: 00:00:00:00:00:00 Destination: 00:00:00:00:00:00 (00:00:00_00:00:00) Source: 00:00:00:00:00:00 (00:00:00_00:00:00) Type: IP (0x0800) Internet Protocol, Src Addr: 127.0.0.1 (127.0.0.1), Dst Addr: 127.0.0.1 (127.0.0.1) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..0. = ECN-Capable Transport (ECT): 0 .... ...0 = ECN-CE: 0 Total Length: 255 Identification: 0x86bc (34492) Flags: 0x04 (Don't Fragment) 0... = Reserved bit: Not set .1.. = Don't fragment: Set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 64 Protocol: TCP (0x06) Header checksum: 0xb53a (correct) Source: 127.0.0.1 (127.0.0.1) Destination: 127.0.0.1 (127.0.0.1) Transmission Control Protocol, Src Port: 44404 (44404), Dst Port: 1521 (1521), Seq: 1, Ack: 1, Len: 203 Source port: 44404 (44404) Destination port: 1521 (1521) Sequence number: 1 (relative sequence number) Next sequence number: 204 (relative sequence number) Acknowledgement number: 1 (relative ack number) Header length: 32 bytes Flags: 0x0018 (PSH, ACK) 0... .... = Congestion Window Reduced (CWR): Not set .0.. .... = ECN-Echo: Not set ..0. .... = Urgent: Not set ...1 .... = Acknowledgment: Set .... 1... = Push: Set .... .0.. = Reset: Not set .... ..0. = Syn: Not set .... ...0 = Fin: Not set Window size: 32767 Checksum: 0xfef3 (incorrect, should be 0x5c50) Options: (12 bytes) NOP NOP Time stamp: tsval 35686106, tsecr 35686106 Transparent Network Substrate Protocol Packet Length: 203 Packet Checksum: 0x0000 Packet Type: Connect (1) Reserved Byte: 00 Header Checksum: 0x0000 Connect Version: 312 Version (Compatible): 300 Service Options: 0x0c01 ..0. .... .... .... = Broken Connect Notify: False ...0 .... .... .... = Packet Checksum: False .... 1... .... .... = Header Checksum: True .... .1.. .... .... = Full Duplex: True .... ..0. .... .... = Half Duplex: False .... ...0 .... .... = Don't Care: False .... .... 0... .... = Don't Care: False .... .... ...0 .... = Direct IO to Transport: False .... .... .... 0... = Attention Processing: False .... .... .... .0.. = Can Receive Attention: False .... .... .... ..0. = Can Send Attention: False Session Data Unit Size: 2048 Maximum Transmission Data Unit Size: 32767 NT Protocol Characteristics: 0x7f08 0... .... .... .... = Hangon to listener connect: False .1.. .... .... .... = Confirmed release: True ..1. .... .... .... = TDU based IO: True ...1 .... .... .... = Spawner running: True .... 1... .... .... = Data test: True .... .1.. .... .... = Callback IO supported: True .... ..1. .... .... = ASync IO Supported: True .... ...1 .... .... = Packet oriented IO: True .... .... 0... .... = Can grant connection to another: False .... .... .0.. .... = Can handoff connection to another: False .... .... ..0. .... = Generate SIGIO signal: False .... .... ...0 .... = Generate SIGPIPE signal: False .... .... .... 1... = Generate SIGURG signal: True .... .... .... .0.. = Urgent IO supported: False .... .... .... ..0. = Full duplex IO supported: False .... .... .... ...0 = Test operation: False Line Turnaround Value: 0 Value of 1 in Hardware: 0100 Length of Connect Data: 145 Offset to Connect Data: 58 Maximum Receivable Connect Data: 512 Connect Flags 0: 0x41 ...0 .... = NA services required: False .... 0... = NA services linked in: False .... .0.. = NA services enabled: False .... ..0. = Interchange is involved: False .... ...1 = NA services wanted: True Connect Flags 1: 0x41 ...0 .... = NA services required: False .... 0... = NA services linked in: False .... .0.. = NA services enabled: False .... ..0. = Interchange is involved: False .... ...1 = NA services wanted: True Trace Cross Facility Item 1: 0x00000000 Trace Cross Facility Item 2: 0x00000000 Trace Unique Connection ID: 0x0000660c007e4a09 Connect Data: (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=127.0.0.1)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=OPT.BALASYS)(CID=(PROGRAM=)(HOST=crm)(USER=oracle)))) |
PNS has a number of global options and variables that are used during the initialization of the engine, before any proxies or services are started. These options control the swapping of large data chunks (blobs) to disk, the handling of audit trails, and other miscellaneous parameters. To set these options, complete the following steps:
Select the PNS MC component, then select Variables > New.
Enter the name of the global option into the Name field, and select the type of the option in the Type field.
Select OK, then Edit.
Enter the desired value of the option, then select OK.
Note |
---|
Global options can be also set at the beginning of the |
blob
These options control the handling of large data chunks (blobs), determine when they are swapped to disk, and also how much disk space and memory can be used by PNS.
The directory where the blobs are swapped to. Default value:
/var/lib/vela/tmp/
PNS tries to store everything in the memory if possible. If the memory usage of PNS reaches hiwat, it starts to swap the data onto the hard disk, until the memory usage reaches lowat.
Global options can be also set at the beginning of the
Config.py
file if managing the configuration of PNS manually.
Lower threshold of data swapping.
The maximum amount of hard disk space that PNS is allowed to use.
The maximum amount of memory that PNS is allowed to use.
Objects smaller than this value (in bytes) are never swapped to hard
disk. Default value: 16384
audit
Enable the compression of audit trail files. The level of compression
can be set via the config.audit.compress_level
parameter. Default value: TRUE
The level of compression ranging from 1 (lowest, default) to 9
(highest). Please note that higher compression levels use significantly
more CPU, therefore it is usually not recommended to set it to higher
than 4. Default value: 1
Encrypt the audit trail files using the key provided in the
config.audit.encrypt_certificate
parameter.
Default value: FALSE
The X.509 PEM certificate used to encrypt the audit trail files. Default value: empty.
The certificate should be placed in the following format:
-----BEGIN CERTIFICATE----- insert key here -----END CERTIFICATE-----
Name and path of the file containing the X.509 PEM certificate used to
encrypt the audit trail files. If this parameter is set, it overrides
the settings of config.audit.encrypt_certificate
.
Default value: empty.
The maximum size of a single audit trail file in bytes. Default value:
2000000000L
(2 GB)
Store each session in its own audit file. Default value:
FALSE
The maximum time frame of a single audit file in seconds. Default
value: 28800
(8 hours)
PNS considers it abnormal if the size of an audit trail is increasing
faster than this value in byte/second. Default value:
2097152
(2 MB)
Time in seconds before repeating the notification about abnormally
growing audit trails. Default value: 300
(5
minutes)
Maximum size of an audit trail file in bytes. Default value:
52428800
(50 MB)
If set to TRUE
, PNS terminates the connection
if the corresponding audit trail file reaches the size limit set in
config.audit.write_size_max
. Default value:
FALSE
options
Priority mapping for transferring Differentiated Services Code Point
(DSCP, also known as Type of Service or ToS). The low
(0
), normal (1
), high
(2
), and urgent (3
)
priorities can be assigned to the DSCP classes. The assigned priority
determines the priority of the PNS thread that handles the connection.
The mapping is actually a hash table consisting of the DSCP class ID, a
colon (:
), the priority of the class
(0-3
), and a comma (,
)
except for the last row. For example:
config.options.dscp_mapping = { 1: 3, 2: 2, 3: 2, 4: 0 }
The default language used to display user-visible messages, e.g., HTTP
error pages. Default value: en
(English). Other
supported languages: de
(German);
hu
(Hungarian).
The timeout (in milliseconds) used when establishing server-side
connections. Default value: 30000
(30 sec)
PNS caches certain data (e.g., to which zone a particular IP address belongs to)
to decrease the time required to process a connection. The following parameters
determine the size of these caches (the number of decisions stored in the cache).
Adjusting these parameters is required only in environments having very complex zone
structure and a large number of services. The following log message indicates that a
cache is full: Cache over shift-threshold, shifting
Stores IP addresses and the zone they belong to. Default value:
1000
Stores service-zone pairs, and if the service is permitted to enter
the zone. Default value: 1000
Stores service-zone pairs, and if the service is permitted to leave
the zone. Default value: 1000
vas — Authentication Server
vas [options]
AS is an authentication server providing authentication services to a Vela based
firewall. Its behaviour is controlled by
vas.cfg(5)
and router.cfg
.
Do not daemonize, run in the foreground.
Send log messages to the standard output instead of syslog. This option implies foreground mode, overriding the contradicting process options if present.
Set verbosity level to <num>. Valid values are 0-10; default value is 3.
Enable logging of message tags.
Set verbosity mask on a per category basis. The format of this value is described in vela(8).
Use <file> as configuration file instead of the default
/etc/vas/vas.cfg
.
Display a brief help message.
vas.cfg — vas(8) configuration file.
The file uses an XML-like format to describe various configuration settings. It uses a
configuration/section/<setting> structure where the "name" attribute of the
configuration block identifies the AS subsystem described by the nested tags. The example
below sets the global options used by AS, broken down to three different sections: "log" for
log related settings, "router" to set the path to the router.cfg
file and
"ssl" for SSL related settings.
<configuration name="vas">
<section name="log">
<loglevel>3</loglevel>
<use_syslog>1</use_syslog>
<logtags>1</logtags>
</section>
<section name="router">
<router>/etc/vas/router.cfg</router>
</section>
<section name="ssl">
<use_ssl>0</use_ssl>
<key>/etc/vas/vas.key</key>
<cert>/etc/vas/vas.crt</cert>
<verify_mode>0</verify_mode>
</section>
</configuration>
The AS plugins (backends) have a slightly different structure. The name attribute in the
configuration tag of the AS plugin and the section name identifies an instance of that
plugin. Each instance can be run with a different parameter set. The example below shows a
complete configuration block for the PAM backend with two instances:
intra
and internet
:
<configuration name="pam">
<section name="intra">
<service>vas_intra</service>
<sleep_time>0</sleep_time>
<fake_user>0</fake_user>
</section>
<section name="internet">
<service>vas_internet</service>
<sleep_time>10</sleep_time>
<fake_user>1</fake_user>
</section>
</configuration>
The router.cfg
file controls the backend instance selection in AS.
When a new authentication request is initiated by vela(8), AS
selects an authentication backend and an instance based on the meta-information that Vela
supplies. Each line in router.cfg
comprises from a
condition
and an action
, separated by
whitespace. When an incoming request matches a condition
, the
corresponding the action
identifies the authentication backend and
its instance to be used.
The condition
is a comma separated list of constraints, each
constraint identifying an authentication header and an expected value in the
header=match,header=match,... format. Wildcard characters like '*' and
'?' can be included in the matches.The following headers are currently defined:
The name of the zone the client belongs to.
The original IP address of the client initiating the connection to be authenticated.
The name of the service the client is authenticating for.
The action
identifies the AS backend to use (e.g.:
vas_db
, pam
, etc.) and the specific instance
of that backend. The backend and instance names are separeated by colon (:). Instances are
identified by simple names and are used distinguish between various setups of the same
backend.
The example below selects the intra
instance of the
vas_db
backend. If the configuration block for this backend is not
found, or the condition does not match, the vas_db:default
instance
is used.
Client-Zone=intra vas_db:intra
vas_db:default
The global configuration options of AS are described in the vas
configuration block. The related options are grouped into sections. The following options are
available:
Section log
Use syslog for logging.
Enable the logging of message tags.
Level of verbosity for logging messages. Default value: 3.
Section bind
IP address to which AS binds. Default value: 0.0.0.0
.
Port to which AS binds. Default value: 1317.
Section ssl
Enable SSL encryption.
The certificate file used to authenticate AS.
The private key file of the certificate used to authenticate AS.
Path to the directory where the certificates of the trusted CAs are stored.
Path to the directory where the certificate revocation lists are stored.
The maximum length of the verification chain. Default value: 3.
Method how the certificates of the connections incoming to AS are verified.
No certificate is needed.
Certificate is optional, but has to be valid if present.
A valid certificate is required, untrusted (but valid) certificates are also accepted.
A valid, trusted certificate is required.
Section router
Path to the router.cfg
file.
Section misc
Permit password-based authentication methods even for unencrypted connections.
Default value: 0
(false).
AS operates using several authentication backends, each with its own set of parameters. Currently the following backends are available:
Database based backend which currently provides the most features. It has a backing database (called "storage") and a set of authentication methods (called "methods"). The name of the configuration block is vas_db
Authenticates users against the local PAM libraries on the host running AS itself. The name of the configuration block is pam.
Authenticates users against an Apache htpasswd style password file. The name of the configuration block is htpass.
Authenticates users against a RADIUS server. The name of the configuration block is radius.
Authenticates users against a TACACS+ server. The name of the configuration block is tacacs.
All backends are capable of authentication faking. This is a method to hide the valid usernames, so that they cannot be guessed (for example using brute-force methods). If somebody tries to authenticate with a non-existing username, the attempt is not immediately rejected: the full authentication process is simulated (e.g.: password is requested, etc.), and rejected only at the end of the process. That way it is not possible to determine if the username itself was valid or not.
The vas_db backend interprets the following parameters in its configuration block.
Specifies the database plugin to use. Currently only the ldap database is supported.
Specifies a space separated list of enabled authentication methods. The following authentication plugins are available: passwd, skey, rb1, x509, ldapbind, and none.
Enables authentication faking.
Specifies a user name which is used for faking authentication. This has to be an existing user name, used exclusively for this purpose.
Wait at least that many seconds after a failed authentication attempt.
The vas_db backend authenticates against an abstract database, the actual implementation is specified using the storage parameter. The only storage plugin currently supported is ldap.
The ldap storage plugin uses the Lightweight Directory Access Protocol (LDAP) to access a directory based database. It has a separate configuration block identified by the name vas_db_storage_ldap.
The LDAP storage plugin connects to an LDAP server, authenticates using a user-independent, service account and runs queries against the database to provide a vas_db dependent view on the directory. It uses a AS specific LDAP scheme available in the vas package.
Enables SSL/TLS when connecting to the LDAP server.
Specifies the LDAP host to use.
Specifies port of the LDAP server to use.
Bind to this DN before accessing the database.
Use this password when binding to LDAP.
Perform queries using this base DN.
Search for an account using this filter expression. Defaults to '(uid=%u)'; %u is expanded to the username being searched for.
Specifies the scope of the search. base
,
sub
, and one
are acceptable values,
specifying LDAP_SCOPE_BASE, LDAP_SCOPE_SUB, and LDAP_SCOPE_ONE, respectively.
Specify that the incoming username is a fully qualified DN.
Specify LDAP scheme to use: posix
for POSIX,
ad
for ActiveDirectory, or nds
for
Novell eDirectory/NDS style directory layout.
When the ldapbind
authentication method is used for
authentication, the value of this string is returned as method description to the
user. NOTE: This parameter is OBSOLETE, it must be set in the
ldapbind
authentication method.
When the directory contains user keys in the userCertificate attribute and it is used for X.509 based authentication, the value of this string will be returned as method description to the user. OBSOLETE. Set it in x509 authentication method.
If this option is set, AS will respect the referral response from the LDAP server when looking up a user.
The vas_db backend is general enough to allow the use of several
different authentication methods. The set of permitted authentication methods is defined
using the methods
configuration option as described in the previous
section. All pligins have a priority
attribute. This attribute is
used by the Authentication Agent client: the authentication methods available to the user
are displayed in the order of the priority (starting with the highest value).
The following method plugins are available:
Implements password authentication. Password authentication is available only if the connection between Vela and AS is secure. The name of the configuration block is vas_db_method_passwd.
The password authentication method has the following parameters:
Priority of the authentication type.
Implements S/Key authentication. The name of the configuration block is vas_db_method_skey.
The S/Key authentication method has the following parameters:
Priority of the authentication type.
Implements CryptoCard RB1 hardware token based authentication. The name of the configuration block is vas_db_method_rb1.
The RB1 authentication method has the following parameters:
Priority of the authentication type.
Implements X.509 certificate based authentication. The name of the configuration block is vas_db_method_x509.
The X.509 authentication method has the following parameters:
Compare the stored certificate bit-by-bit to the certificate supplied by the client. The authentication will fail when the certificates do not match, even if the new certificate is trusted by the CA. Default value: 1 (TRUE).
Send a list of trusted certificates to the client to choose from to narrow the list of available certificates. Default value: 1 (TRUE).
Verify the validity of the certificate (i.e. the certificate has to be
issued by one of the trusted CAs and not revoked). This is verification is
independent from the compare_cert
setting, so if both
parameters are set, both conditions must be fulfilled to accept the certificate.
Default value: 1 (TRUE).
A list of space separated URLs to the trusted CAs. The
file://
and ldap://
URLs are
supported.
A list of space separated URLs to the CRLs issued by the trusted CAs. The
file://
and ldap://
URLs are
supported.
The maximum length of the verification chain.
Priority of the authentication type.
Implements authentication against the target LDAP server. Only password authentication is supported by this method, therefore it is only available if the connection between AS and Vela is secured with SSL. The name of the configuration block is vas_db_method_ldapbind.
The LDAP authentication method has the following parameters:
Priority of the authentication type.
The value of this string is returned as method description to the user.
Implements NO authentication. This method accept every authentication request if the user is exists in the database. The main advantage of this method is when the authentication is done somwhere outside of this program but the groups information is needed. The name of the configuration block is vas_db_method_none.
The None authentication method has the following parameters:
Priority of the authentication type.
The value of this string is returned as method description to the user.
Implements GSSAPI based authentication. NOTE: The Kerberos5 keytab file to be used
can be specified via the standard KRB5_KTNAME
environment
variable. The name of the configuration block is
vas_db_method_gssapi.
The gssapi authentication method has the following parameters:
Priority of the authentication type.
The value of this string is returned as method description to the user.
Specifies the GSSAPI principal name which this authentication service
represents. Make sure that the keys associated with this principal are present
in /etc/krb5.keytab
. Changing the keytab location is
currently not possible.
The PAM backend implements authentication based on the local authentication settings of the host running AS. It basically authenticates the users against the local PAM installation and/or using GSSAPI/krb5. The PAM backend has the following parameters:
Use the local passwd/group database to query group membership of a given account. The Name Service Switch can also be used, so integrating other naming services is possible. Defaults value: 0 (FALSE).
Enable PAM authentication. Default value: 1 (TRUE).
Specifies the PAM service to use for authentication. This option is an alias for
the now deprecated service
option. Defaults value:
vas
.
Enable GSSAPI/krb5 authentication in this backend. Defaults value: 0 (FALSE).
NOTE: The Kerberos5 keytab file to be used can be specified via the standard
KRB5_KTNAME
environment variable.
Specifies the GSSAPI principal name which this authentication service represents.
Make sure that the keys associated with this principal are present in
/etc/krb5.keytab
. Changing the keytab location is currently not
possible.
The value of this string is returned as method description to the user.
Enables authentication faking.
Wait at least that many seconds after a failed authentication attempt.
The htpass backend has the following parameters:
The file to be read as password file. The file should contain two columns separated by colon (':'), with the first column containing the username, the second the password encrypted by crypt(3) function. This file can be created/maintained by the Apache htpasswd(1) utility.
Enables authentication faking.
Wait at least that many seconds after a failed authentication attempt.
The Radius backend has the following parameters:
The hostname of the RADIUS server.
The port of the RADIUS server.
The shared secret between the authentication server and AS.
The value of this string is returned as method description to the user.
Enables authentication faking.
Wait at least that many seconds after a failed authentication attempt.
The TACACS backend has the following parameters:
The hostname of the TACACS+ server.
The port of the TACACS+ server, defaults to 49.
The shared secret between the authentication server and AS.
The value of this string is returned as method description to the user.
Enables authentication faking.
Wait at least that many seconds after a failed authentication attempt.
vcf — Content Filtering Server
vcf [options]
The Content Filtering Server (CF) is a content scanning framework providing stream
and file scanning services for vela(8). CF runs as a separate
application and can be accessed over TCP, UNIX domain sockets and standard input and output
file handles. The behaviour of CF can be controlled via the
vcf.cfg(5)
configuration file.
Set verbosity level to <verbosity>, or if <verbosity> is omitted increment it by one. Default the verbosity level is 3; possible values are 0-10.
Send log messages to the standard output instead of syslog. This option implies foreground mode, overriding the contradicting process options if present.
Set verbosity mask on a per category basis. The format of this value is described in vela(8).
Enable logging of message tags.
Do not daemonize, run in the foreground.
Display a brief help message.
Start in Vela mode using the <ctrl-fd> file descriptor and remain in the foreground. In this mode only a single scan is performed on the data on the standard input. Results are sent to the standard output. (Naturally, log messages are not sent to the standard output in this mode, as this would interfere with the scanning results.) This mode is used mainly for testing purposes.
The value for the vcf_rule_group routing variable in Vela mode.
Use the configuration file <file> instead of the default
/etc/vcf/vcf.cfg
file.
Use <file> as pid file instead of the default
/var/run/vcf/vcf.pid
file.
CF scans the contents of incoming streams. CF has multiple channels, each performing a possibly different set of actions on the incoming stream. These channels are called "scanpaths", i.e. a scanpath is an ordered set of modules and their associated settings. The scanpath to be used is selected based on meta information provided by Vela and meta information gathered about the stream by CF itself. This scanpath selection mechanism is called "routing decision" and is controlled by the router rules.
To summarize, CF operates as follows: A connection is established between Vela and CF. CF selects a scanpath (i.e. makes the routing decision) based the collected information, the router rules and information received from Vela. The scanpath determines the modules to use and their associated settings. After the modules process the data received in the stream, the result of the scanning operation is sent back to Vela.
vcf.cfg — vcf(8) configuration file format
vcf.cfg
uses an XML-like format to describe various configuration
settings. The exact structure is
configuration/section/<setting>
, where the "name"
attribute of the configuration block identifies the CF subsystem described by the nested
tags.
The main configuration blocks of the file are the following:
Global options of vcf.
Definitions and settings of the scanpaths.
Definitions and instance-specific settings of the modules.
Global settings of the modules that apply to every instance of the module.
The example below sets the global options used by CF, broken down to three different
sections: log for log related settings, router for
setting the path to the router.cfg
file and misc for
miscellaneous parameters.
<configuration name="vcf">
<section name="log">
<loglevel>3</loglevel>
<use_syslog>true</use_syslog>
<logtags>true</logtags>
</section>
<section name="router">
<router>/etc/vcf/router.cfg</router>
</section>
<section name="misc">
<magic_length>2048</magic_length>
</section>
</configuration>
The CF modules have a slightly different structure. The name attribute in the configuration tag of the CF module and the section name identifies an instance of that module. Each instance can be run with a different parameter set. The example below shows a complete configuration block for the clamav module, with an instance named intranet having normal, and another named internet having paranoid sensitivity.
<configuration name="clamav">
<section name="internet">
<mode>file</mode>
<scan_packed>1</scan_packed>
<disinfect>0</disinfect>
<scan_suspicious>1</scan_suspicious>
<heuristic_level>normal</heuristic_level>
</section>
<section name="intranet">
<mode>file</mode>
<scan_packed>1</scan_packed>
<disinfect>1</disinfect>
<scan_suspicious>0</scan_suspicious>
<heuristic_level>normal</heuristic_level>
</section>
</configuration>
The router.cfg
file controls the scanpath selection in CF. CF
selects the scanpath based on the meta-information that Vela supplies. Each line in
router.cfg
comprises from a condition
and an
action
, separated by whitespace. When an incoming request matches a
condition
, the corresponding the action
identifies the scanpath and its instance to be used.
The condition
is a comma separated list of constraints, each
constraint identifying a variable and an expected value in the
header=match,header=match,... format. Wildcard characters like '*' and
'?' can be included in the matches.The following variables are currently defined:
The name of the rule group that the peer requests. Its value is specified the -R command line option in Vela mode, or is supplied by the peer during the handshake.
MIME type detected based on the first bytes of the file.
MIME type detected based on the first bytes of the file looking into a compressed file header and decompressing it if necessary.
MIME type as specified by the peer.
File name or URL.
File extension. Please note that this information might not be accurate as some URLs do not contain file extension in which case this variable is empty. For example it is common to reference directories in HTTP which implicitly map to a server defined content and the URL does not contain a filename extension as in http://domain.com/directory/. It is better to use content_type or content_type_detected for content specific scanning.
File transfer direction, either "upload" or "download".
Protocol that was used to transfer the checked file.
Vela session id that requested content filtering.
The name of the proxy class that requested content filtering.
The authenticated username.
Client address in AF_INET(>ipaddr<, >port<) format.
Client IP address.
Client TCP/UDP port.
The name of the client zone.
Server address in AF_INET(>ipaddr<, >port<) format.
Server IP address.
Server TCP/UDP port.
The name of the server zone.
The envelope sender address in SMTP.
Space separated list of envelope recipient addresses in SMTP.
The type of the HTTP request.
The HTTP request URL.
The version of the HTTP request (e.g. 1.1).
The Host header included in the HTTP request.
Furthermore, virtually all defined Vela variables can be used as variables with the
'vela.' prefix, which denotes the 'session' object of the stacking proxy. For example:
> vela.session_id
,
vela.client_address.ip_s
, etc.
The action
identifies the CF scanpath to use.
The example below selects the html
scanpath for all files which
are recognized as "text/html" files, and rejects everything else. An object is scanned only
by the scanpath of the first matching condition.
content_type="text/html" html
content_type_detected="text/html" html
REJECT
Global options are stored in the configuration block named vcf. Related options are grouped into sections.
Section log
Use syslog for logging.
Enable the logging of message tags.
Level of verbosity for logging messages. Default value: 3.
Set verbosity mask on a per category basis. The format of this value is described in vela(8).
Section misc
This parameter determines the amount of data (in bytes) read from MIME objects to detect their MIME-type. Higher value increases the precision of MIME-type detection. Default value: 0.
Location of the temporal directory (used for swap files, etc.). Default value:
/var/lib/vela/tmp
Section router
Location of the router.cfg
file. Default value:
/etc/vcf/router.cfg
Section bind
IP address to which CF binds. Default value: 0.0.0.0
.
Port to which CF binds. Default value: 1318
.
Bind to a unix domain socket. If only the empty tag is present, the default socket
(/var/run/vcf/vcf.sock
) is used.
When binding to a unix domain socket, the owner and the permissions of the socket can be set using the following parameters:
The owner of the socket. By default its value is NULL
,
meaning that the owner of the socket is the user running CF.
The owner group of the socket. Default value:
velastate
.
The permission settings of the socket in Unix-style. Default value:
770
.
Section blob
CF tries to store everything in the memory if possible. If the memory usage of CF
reaches hiwat
, it starts to swap the data onto the hard disk,
until the memory usage reaches lowat
. Default value: 960 *1024 *1024
(960 MB).
Lower threshold of data swapping. Default value: 640 *1024 *1024 (640 MB).
The maximum amount of hard disk space that CF is allowed to use. Default value: 64 * 1024 * 1024 * 1024 (64 GB).
The maximum amount of memory that CF is allowed to use. Default value: 1024 * 1024 * 1024 (1 GB).
Objects smaller than this value (in bytes) are never swapped to hard disk. Default value: 16384.
The period of deadlock check in seconds, to resolve deadlock, when storage is full. Default value: 5.
The time in seconds of waiting for blob allocation, if storage is full. Default value: 10.
The scanpath options are stored in the configuration block named scanpaths. Each section in this block has the name of a scanpath and contains settings specific for the given scanpath.
Settings to control trickling can also be configured here. Content filtering cannot be performed on partial files: the entire file has to be available on the firewall. Sending of the file to the client is started only if no virus was found (or the file was successfully disinfected). Instead of receiving the data in a continuous stream, as when connecting to the server “regularly”, the client does not receive any data for a while, then “suddenly” it starts to flow. This phenomena is not a problem for small files, since these are transmitted and checked fast, probably without the user ever noticing the delay, but can be an issue for larger files when the client application might time out. Another source of annoyance can be when the bandwidth of the network on the client and server side of the firewall is significantly different. In order to avoid time outs, a solution called trickling is used. This means that the firewall starts to send small pieces of data to the client so it feels that it is receiving something and does not time out. For further information on trickling, see the Virus filtering and HTTP Technical White Paper available at the Balasys Documentation Page at http://www.docs.balasys.hu/
The following options are available for each scanpath:
Comma-separated list of colon separated pairs listing the modules to be executed in
the scanpath. The colon-separated pairs specify the module and its instance (e.g.:
html:filterscripts, nod32:paranoid
).
Quarantine mode to be used. Always the original file is quarantined.
Quarantine all objects rejected for any reason.
Quarantine objects that could not be disinfected.
Quarantine only the original version of the files which were successfully disinfected. E.g.: if an infected object is found but it is successfully disinfected, the original (infected) object is quarantined. That way, the object is retained even if the disinfection eliminates some important information.
Disable quarantining, objects rejected for any reason are dropped.
Objects larger than threshold_oversize
(in bytes) are not
scanned, because of performance/resource reasons (i.e. large archives, ISO files,
etc.).
Mode of trickling to be used. Default: NONE.
Trickling is disabled.
Determine the amount of data to be trickled based on the size of the object. Data is sent to the client only when CF receives new data; the size of the data trickled is the set percentage of the total data received so far. This is the recommended method to use.
Trickle fixed amount of data in fixed time intervals.
Amount of data to be trickled (percentage). Defailt value: 10.
When an object is downloaded, trickling is started after this period (in seconds). Default value: 10.
Period (in seconds) between trickling data chunks.
Amount of data (in bytes) that is sent to the client in a chunk during trickling. Default value: 128 bytes.
The following modules are available in CF:
Filters and rewrites the input in stream similarly to the operation of the UNIX 'sed' command.
Performs virus scanning on the incoming data with the NOD32 engine. The data is processed in file mode.
Performs virus scanning on the incoming data with the Clam AntiVirus engine. The data is processed in file mode.
Performs JavaScript/Java/ActiveX filtering of HTML data in stream mode.
Performs spam filtering on the incoming e-mails with the SpamAssassin engine. The data is processed in file mode.
Performs filtering and manipulation on the headers of e-mail messages. The data can be processed both in file and stream mode.
ModSecurity is a platform-independent web application level security gateway module (Web Application Firewall (WAF)), that can be integrated to Vela Gateway. ModSecurity's WAF solution can look into the HTTP(S) traffic and provides a powerful policy definition language and an API to achieve advanced security.
Performs filtering and/or manipulation of the data with an external 3rd-party application. The data can be processed either in file and stream mode.
The configuration name of the sed module is sed. This module has the following instance-specific options:
The stucture of this string is the following: a slash (/), the string to be replaced, a slash (/), the replacement string, and the options. Slashes in the string have to be escaped with backslashes.The folowing options are available:
Replace all occurances of the string.
Run in case insensitive mode.
For example, the /example/sample/-g filter replaces all occurances of 'example' to 'sample'.
The nod32 module has the following instance-specific options:
Perform virus scanning on archived files. Default value: YES.
Perform virus scanning on suspicious files (e.g.: suspicious files are often new variants of known viruses). Default value: NO.
Level of heuristic sensitivity. The available levels are OFF, NORMAL, and HIGH. Default value: OFF.
Archives larger than the specified value (in megabytes) are not scanned. Zero means unlimited. Default value: 10.
The configuration name of the Clam AntiVirus module is clamav. The module has the following module options:
The domain socket used to communicate with the clamav engine. Default value:
/var/run/clamav/clamd.ctl
The clamav module has the following instance-specific options:
Perform virus scanning on archived files. Default value: YES.
The configuration name of the SpamAssassin module is spamassassin. The module has the following instance-specific options::
Only check the e-mails, but do not make any modification to the e-mail. The result of the spam filtering is returned to CF separately. Default value: FALSE.
The hostname and port number of the machine SpamAssassin is running on, if different from the CF host.
The domain socket used to communicate with SpamAssassin if it is running on the CF
host. Default value: /var/run/spamassassin.sock
The user under which SpamAssassin should filter e-mails. Default value: not set, the
user running SpamAssassin is used (nobody
).
Timeout value for the scanning requests in seconds. Default value:
60
.
Note |
---|
If the timeout is set to -1 (unlimited), then no timeout is used for the connection if SpamAssassin is running on a remote host. |
By default, CF rejects all e-mails SpamAssassin detects as spam.
However, to minimize the impacts of false positives, if the spam
status of an e-mail (as calculated by SpamAssassin) is over the
required_score
(default value: 5
), but below
the value set in threshold
, CF only marks the e-mail as spam,
but does not reject it. If the spam status of an e-mail is above the threshold
,
it is automatically rejected. Default value: 10.0
.
The configuration name of the html module is html.
The html module has the following instance-specific options:
Remove javascript from HTML pages. Default value: NO. Enabling this option removes
all javascript
and script
tags, and the
conditional value prefixes (e.g.: onclick
,
onreset
, etc.).
Remove ActiveX components from HTML pages. Default value: NO. Enabling this option
removes the applet
tags and the classid
value prefix.
Remove java from HTML pages. Default value: NO. Enabling this option removes the
java:
and application/java-archive
inclusions, as well as the applet
tags.
Remove CSS (cascading style sheets) from HTML pages. Default value: NO. Enabling
this option removes the single link
tags, the
style
tags and options, as well as the
class
options.
A whitespace-separated value of colon separated pairs, specifying the headers, tags, etc. to be removed based on their names or their values.
The following HTML elements can be filtered:
Tags: Remove everything between the specified tag and its
closing tag. Embedded structures are also handled. E.g.:
closed-tag:ul
Single tags: Remove all occurrences of the specified single tag
(img
, hr
, etc.). E.g.:
tag:hr
Options: Remove options (e.g.: width
,
etc.) and their values. E.g.: option:width
Prefixes: Remove all options starting with the set prefix.
E.g.: prefix:on
will remove all options like
onclick
, etc.
This attribute control the size of the internal buffer of this module
The configuration name of the mail header module is mail-hdr. A
filter contains a pattern (i.e. the header line to be found) enclosed within backslashes
(/
), a whitespace, the action to be performed on the header line, and
an optional argument. The pattern and the argument can be regular expressions. To search for
the pattern in case insensitive mode, add an i
character after the
closing backslash of the pattern. The following actions can be performed on the mail headers:
Append: Add the argument of the filter as a new header line after the match.
Discard: Discard the entire e-mail message. The argument is returned to the mail server sending the message as an error message.
Ignore: Remove the matching header line from the message.
Pass: Accept the matching header line. This action can be used to create exceptions from other filter rules.
Prepend: Add the argument of the filter as a new header line before the match.
Reject: Reject the entire e-mail message. The argument is returned to the sender of the message as an error message.
Replace: Replace the mathing header line to the argument of the filter.
The module has the following instance-specific options::
The list of filters to be applied on the mail headers. For example:
<filter>
/^Subject: hello$/i DISCARD
/^Date: (.*)/ APPEND "X-Date: \1 \1"
<filter>
If a manipulated header line is longer than this value (in bytes), is will be broken
into a new lines. These new lines will not be longer then
header_wrap_length
. Default value: .
This attribute control the maximum length of a header line
The configuration name of the Modsecurity module is modsecurity. The module has the following module options:
Ruleset configuration file for ModSecurity. Default value: not set.
Timeout value for transactions, in seconds. Default value: 60.
Request bodies will be buffered and processed by ModSecurity. Default value: YES.
Response bodies will be buffered by ModSecurity. Default value: YES.
The maximum request body size ModSecurity will accept for buffering, in KBytes. Anything over the limit will be rejected with status code 413 (Request Entity Too Large). Default value: 10000.
The maximum request body size ModSecurity will accept for buffering in KBytes, excluding the size of any files being transported in the request. Default value: 1000.
The maximum response body size that will be accepted for buffering, in KBytes. Anything over this limit will be rejected with status code 500 (Internal Server Error). Default value: 1000.
vms — Vela Management Server engine
vms [options]
vms is the server component of Vela Management System, which is a distributed management system for Vela firewalls. The server component is responsible for storing configuration data, distributing keys and certificates, and accepting administrator changes via the MC graphical user interface.
Display version information.
Do not daemonize, run in the foreground.
Send log messages to the standard output instead of syslog. This option implies foreground mode, overriding the contradicting process options if present.
Set the verbosity level of logging to <level>. Default value: 3.
Enable tag logging.
Use the configuration file <file> instead of the default file.
Set verbosity mask on a per category basis. The format of this value is described in vela(8).
Bootstrap the engine.
Display a brief help message.
vms.conf — Configuration file format for the Vela Management Server (vms(8)).
The vms.conf
file controls the operation of the Vela Management
Server vms(8). It is rarely needed to modify the configuration
manually.
WARNING: The settings stored in vms.conf
are managed by the MS
engine via MC. Do not modify the settings manually unless you know exactly what you are
doing.
vms.conf
uses an XML-like format to describe various configuration
settings. The exact structure is
configuration/section/<setting>
, where the "name"
attribute of the configuration block identifies the subsystem described by the nested tags.
Main configuration blocks are found in the default
configuration
block, with related options grouped into sections such as global
,
log
, and ssl
.
WARNING: The settings stored in the vms.conf
file are used internally
within Vela; the structure of the file and the individual options may change between the
different Vela releases.
vms-integrity — VMS Database Integrity Checker
vms-integrity [options]
vms-integrity is a tool for checking the integrity of the VMS database. It can also be used for recovery if the database contains errors.
Database directory. Default value: /var/lib/vms
.
Try to recover database if integrity check fails. If not set, the integrity check will only report the errors found.
Use syslog for logging.
Set the verbosity level of logging to <level>. Default value: 3.
No logging, only exit status is set.
Display a brief help message.
When restoring an earlier VMS database and the process fails, the vms-integrity can fix the database backup archive file. To recover a vms-backup-<timestamp>.tar.gz formatted file, complete the following steps.
mkdir /tmp/vms-backup
tar -zxf <backup-file-to-restore> -C /tmp/vms-backup
/usr/sbin/vms-integrity -r -d /tmp/vms-backup
/usr/sbin/vms-integrity -d /tmp/vms-backup
tar -C /tmp/vms-backup -czf <fixed-backup-file>
rm -rf /tmp/vms-backup
instances.conf — vela(8) instances database
The instances.conf
file describes the
vela(8)
instances to be run on the system. It is processed by
velactl(8)
line by line, each line having the structure described below. Empty lines and lines
beginning with '#' are comments ignored by velactl.
instance-name parameters [-- velactl-options]
instance-name is the name of the Vela instance to be started; it is passed to vela with its --as parameter. Instance names may consist of the characters [a-zA-Z0-9_] and must begin with a letter.
parameters are space separated parameters entered into the vela command-line. For details on these command-line parameters see vela(8).
velactl-options are space separated parameters control startup specific options. They are processed by velactl itself. The following velactl options are available:
Enable the automatic restart feature of velactl. When an instance is in auto-restart mode, it is restarted automatically in case the instance exits.
Disable automatic restart for this instance.
Set the file descriptor limit to <number>. The file descriptor limit defaults to the number of threads (specified by the --threads parameter of vela(8)) multiplied by 4.
Run <number> of processes for the instance. velactl starts exactly one Vela process in master mode and <number> of slave Vela processes. This mode of operation is incompatible with old-style dispatchers, you must use the new rule-based policy with this option.
vela_ftp --policy /etc/vela/policy.py --verbose 5
The line above describes a Vela instance named vela_ftp using policy file /etc/vela/policy.py, and having verbosity level 5.
vela_intra -v4 -p /etc/vela/policy.py --threads 500 --no-auto-restart --fd-limit 1024 --process-limit 512
This line describes a vela instance named vela_intra using the policy
file /etc/vela/policy.py
, verbosity level 4. The maximum number of
threads is set to 500, file descriptor limit to 1024, process limit to 512.
policy.py — vela(8) policy file.
The policy.py
file is a Python module containing the zone and service
definitions and other policy related settings used by
vela(8)
. Empty lines and lines beginning with '#' are comments and are ignored.
The policy.py
file is generated automatically by MC, the Vela
Management Console, or it can be edited manually.
IMPORTANT: Do not edit manually a file generated by MC, because the manual changes will not be retained by MC and will be lost when re-generating the file.
For further information on policy.py
refer to the following sources:
A tutorial on manually editing the policy.py
file can be found at
http://www.docs.balasys.hu/.
Additional information can also be found in the Vela Administrator's Guide, the Vela Reference Guide, and in the various tutorials available at the Balasys Documentation Page at http://www.docs.balasys.hu.
vela — Vela Firewall Suite
vela [options]
The vela command is the main entry point for a Vela instance, and as
such it is generally called by velactl(8) with command line
parameters specified in
instances.conf(5)
.
Display version number and compilation information.
Set instance name to <name>. Instance names may consist of the characters [a-zA-Z0-9_] and must begin with a letter. Log messages of this instance are prefixed with this name.
Send log messages to the standard output instead of syslog. This option implies foreground mode, overriding the contradicting process options if present.
Prepend log category and log level to each message.
Escape non-printable characters to avoid binary log files. Each character less than 0x20 and greater than 0x7F are escaped in the form <XX>.
Set verbosity mask on a per category basis. Each log message has an assigned multi-level category, where levels are separated by a dot. For example, HTTP requests are logged under http.request. <spec> is a comma separated list of log specifications. A single log specification consists of a wildcard matching log category, a colon, and a number specifying the verbosity level of that given category. Categories match from left to right. E.g.: --logspec 'http.*:5,core:3'. The last matching entry will be used as the verbosity of the given category. If no match is found the default verbosity specified with --verbose is used.
Set the maximum number of threads that can be used in parallel by this Vela instance.
Set the maximum number of idle threads; this option has effect only if threadpools are enabled (see the option --threadpools).
Enable the use of threadpools, which means that threads associated with sessions are not automatically freed, only if the maximum number of idle threads is exceeded.
Switch to the supplied user after starting up.
Switch to the supplied group after starting up.
Change root to the specified directory before reading the configuration file. The directory must be set up accordingly.
Switch to the supplied set of capabilities after starting up. This should contain the required capabilities in the permitted set. For the syntax of capability description see the man page of cap_from_text(3).
Do not change capabilities at all.
Set the OpenSSL crypto engine to be used for hardware accelerated crypto support.
velactl — Start and stop vela instances.
velactl command [options [instances/@instance-list-file]]
velactl starts and stops vela(8) instances
based on the contents of the
instances.conf(5)
file. Multiple instance names can be specified in the
command-line or in a file to start or stop several instances. If an
error occurs while stopping or starting an instance, an exclamation
mark is appended to the instance name as velactl
processes the request, and a summary is printed when the program
exits. If no instance is specified, the command is executed on all
instances. The instances to be controlled can be specified in a file instead
of listing them in the command line, e.g.: velactl command options
instances.txt. The instances.txt
should contain every instance
name in a new line.
Starts the specified Vela instance(s).
Starts the specified Vela instance(s) even if they are disabled.
Stops the specified Vela instance(s).
Forces the specified Vela instance(s) to stop using the KILL signal.
Restart the specified Vela instance(s).
Forces the specified Vela instance(s) to restart by stopping them using the KILL signal.
Reload the specified Vela instance(s).
Display the status of the specified Vela instance(s).
Display detailed status information.
Display the status of the specified Vela instance(s) in an internal format easily parsable by MC. NOTE: This command is mainly used internally within Vela, and the structure of its output may change.
Display version information on Vela.
Raise the verbosity (log) level of the specified Vela instance(s) by one.
Decrease the verbosity (log) level of the specified Vela instance(s) by one.
Change various log related settings in the specified Vela instance(s) using the following options:
Increase verbosity level by one.
Decrease verbosity level by one.
Set verbosity level to <verbosity>.
Set verbosity mask on a per category basis. The format of this value is described in vela(8).
Display this help screen on the options of the log command.
Display internal information from the specified Vela instance(s). The information to be disblayed can be specified with the following options:
Walk the specified tree.
Set the root node of the walk operation to [node].
Display a brief help on the options of the szig command.
Display a brief help message.
velactl.conf — velactl(8) configuration file.
The velactl.conf
file describes various global options ifluencing the
behavior of
velactl(8)
.
velactl(8)
processes the file line by line, each line having the structure described below. Empty
lines and lines beginning with '#' are comments and are ignored.
variable name = variable value
Each non-empty line specifies a variable name and its value separated by the equal sign ('='). The following variables are available:
Enable the automatic restart feature of velactl. Instances in auto-restart mode are restarted automatically when they exit. Default value: 1 (TRUE).
The number of seconds to wait for a stopping Vela instance. Default value: 3.
In auto-restart mode there is no real way to detect whether Vela failed to load or not. Velactl waits START_CHECK_TIMEOUT seconds and assumes that Vela loaded successfully if it did not exit within this interval. Default value: 5 seconds.
In no-auto-restart mode the successful loading of a Vela instance can be verified by instructing Vela to daemonize itself and waiting for the parent to exit. This parameter specifies the number of seconds to wait for Vela to daemonize itself. Default value: 60 seconds.
Vela-specific arguments to be appended to the command line of each Vela instance. Also recognised as APPEND_ARGS (deprecated). Default value: "".
Velactl-specific arguments to be appended to the command line of each instance. Default value: "".
Specifies whether to check the permissions of the Vela configuration directory. If
set, Vela refuses to run if the /etc/vela
directory can be written
by user other then vela
Default value: 1 (TRUE).
The path to the Vela configuration directory to check if CHECK_PERMS is enabled.
NOTE: it does not change the Vela policy file argument, this parameter is only used by
the permission validating code. Default value: ${prefix}/etc/vela
.
The owner/group/permissions values considered valid for the configuration directory. velactl fails if the actual owner/group/permissions values conflict the ones set here. Default values: root.vela, 0750 .
The path to the Vela pid file directory. The directory is created automatically
prior to starting Vela if it does not already exist.It is created if it does not exist,
before NOTE: No --pidfile argument is passed to Vela, only
texistance of the directory is verified. Default value:
/var/run/vela
.
The owner/group/permission values the pidfile directory is created with if it does not exist. Default values: root.root, 0700.
vela-zone-helper — Zone helper daemon
vela-zone-helper [options]
vela-zone-helper(8) is a daemon responsible for maintaining
zone address information in vela-nfqueue-helper and also for updating
dynamic address information in hostname-based zones. Its behaviour is controlled by
vela-zone-helper.conf(5)
or command-line options.
Command-line options take precedence over configuration files.
Set verbosity level to <num>. The valid values are 0-10; the default value is 3.
Set verbosity mask on a per category basis. The format of this value is described in vela(8).
Send log messages to the standard output instead of syslog.
Set bogus DNS response filtering level to <num>. The valid values are 0-3; the default value is 3. For more information see vela-zone-helper.conf.5.
Set the maximum number of DNS resolver threads. The default value is 8.
Reload running vela-zone-helper(8) daemon.
Use <filename> as configuration file instead of the default
/etc/vela/vela-zone-helper.conf
.
Display a brief help message.
vela-zone-helper.conf — vela-zone-helper(8) configuration file
The vela-zone-helper.conf
file describes various global options controlling the
behavior of vela-zone-helper(8).
vela-zone-helper(8) processes the lines of the file under [vela-zone-helper] group, each line having the structure described below. Empty lines and lines beginning with '#' or ';' are comments and are ignored.
variable name = variable value
Each non-empty line specifies a variable name and its value separated by the equal sign ('='). The following variables are available:
Set logging verbosity level. The default value is: 3.
Set verbosity mask on a per category basis. The format of this value is described in vela-zone-helper(8). The default value is: core.accounting:4.
Send log messages to the standard output instead of syslog. The default value is: 0 (False).
Set bogus DNS response filtering level. The default value is: 3. Filtered addresses will not be used in hostname-based zones.
DNS_FILTER_LEVEL value is interpreted as:
0 = No filtering takes place
1 = Filter invalid host addresses: unspecified addresses ('0.0.0.0/32', '::/128').
2 = Filter loopback address ranges ('127.0.0.0/8', '::1/128')
3 = Filtering of private address ranges ('192.168.0.0/16', '10.0.0.0/8', '172.16. 0.0/12', 'fc00::/7'), link-local address ranges ('169.254.0.0/16', 'fe80::/10') and multicast ranges (224.0.0.0/4 , 'ff00::/8')
Set the maximum number of DNS resolver threads. To perform non-threaded resolving operations, set the value to 0. The default value is 8.
vela-geoip-helper — GeoIP helper daemon
vela-geoip-helper [options]
vela-geoip-helper(8) is a daemon responsible for downloading
and keeping the geoip database up to date for geographical location based access
conrol in vela-nfqueue-helper. Its behaviour is controlled by
vela-geoip-helper.conf(5)
or command-line options.
Command-line options take precedence over configuration files.
Set verbosity level to <num>. The valid values are 0-10; the default value is 3.
Set verbosity mask on a per category basis. The format of this value is described in vela(8).
Send log messages to the standard output instead of syslog.
Reload running vela-geoip-helper(8) daemon.
Use <filename> as configuration file instead of the default
/etc/vela/vela-geoip-helper.conf
.
Display a brief help message.
Use the provided <id> when connecting to MaxMind servers for database retrival.
Use the provided <key> when connecting to MaxMind servers for database retrival.
Select MaxMind GeoIP database edition. Supported values are <GeoLite2-Country> and <GeoIP2-Country>.
Check the MaxMind servers every <num> seconds for GeoIP database update.
vela-geoip-helper.conf — vela-geoip-helper(8) configuration file
The vela-geoip-helper.conf
file describes various global options controlling the
behavior of vela-geoip-helper(8).
vela-geoip-helper(8) processes the lines of the file under [vela-geoip-helper] group, each line having the structure described below. Empty lines and lines beginning with '#' or ';' are comments and are ignored.
variable name = variable value
Each non-empty line specifies a variable name and its value separated by the equal sign ('='). The following variables are available:
Set logging verbosity level. The default value is: 3.
Set verbosity mask on a per category basis. The format of this value is described in vela-geoip-helper(8). The default value is: core.accounting:4.
Send log messages to the standard output instead of syslog. The default value is: 0 (False).
Set the ACCOUNT_ID towards MaxMind servers.
Set the ACCOUNT_ID towards MaxMind servers.
Set the LICENSE_KEY towards MaxMind servers.
Select the GeoIP database version to use. See MaxMind for further information on database editions.
The following values are supported:
GeoLite2-Country
GeoIP2-Country
Sets the UPDATE_INTERVAL to check for GeoIP database updates in seconds. Default value is 3000. Checking if a database update is available does not contribute towards the download limits of MaxMind.
vavupdate — Updates the various AntiVirus engine's databases.
vavupdate [options]
vavupdate updates the databases of the various AntiVirus engines (Clamav, NOD32) used by Vela and VCF to filter the contents of the incoming and outgoing traffic.
The verbosity level of the program. Default value: 3.
0: No messages.
1: Show only error messages.
2: Report successful database updates.
3: Show also progress indicator messages.
4: Show all messages. (NOTE: The output can be very large.)
Force the execution of vavupdate, with this option the HRS settings in
/etc/vela/*.options
can be overridden.
Display the version number of vavupdate.
Use syslog for logging (otherwise vavupdate logs into the file
/var/log/vavupdate.log
).
Display a brief help message.
vavupdate.conf, clamav.options, nod32.options — vavupdate(8) configuration files.
vavupdate reads its configuration from the
/etc/vela/vavupdate.conf
file and the various .options
files in the /etc/vela
directory. vavupdate was
designed to run regularly as a cron job.
The e-mail address(es) of the administrator(s). Leaving this field blank suppresses the sending of notification e-mails.
The verbosity level of the program.
0: no messages;
1: show only error messages;
2: report successful database upgrades;
3: show also progress indicator messages;
4: show all messages (NOTE: The output can be huge.).
When set to 1, vavupdate use syslog for logging (otherwise
vavupdate logs into the file
/var/log/vavupdate.log
).
If access to FTP servers has to go through a proxy and the individual AV engine's package do not handle proxy server settings, the following setting has to be used: FTPPROXY="http://proxyhost:proxyport/" . If the proxy requires authentication, specify the username and the password as well: FTPPROXY="http://username:password@proxyhost:proxyport/.
Access HTTP servers via proxy. The syntax is the same as the FTPPROXY's.
An optional prefix which will be written to the subject line of the e-mail messages sent by the program. When using vavupdate on multiple hosts, this setting can be used to differentiate between the hosts. It is recommended to set this parameter to the hostname of the host vavupdate is running on.
The hours when vavupdate will run the database update for the specied AV engine.
Example: HRS="5 11 17 23".
If the HRS parameter is left blank, vavupdate will updates the database every time it
is invoked. It has to be specified in the per-engine .options
files.
DEPRECATED
vqc — Vela Quarantine Checker
vqc [options]
Check a quarantine directory and manage the files it contains.
There are no mandatory arguments; the settings may be specified as command-line options.
Display a brief help message.
Directory used as quarantine. Default value:
/var/lib/vela/quarantine
.
Chooses output format (txt or xml). Default value: xml.
Makes the output more verbose.
Selection options
Select only the objects matching <expression>.
NOTE: This option may not be used together with --id.
Select only the objects having the specified ids.
NOTE: This option may not be used together with --expr.
Restrictive options
Select files older than <days>
days.
Select only files larger than <Bytes> bytes. The size is specified in bytes by default, the 'k' suffix means kilobytes, etc.
Select only objects above the total count limit <Number>.
Action options
List the selected objects. Only the specified fields (<field0, field1, ...>) are displayed.
Dump the selected objects, or only the first <Bytes> bytes of each object if <Bytes> is specified.
Delete the selected objects.
Send the selected objects as attachment to <email address>,
Subject for email sent by --attachment-to, empty by default.
Forward the selected objects to <email address>.
(c) BalaSys IT Security.
1.1 This License Contract is entered into by and between BalaSys and Licensee and sets out the terms and conditions under which Licensee and/or Licensee's Authorized Subsidiaries may use the Proxedo Network Security Suite under this License Contract.
In this License Contract, the following words shall have the following meanings:
2.1 BalaSys
Company name: BalaSys IT Security.
Registered office: H-1117 Budapest, Alíz Str. 4.
Company registration number: 01-09-687127
Tax number: HU11996468-2-43
2.2. Words and expressions
Annexed Software
Any third party software that is a not a BalaSys Product contained in the install media of the BalaSys Product.
Authorized Subsidiary
Any subsidiary organization: (i) in which Licensee possesses more than fifty percent (50%) of the voting power and (ii) which is located within the Territory.
BalaSys Product
Any software, hardware or service licensed, sold, or provided by BalaSys including any installation, education, support and warranty services, with the exception of the Annexed Software.
License Contract
The present Proxedo Network Security Suite License Contract.
Product Documentation
Any documentation referring to the Proxedo Network Security Suite or any module thereof, with special regard to the reference guide, the administration guide, the product description, the installation guide, user guides and manuals.
Protected Hosts
Host computers located in the zones protected by Proxedo Network Security Suite, that means any computer bounded to network and capable to establish IP connections through the firewall.
Protected Objects
The entire Proxedo Network Security Suite including all of its modules, all the related Product Documentation; the source code, the structure of the databases, all registered information reflecting the structure of the Proxedo Network Security Suite and all the adaptation and copies of the Protected Objects that presently exist or that are to be developed in the future, or any product falling under the copyright of BalaSys.
Proxedo Network Security Suite
Application software BalaSys Product designed for securing computer networks as defined by the Product Description.
Warranty Period
The period of twelve (12) months from the date of delivery of the Proxedo Network Security Suite to Licensee.
Territory
The countries or areas specified above in respect of which Licensee shall be entitled to install and/or use Proxedo Network Security Suite.
Take Over Protocol
The document signed by the parties which contains
a) identification data of Licensee;
b) ordered options of Proxedo Network Security Suite, number of Protected Hosts and designation of licensed modules thereof;
c) designation of the Territory;
d) declaration of the parties on accepting the terms and conditions of this License Contract; and
e) declaration of Licensee that is in receipt of the install media.
3.1. For the Proxedo Network Security Suite licensed under this License Contract, BalaSys grants to Licensee a non-exclusive,
non-transferable, perpetual license to use such BalaSys Product under the terms and conditions of this License Contract and the applicable Take Over Protocol.
3.2. Licensee shall use the Proxedo Network Security Suite in the in the configuration and in the quantities specified in the Take Over Protocol within the Territory.
3.3. On the install media all modules of the Proxedo Network Security Suite will be presented, however, Licensee shall not be entitled to use any module which was not licensed to it. Access rights to modules and IP connections are controlled by an "electronic key" accompanying the Proxedo Network Security Suite.
3.4. Licensee shall be entitled to make one back-up copy of the install media containing the Proxedo Network Security Suite.
3.5. Licensee shall make available the Protected Objects at its disposal solely to its own employees and those of the Authorized Subsidiaries.
3.6. Licensee shall take all reasonable steps to protect BalaSys's rights with respect to the Protected Objects with special regard and care to protecting it from any unauthorized access.
3.7. Licensee shall, in 5 working days, properly answer the queries of BalaSys referring to the actual usage conditions of the
Proxedo Network Security Suite, that may differ or allegedly differs from the license conditions.
3.8. Licensee shall not modify the Proxedo Network Security Suite in any way, with special regard to the functions inspecting the usage of the software. Licensee shall install the code permitting the usage of the Proxedo Network Security Suite according to the provisions defined for it by BalaSys. Licensee may not modify or cancel such codes. Configuration settings of the Proxedo Network Security Suite in accordance with the possibilities offered by the system shall not be construed as modification of the software.
3.9. Licensee shall only be entitled to analize the structure of the BalaSys Products (decompilation or reverse- engineering) if concurrent operation with a software developed by a third party is necessary, and upon request to supply the information required for concurrent operation BalaSys does not provide such information within 60 days from the receipt of such a request. These user actions are limited to parts of the BalaSys Product which are necessary for concurrent operation.
3.10. Any information obtained as a result of applying the previous Section
(i) cannot be used for purposes other than concurrent operation with the BalaSys Product;
(ii) cannot be disclosed to third parties unless it is necessary for concurrent operation with the BalaSys Product;
(iii) cannot be used for the development, production or distribution of a different software which is similar to the BalaSys Product
in its form of expression, or for any other act violating copyright.
3.11. For any Annexed Software contained by the same install media as the BalaSys Product, the terms and conditions defined by its copyright owner shall be properly applied. BalaSys does not grant any license rights to any Annexed Software.
3.12. Any usage of the Proxedo Network Security Suite exceeding the limits and restrictions defined in this License Contract shall qualify as material breach of the License Contract.
3.13. The Number of Protected Hosts shall not exceed the amount defined in the Take Over Protocol.
3.14. Licensee shall have the right to obtain and use content updates only if Licensee concludes a maintenance contract that includes such content updates, or if Licensee has otherwise separately acquired the right to obtain and use such content updates. This License Contract does not otherwise permit Licensee to obtain and use content updates.
4.1 Authorized Subsidiaries may also utilize the services of the Proxedo Network Security Suite under the terms and conditions of this License Contract. Any Authorized Subsidiary utilising any service of the Proxedo Network Security Suite will be deemed to have accepted the terms and conditions of this License Contract.
5.1. Licensee agrees that BalaSys owns all rights, titles, and interests related to the Proxedo Network Security Suite and all of BalaSys's patents, trademarks, trade names, inventions, copyrights, know-how, and trade secrets relating to the design, manufacture, operation or service of the BalaSys Products.
5.2. The use by Licensee of any of these intellectual property rights is authorized only for the purposes set forth herein, and upon termination of this License Contract for any reason, such authorization shall cease.
5.3. The BalaSys Products are licensed only for internal business purposes in every case, under the condition that such license does not convey any license, expressly or by implication, to manufacture, duplicate or otherwise copy or reproduce any of the BalaSys Products.
No other rights than expressly stated herein are granted to Licensee.
5.4. Licensee will take appropriate steps with its Authorized Subsidiaries, as BalaSys may request, to inform them of and assure compliance with the restrictions contained in the License Contract.
6.1. BalaSys hereby grants to Licensee the non-exclusive right to use the trade marks of the BalaSys Products in the Territory in accordance with the terms and for the duration of this License Contract.
6.2. BalaSys makes no representation or warranty as to the validity or enforceability of the trade marks, nor as to whether these infringe any intellectual property rights of third parties in the Territory.
7.1. In case of negligent infringement of BalaSys's rights with respect to the Proxedo Network Security Suite, committed by violating the restrictions and limitations defined by this License Contract, Licensee shall pay liquidated damages to BalaSys. The amount of the liquidated damages shall be twice as much as the price of the BalaSys Product concerned, on BalaSys's current Price List.
8.1. BalaSys shall pay all damages, costs and reasonable attorney's fees awarded against Licensee in connection with any claim brought against Licensee to the extent that such claim is based on a claim that Licensee's authorized use of the BalaSys Product infringes a patent, copyright, trademark or trade secret. Licensee shall notify BalaSys in writing of any such claim as soon as Licensee learns of it and shall cooperate fully with BalaSys in connection with the defense of that claim. BalaSys shall have sole control of that defense (including without limitation the right to settle the claim).
8.2. If Licensee is prohibited from using any BalaSys Product due to an infringement claim, or if BalaSys believes that any BalaSys Product is likely to become the subject of an infringement claim, BalaSys shall at its sole option, either: (i) obtain the right for Licensee to continue to use such BalaSys Product, (ii) replace or modify the BalaSys Product so as to make such BalaSys Product non-infringing and substantially comparable in functionality or (iii) refund to Licensee the amount paid for such infringing BalaSys Product and provide a pro-rated refund of any unused, prepaid maintenance fees paid by Licensee, in exchange for Licensee's return of such BalaSys Product to BalaSys.
8.3. Notwithstanding the above, BalaSys will have no liability for any infringement claim to the extent that it is based upon:
(i) modification of the BalaSys Product other than by BalaSys,
(ii) use of the BalaSys Product in combination with any product not specifically authorized by BalaSys to be combined with the BalaSys Product or
(iii) use of the BalaSys Product in an unauthorized manner for which it was not designed.
9.1. The number of the Protected Hosts (including the server as one host), the configuration and the modules licensed shall serve as the calculation base of the license fee.
9.2. Licensee acknowlegdes that payment of the license fees is a condition of lawful usage.
9.3. License fees do not contain any installation or post charges.
10.1. BalaSys warrants that during the Warranty Period, the optical media upon which the BalaSys Product is recorded will not be defective under normal use. BalaSys will replace any defective media returned to it, accompanied by a dated proof of purchase, within the Warranty Period at no charge to Licensee. Upon receipt of the allegedly defective BalaSys Product, BalaSys will at its option, deliver a replacement BalaSys Product or BalaSys's current equivalent to Licensee at no additional cost. BalaSys will bear the delivery charges to Licensee for the replacement Product.
10.2. In case of installation by BalaSys, BalaSys warrants that during the Warranty Period, the Proxedo Network Security Suite, under normal use in the operating environment defined by BalaSys, and without unauthorized modification, will perform in substantial compliance with the Product Documentation accompanying the BalaSys Product, when used on that hardware for which it was installed, in compliance with the provisions of the user manuals and the recommendations of BalaSys. The date of the notification sent to BalaSys shall qualify as the date of the failure. Licensee shall do its best to mitigate the consequences of that failure. If, during the Warranty Period, the BalaSys Product fails to comply with this warranty, and such failure is reported by Licensee to BalaSys within the Warranty Period, BalaSys's sole obligation and liability for breach of this warranty is, at BalaSys's sole option, either:
(i) to correct such failure,
(ii) to replace the defective BalaSys Product or
(iii) to refund the license fees paid by Licensee for the applicable BalaSys Product.
11.1. EXCEPT AS SET OUT IN THIS LICENSE CONTRACT, BALASYS MAKES NO WARRANTIES OF ANY KIND WITH RESPECT TO THE Proxedo Network Security Suite. TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, BALASYS EXCLUDES ANY OTHER WARRANTIES, INCLUDING BUT NOT LIMITED TO ANY IMPLIED WARRANTIES OF SATISFACTORY QUALITY, MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT OF INTELLECTUAL PROPERTY RIGHTS.
12.1. SOME STATES AND COUNTRIES, INCLUDING MEMBER COUNTRIES OF THE EUROPEAN UNION, DO NOT ALLOW THE LIMITATION OR EXCLUSION OF LIABILITY FOR INCIDENTAL OR CONSEQUENTIAL DAMAGES AND, THEREFORE, THE FOLLOWING LIMITATION OR EXCLUSION MAY NOT APPLY TO THIS LICENSE CONTRACT IN THOSE STATES AND COUNTRIES. TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW AND REGARDLESS OF WHETHER ANY REMEDY SET OUT IN THIS LICENSE CONTRACT FAILS OF ITS ESSENTIAL PURPOSE, IN NO EVENT SHALL BALASYS BE LIABLE TO LICENSEE FOR ANY SPECIAL, CONSEQUENTIAL, INDIRECT OR SIMILAR DAMAGES OR LOST PROFITS OR LOST DATA ARISING OUT OF THE USE OR INABILITY TO USE THE Proxedo Network Security Suite EVEN IF BALASYS HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
12.2. IN NO CASE SHALL BALASYS'S TOTAL LIABILITY UNDER THIS LICENSE CONTRACT EXCEED THE FEES PAID BY LICENSEE FOR THE Proxedo Network Security Suite LICENSED UNDER THIS LICENSE CONTRACT.
13.1. This License Contract shall come into effect on the date of signature of the Take Over Protocol by the duly authorized
representatives of the parties.
13.2. Licensee may terminate the License Contract at any time by written notice sent to BalaSys and by simultaneously destroying all copies of the Proxedo Network Security Suite licensed under this License Contract.
13.3. BalaSys may terminate this License Contract with immediate effect by written notice to Licensee, if Licensee is in material or persistent breach of the License Contract and either that breach is incapable of remedy or Licensee shall have failed to remedy that breach within 30 days after receiving written notice requiring it to remedy that breach.
14.1. Save as expressly provided in this License Contract, no amendment or variation of this License Contract shall be effective unless in writing and signed by a duly authorised representative of the parties to it.
15.1. The failure of a party to exercise or enforce any right under this License Contract shall not be deemed to be a waiver of that right nor operate to bar the exercise or enforcement of it at any time or times thereafter.
16.1. If any part of this License Contract becomes invalid, illegal or unenforceable, the parties shall in such an event negotiate in good faith in order to agree on the terms of a mutually satisfactory provision to be substituted for the invalid, illegal or unenforceable
provision which as nearly as possible validly gives effect to their intentions as expressed in this License Contract.
17.1. Any notice required to be given pursuant to this License Contract shall be in writing and shall be given by delivering the notice by hand, or by sending the same by prepaid first class post (airmail if to an address outside the country of posting) to the address of the relevant party set out in this License Contract or such other address as either party notifies to the other from time to time. Any notice given according to the above procedure shall be deemed to have been given at the time of delivery (if delivered by hand) and when received (if sent by post).
18.1. Headings are for convenience only and shall be ignored in interpreting this License Contract.
18.2. This License Contract and the rights granted in this License Contract may not be assigned, sublicensed or otherwise transferred in whole or in part by Licensee without BalaSys's prior written consent. This consent shall not be unreasonably withheld or delayed.
18.3. An independent third party auditor, reasonably acceptable to BalaSys and Licensee, may upon reasonable notice to Licensee and during normal business hours, but not more often than once each year, inspect Licensee's relevant records in order to confirm that usage of the Proxedo Network Security Suite complies with the terms and conditions of this License Contract. BalaSys shall bear the costs of such audit. All audits shall be subject to the reasonable safety and security policies and procedures of Licensee.
18.4. This License Contract constitutes the entire agreement between the parties with regard to the subject matter hereof. Any modification of this License Contract must be in writing and signed by both parties.
THE WORK (AS DEFINED BELOW) IS PROVIDED UNDER THE TERMS OF THIS CREATIVE COMMONS PUBLIC LICENSE ("CCPL" OR "LICENSE"). THE WORK IS PROTECTED BY COPYRIGHT AND/OR OTHER APPLICABLE LAW. ANY USE OF THE WORK OTHER THAN AS AUTHORIZED UNDER THIS LICENSE OR COPYRIGHT LAW IS PROHIBITED. BY EXERCISING ANY RIGHTS TO THE WORK PROVIDED HERE, YOU ACCEPT AND AGREE TO BE BOUND BY THE TERMS OF THIS LICENSE. TO THE EXTENT THIS LICENSE MAY BE CONSIDERED TO BE A CONTRACT, THE LICENSOR GRANTS YOU THE RIGHTS CONTAINED HERE IN CONSIDERATION OF YOUR ACCEPTANCE OF SUCH TERMS AND CONDITIONS.
Definitions
"Adaptation" means a work based upon the Work, or upon the Work and other pre-existing works, such as a translation, adaptation, derivative work, arrangement of music or other alterations of a literary or artistic work, or phonogram or performance and includes cinematographic adaptations or any other form in which the Work may be recast, transformed, or adapted including in any form recognizably derived from the original, except that a work that constitutes a Collection will not be considered an Adaptation for the purpose of this License. For the avoidance of doubt, where the Work is a musical work, performance or phonogram, the synchronization of the Work in timed-relation with a moving image ("synching") will be considered an Adaptation for the purpose of this License.
"Collection" means a collection of literary or artistic works, such as encyclopedias and anthologies, or performances, phonograms or broadcasts, or other works or subject matter other than works listed in Section 1(f) below, which, by reason of the selection and arrangement of their contents, constitute intellectual creations, in which the Work is included in its entirety in unmodified form along with one or more other contributions, each constituting separate and independent works in themselves, which together are assembled into a collective whole. A work that constitutes a Collection will not be considered an Adaptation (as defined above) for the purposes of this License.
"Distribute" means to make available to the public the original and copies of the Work through sale or other transfer of ownership.
"Licensor" means the individual, individuals, entity or entities that offer(s) the Work under the terms of this License.
"Original Author" means, in the case of a literary or artistic work, the individual, individuals, entity or entities who created the Work or if no individual or entity can be identified, the publisher; and in addition (i) in the case of a performance the actors, singers, musicians, dancers, and other persons who act, sing, deliver, declaim, play in, interpret or otherwise perform literary or artistic works or expressions of folklore; (ii) in the case of a phonogram the producer being the person or legal entity who first fixes the sounds of a performance or other sounds; and, (iii) in the case of broadcasts, the organization that transmits the broadcast.
"Work" means the literary and/or artistic work offered under the terms of this License including without limitation any production in the literary, scientific and artistic domain, whatever may be the mode or form of its expression including digital form, such as a book, pamphlet and other writing; a lecture, address, sermon or other work of the same nature; a dramatic or dramatico-musical work; a choreographic work or entertainment in dumb show; a musical composition with or without words; a cinematographic work to which are assimilated works expressed by a process analogous to cinematography; a work of drawing, painting, architecture, sculpture, engraving or lithography; a photographic work to which are assimilated works expressed by a process analogous to photography; a work of applied art; an illustration, map, plan, sketch or three-dimensional work relative to geography, topography, architecture or science; a performance; a broadcast; a phonogram; a compilation of data to the extent it is protected as a copyrightable work; or a work performed by a variety or circus performer to the extent it is not otherwise considered a literary or artistic work.
"You" means an individual or entity exercising rights under this License who has not previously violated the terms of this License with respect to the Work, or who has received express permission from the Licensor to exercise rights under this License despite a previous violation.
"Publicly Perform" means to perform public recitations of the Work and to communicate to the public those public recitations, by any means or process, including by wire or wireless means or public digital performances; to make available to the public Works in such a way that members of the public may access these Works from a place and at a place individually chosen by them; to perform the Work to the public by any means or process and the communication to the public of the performances of the Work, including by public digital performance; to broadcast and rebroadcast the Work by any means including signs, sounds or images.
"Reproduce" means to make copies of the Work by any means including without limitation by sound or visual recordings and the right of fixation and reproducing fixations of the Work, including storage of a protected performance or phonogram in digital form or other electronic medium.
Fair Dealing Rights. Nothing in this License is intended to reduce, limit, or restrict any uses free from copyright or rights arising from limitations or exceptions that are provided for in connection with the copyright protection under copyright law or other applicable laws.
License Grant. Subject to the terms and conditions of this License, Licensor hereby grants You a worldwide, royalty-free, non-exclusive, perpetual (for the duration of the applicable copyright) license to exercise the rights in the Work as stated below:
to Reproduce the Work, to incorporate the Work into one or more Collections, and to Reproduce the Work as incorporated in the Collections; and,
to Distribute and Publicly Perform the Work including as incorporated in Collections.
The above rights may be exercised in all media and formats whether now known or hereafter devised. The above rights include the right to make such modifications as are technically necessary to exercise the rights in other media and formats, but otherwise you have no rights to make Adaptations. Subject to 8(f), all rights not expressly granted by Licensor are hereby reserved, including but not limited to the rights set forth in Section 4(d).
Restrictions. The license granted in Section 3 above is expressly made subject to and limited by the following restrictions:
You may Distribute or Publicly Perform the Work only under the terms of this License. You must include a copy of, or the Uniform Resource Identifier (URI) for, this License with every copy of the Work You Distribute or Publicly Perform. You may not offer or impose any terms on the Work that restrict the terms of this License or the ability of the recipient of the Work to exercise the rights granted to that recipient under the terms of the License. You may not sublicense the Work. You must keep intact all notices that refer to this License and to the disclaimer of warranties with every copy of the Work You Distribute or Publicly Perform. When You Distribute or Publicly Perform the Work, You may not impose any effective technological measures on the Work that restrict the ability of a recipient of the Work from You to exercise the rights granted to that recipient under the terms of the License. This Section 4(a) applies to the Work as incorporated in a Collection, but this does not require the Collection apart from the Work itself to be made subject to the terms of this License. If You create a Collection, upon notice from any Licensor You must, to the extent practicable, remove from the Collection any credit as required by Section 4(c), as requested.
You may not exercise any of the rights granted to You in Section 3 above in any manner that is primarily intended for or directed toward commercial advantage or private monetary compensation. The exchange of the Work for other copyrighted works by means of digital file-sharing or otherwise shall not be considered to be intended for or directed toward commercial advantage or private monetary compensation, provided there is no payment of any monetary compensation in connection with the exchange of copyrighted works.
If You Distribute, or Publicly Perform the Work or Collections, You must, unless a request has been made pursuant to Section 4(a), keep intact all copyright notices for the Work and provide, reasonable to the medium or means You are utilizing: (i) the name of the Original Author (or pseudonym, if applicable) if supplied, and/or if the Original Author and/or Licensor designate another party or parties (for example a sponsor institute, publishing entity, journal) for attribution ("Attribution Parties") in Licensor's copyright notice, terms of service or by other reasonable means, the name of such party or parties; (ii) the title of the Work if supplied; (iii) to the extent reasonably practicable, the URI, if any, that Licensor specifies to be associated with the Work, unless such URI does not refer to the copyright notice or licensing information for the Work. The credit required by this Section 4(c) may be implemented in any reasonable manner; provided, however, that in the case of a Collection, at a minimum such credit will appear, if a credit for all contributing authors of Collection appears, then as part of these credits and in a manner at least as prominent as the credits for the other contributing authors. For the avoidance of doubt, You may only use the credit required by this Section for the purpose of attribution in the manner set out above and, by exercising Your rights under this License, You may not implicitly or explicitly assert or imply any connection with, sponsorship or endorsement by the Original Author, Licensor and/or Attribution Parties, as appropriate, of You or Your use of the Work, without the separate, express prior written permission of the Original Author, Licensor and/or Attribution Parties.
For the avoidance of doubt:
Non-waivable Compulsory License Schemes. In those jurisdictions in which the right to collect royalties through any statutory or compulsory licensing scheme cannot be waived, the Licensor reserves the exclusive right to collect such royalties for any exercise by You of the rights granted under this License;
Waivable Compulsory License Schemes. In those jurisdictions in which the right to collect royalties through any statutory or compulsory licensing scheme can be waived, the Licensor reserves the exclusive right to collect such royalties for any exercise by You of the rights granted under this License if Your exercise of such rights is for a purpose or use which is otherwise than noncommercial as permitted under Section 4(b) and otherwise waives the right to collect royalties through any statutory or compulsory licensing scheme; and,
Voluntary License Schemes. The Licensor reserves the right to collect royalties, whether individually or, in the event that the Licensor is a member of a collecting society that administers voluntary licensing schemes, via that society, from any exercise by You of the rights granted under this License that is for a purpose or use which is otherwise than noncommercial as permitted under Section 4(b).
Except as otherwise agreed in writing by the Licensor or as may be otherwise permitted by applicable law, if You Reproduce, Distribute or Publicly Perform the Work either by itself or as part of any Collections, You must not distort, mutilate, modify or take other derogatory action in relation to the Work which would be prejudicial to the Original Author's honor or reputation.
Representations, Warranties and Disclaimer UNLESS OTHERWISE MUTUALLY AGREED BY THE PARTIES IN WRITING, LICENSOR OFFERS THE WORK AS-IS AND MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND CONCERNING THE WORK, EXPRESS, IMPLIED, STATUTORY OR OTHERWISE, INCLUDING, WITHOUT LIMITATION, WARRANTIES OF TITLE, MERCHANTIBILITY, FITNESS FOR A PARTICULAR PURPOSE, NONINFRINGEMENT, OR THE ABSENCE OF LATENT OR OTHER DEFECTS, ACCURACY, OR THE PRESENCE OF ABSENCE OF ERRORS, WHETHER OR NOT DISCOVERABLE. SOME JURISDICTIONS DO NOT ALLOW THE EXCLUSION OF IMPLIED WARRANTIES, SO SUCH EXCLUSION MAY NOT APPLY TO YOU.
Limitation on Liability. EXCEPT TO THE EXTENT REQUIRED BY APPLICABLE LAW, IN NO EVENT WILL LICENSOR BE LIABLE TO YOU ON ANY LEGAL THEORY FOR ANY SPECIAL, INCIDENTAL, CONSEQUENTIAL, PUNITIVE OR EXEMPLARY DAMAGES ARISING OUT OF THIS LICENSE OR THE USE OF THE WORK, EVEN IF LICENSOR HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
Termination
This License and the rights granted hereunder will terminate automatically upon any breach by You of the terms of this License. Individuals or entities who have received Collections from You under this License, however, will not have their licenses terminated provided such individuals or entities remain in full compliance with those licenses. Sections 1, 2, 5, 6, 7, and 8 will survive any termination of this License.
Subject to the above terms and conditions, the license granted here is perpetual (for the duration of the applicable copyright in the Work). Notwithstanding the above, Licensor reserves the right to release the Work under different license terms or to stop distributing the Work at any time; provided, however that any such election will not serve to withdraw this License (or any other license that has been, or is required to be, granted under the terms of this License), and this License will continue in full force and effect unless terminated as stated above.
Miscellaneous
Each time You Distribute or Publicly Perform the Work or a Collection, the Licensor offers to the recipient a license to the Work on the same terms and conditions as the license granted to You under this License.
If any provision of this License is invalid or unenforceable under applicable law, it shall not affect the validity or enforceability of the remainder of the terms of this License, and without further action by the parties to this agreement, such provision shall be reformed to the minimum extent necessary to make such provision valid and enforceable.
No term or provision of this License shall be deemed waived and no breach consented to unless such waiver or consent shall be in writing and signed by the party to be charged with such waiver or consent.
This License constitutes the entire agreement between the parties with respect to the Work licensed here. There are no understandings, agreements or representations with respect to the Work not specified here. Licensor shall not be bound by any additional provisions that may appear in any communication from You. This License may not be modified without the mutual written agreement of the Licensor and You.
The rights granted under, and the subject matter referenced, in this License were drafted utilizing the terminology of the Berne Convention for the Protection of Literary and Artistic Works (as amended on September 28, 1979), the Rome Convention of 1961, the WIPO Copyright Treaty of 1996, the WIPO Performances and Phonograms Treaty of 1996 and the Universal Copyright Convention (as revised on July 24, 1971). These rights and subject matter take effect in the relevant jurisdiction in which the License terms are sought to be enforced according to the corresponding provisions of the implementation of those treaty provisions in the applicable national law. If the standard suite of rights granted under applicable copyright law includes additional rights not granted under this License, such additional rights are deemed to be included in the License; this License is not intended to restrict the license of any rights under applicable law.
© 2021 BalaSys IT Security.
Send your comments to: support@balasys.hu