In short:

1. Protection of services and opening of ports by knocking cryptographically stable and non-replicable Single Packet Authorization (SPA) with fwknop 2.6.9+ .
2. Dynamically customizable blacklist update with All Cybercrime IP Feeds by FireHOL .
3. Full ipset support in cfnetwork .
4. Support your own black lists.
5. Typical applications.

Thematic cycle:

• Part I: network and network filter (cfnetwork + cffirehol)
• Part II: Access and Standard Environment (cfauth + cfsystem)
• Part III: Install Puppet Server (cfpuppetserver)
• Part IV: Centralized Management (cftotalcontrol)
• Part V: Databases (cfdb)
• Part VI: Topical Blacklists and Secure Knock

Use in a working environment in various applications imposes more and more specific requirements for setting up a network filter, which requires an appropriate solution.

Port-knocking or opening access through port knocking

Purpose

Any publicly available service is a priori subject to hacking or simply denial of service due to limited connection handling resources. The most typical example is SSHd, which quite easily lends itself to DoS with access failures for the administrator. VPN is not a panacea and he gets up to attack.

The most effective way is to restrict access at the network level to outgoing addresses, but this is far from always possible: access on the road, dynamic addresses, temporary employees, etc.

Story

By some references, the topic became more prominent in 2003 by Martin Krzywinski. Initially, in the late 90s, a mechanism for sending packages in a certain sequence in a limited time interval was created for the dynamic opening of access, just like in action films with a secret knock on the door. On the server side there were various options for implementing the processing of such packets and opening access. Such a mechanism has all the flaws of a common password transmitted in the open form, and should be anathematized as telnet and rsh, although in some cases temporary passwords and some hashing are supported.

A number of implementation options are listed on www.portknocking.org .

Subsequently, they still thought of attracting full-fledged cryptography in order to protect against eavesdropping, playback, data substitution and support for individual users. Using secret keys to sign a message and synchronize time with a tolerance, it is possible to reliably send commands in one packet. The first public references of "Single Packet Authorization" (hereinafter referred to as SPA) go to the July BlackHat gathering in 2005.

fwknop - FireWall KNock OPerator

The first release of the project was in 2004 and it is still supported. Standard packages are present in various distributions. The initial approach was to listen for pcap traffic, which is somewhat doubtful. Further, many features were wound up, right up to the remote launch of commands, a la poor man's ssh.

Of course, even despite the quality audit of the code, all the bells and whistles cause concern for use, especially with super-user rights. However, the support of many users and the support of the SPA are serious advantages.

Only in 2014, the "UDP server" mode was added in v2.6.4 without the need for pcap, and at the end of 2015, v2.6.8 added support for running abstract commands for opening and closing access instead of direct shredding of the network filter. These two features allowed to remove some of the concerns for the application.

Integration of fwknop with the cffirehol module

The fwknop service fwknop configured and started with limited privileges and resources for greater security. With successful authentication, it is allowed only to add the necessary address to the lists prepared in advance ( ipset discussed later), and after the time has expired, delete them.

1. We generate secret keys on the client:

 $ server="my_new_host"; \ fwknop --key-gen --key-gen-file ~/.ssh/fwknop_id_${server}; \ cat ~/.ssh/fwknop_id_${server} [+] Wrote Rijndael and HMAC keys to: .../.ssh/fwknop_id_my_new_host KEY_BASE64: WB8/Hh9imafehfoJC/+XF5a2gOuK3zVvGnPVG6ELtLc= HMAC_KEY_BASE64: AuWdYzJ5MSgrM3gbELS9YyhUYLUW5jqlIRson2MhKn0ZL/5AdSSTbJnrgb5Rqhe1cs4nYFJIeBJzKG5FAqBaMg== 

2. Add users

 #   fwknop cffirehol::fwknop::enable: true #   ,   cffirehol::fwknop::port: 62201 #   cffirehol::knockers: portable: timeout: 3600 key_b64: 'WB8/Hh9imafehfoJC/+XF5a2gOuK3zVvGnPVG6ELtLc=' hmac_key_b64: 'AuWdYzJ5MSgrM3gbELS9YyhUYLUW5jqlIRson2MhKn0ZL/5AdSSTbJnrgb5Rqhe1cs4nYFJIeBJzKG5FAqBaMg==' home: timeout: 43200 ipset: - cfauth_admin - other_purpose key_b64: '<OTHER KEY>' hmac_key_b64: '<OTHET_HMAC_KEY>' 

3. Deploy puppet on server

 $ sudo /opt/puppetlabs/bin/puppet agent --test 

4. Create a fwknop client configuration file.

It requires fwknop-client 2.6.4+ with support for "UDP server", which is available in Debian 9+ and Ubuntu 17+, and for all other .deb systems, builds with LaunchPad should come up - they are used in the module.

 [default] WGET_CMD /usr/bin/wget SPA_SERVER_PROTO udp USE_HMAC Y HMAC_DIGEST_TYPE sha256 RESOLVE_IP_HTTPS Y # just a placeholder for SPA format ACCESS tcp/1 [my_new_host] SPA_SERVER 128.1.2.3 SPA_SERVER_PORT 62201 SPOOF_USER portable KEY_BASE64 WB8/Hh9imafehfoJC/+XF5a2gOuK3zVvGnPVG6ELtLc= HMAC_KEY_BASE64 AuWdYzJ5MSgrM3gbELS9YyhUYLUW5jqlIRson2MhKn0ZL/5AdSSTbJnrgb5Rqhe1cs4nYFJIeBJzKG5FAqBaMg== 

Attention: there is no colon in the file format, as in the file from the first item.

5. We test opening access

 fwknop -n my_new_host 

Note

• Usually, the .ssh folder in your home directory is one of the most protected places. Therefore used for example.
• Do not make global settings for cffirehol::knockers to avoid information leaks to all systems in Puppet directories.
• For each node, the user must have separate keys from the banal considerations of managing symmetric keys.
• Immediately, two keys are used to sign the message and to encrypt it, although this may seem somewhat redundant.
• Depending on the type of device and conditions of use, you should select the appropriate time interval for opening access.
• It is intended to be used in conjunction with the cfauth module — therefore, the cfauth_admin list is used by default, but it is acceptable to use others.
• The server requires an explicit IP address, without relying on the UDP packet header.

Black lists

It is hardly necessary to explain the meaning of the term, but one should not forget that there is always an opportunity to replay oneself and one should definitely have a higher priority white list.

Secondly, it is not necessary to prescribe the addresses in the form of individual network filter rules. This is ineffective. To solve this problem in Linux, there is support for IP sets as part of the netfilter project (also known as iptables).

Global lists of unwanted addresses

On the Internet there are many paid and open lists of constantly updated addresses of different quality. One of the great unifying projects is All Cybercrime IP Feeds by FireHOL .

Note that it will be frivolous to throw all possible lists. Some may be of extremely dubious quality or very subjective: for example, Internet troll addresses.

Own blacklists

Such lists are compiled both manually and automatically based on the results of the work of intrusion detection systems (IDS). The well-known fail2ban example. In "manual mode" address lists can be taken from databases with blocked users, etc.

Support for IP lists in the cfnetwork module

A new type of cfnetwork::ipset and the concept of partial configuration were added, when at the deployment stage many lists with a single prefix are combined into one. Example:

• vpn_access - the main definition of the list and its parameters. This name is used for reference.
• vpn_access:hardcoded , vpn_access:static - or any other name can be set in the configuration or other modules.
• vpn_access-net4 vpn_access-net6 - this will be the actual list name created for the IPv4 and IPv6 family, respectively

Lists can be dynamic - the configuration of the network filter assumes that they will change in real time. Network filter rules with dynamic lists are added to all possible interfaces. Otherwise, more intelligently - only on interfaces where they make sense, based on the content.

In all port configurations, where it is possible to specify the IP address or host name, it is also possible to refer to the named list with the prefix "ipset:".

Lists may include other lists, but this only makes sense for predefined addresses. Example:

 cfnetwork::ipsets: locations: addr: - '128.1.2.3' - 'somehost.example.com' - "2001:db8::/32" puppet_access: addr: 'ipset:locations' vpn_access: addr: - 'ipset:locations' - 'ipset:cfauth_admin' 'whitelist:static': addr: - 'trusted.example.com' cfnetwork::service_ports: 'main:puppet': src: 'ipset:puppet_access' 

Note: cfauth_admin automatically added to whitelist .

Support for current blacklists in the cffirehol module

The FireHOL blacklist project has its own update-ipsets tool that allows you to update lists with age verification, manipulate them and update them in the kernel. Despite this, working with such complex super-user operations seemed dangerous. Therefore, all list preparation takes place under an unprivileged user, and saving and updating in the kernel is already done by its own means.

To optimize storage and processing, some false positives may be tolerated. For example, instead of scattered IP addresses, aggregation into one record by a prefix with a customizable factor can occur, and records that are meaningless, covered with more general ones, are simply deleted with the iprange tool.

The parameters cffirehol::dynblacklist::blacklists4 and cffirehol::dynblacklist::blacklists6 - allow you to select named lists. The default is the recommended firehol-level1 with the least number of false positives.

The cffirehol::dynblacklist::addon_ipsets allows you to add your own list configuration for update-ipsets .
In the extreme case, there are cffirehol::dynblacklist::custom_* to get your own black lists more flexibly.

Minimal to enable current blacklists is enough:

 cffirehol::dynblacklist::enable: true 

What we have in the end

Firstly, for the purpose of convenient administration, the cfnetwork functionality has been expanded , which allows combining work with IPv4 and IPv6 addresses without any problems. In addition, inherited lists are supported, the concept of which is absent in lower level tools. This allows you to logically divide addresses into groups without unnecessary duplication.

Secondly, an additional lightweight level of service protection has been introduced. First of all, it allows you to close such "heavy" services as SSH and VPN from unwanted connections. This approach is also used for access to the development environment by freelancers with a personal key for each.

Thirdly, dynamic constantly updated black lists are now supported both from global centralized resources and from own sources.