The Github pphaal/acl_server project INSTALL page describes how to install the acl_server daemon and configure the NGINX web server front end for the Cumulus Linux REST API to include the acl_server functions. The integration ensures that the same access controls configured for the REST API apply to the acl_server functions, which appear under the /acl/ path.
The following examples demonstrate the REST API.
Create an ACL
curl -X PUT -H 'Content-Type:application/json' --data '["[iptables]","-A FORWARD --in-interface swp+ -d 10.10.100.10 -p udp --sport 53 -j DROP"]' -k -u 'cumulus:CumulusLinux!' https://10.0.0.52:8080/acl/ddos1ACLs are sent as a JSON encoded array of strings. Each string will be written as a line in a file stored under /etc/cumulus/acl/policy.d/ - See Cumulus Linux: Netfilter - ACLs. For example, the rule above will be written to the file 50rest-ddos1.rules with the following content:
[iptables] -A FORWARD --in-interface swp+ -d 10.10.100.10 -p udp --sport 53 -j DROPThis iptables rule blocks all traffic from UDP port 53 (DNS) to host 10.10.100.10. This is the type of rule that might be inserted to block a DNS amplification attack.
Retrieve an ACL
curl -k -u 'cumulus:CumulusLinux!' https://10.0.0.52:8080/acl/ddos1Returns the result:
[ "[iptables]", "-A FORWARD --in-interface swp+ -d 10.10.100.10 -p udp --sport 53 -j DROP" ]
List ACLs
curl -k -u 'cumulus:CumulusLinux!' https://10.0.0.52:8080/acl/Returns the result:
[ "ddos1" ]
Delete an ACL
curl -X DELETE -k -u 'cumulus:CumulusLinux!' https://10.0.0.52:8080/acl/ddos1
Delete all ACLs
curl -X DELETE -k -u 'cumulus:CumulusLinux!' https://10.0.0.52:8080/acl/Note: this doesn't delete all the ACLs, just the ones created using the REST API. All default ACLs or manually created ACLs are inaccessible through the REST API.
Errors
The acl_server batches and compiles changes after the HTTP requests complete. Batching has the benefit of increasing throughput and reducing request latency, but makes it difficult to track compilation errors since they are reported later. The acl_server catches the output and status when running cl-acltool and attaches an HTTP Warning header to subsequent responses to indicate that the last compilation failed:HTTP/1.1 200 OK Server: nginx/1.6.2 Date: Thu, 16 Nov 2017 21:38:03 GMT Content-Type: application/json Transfer-Encoding: chunked Connection: keep-alive Keep-Alive: timeout=300 Accept: application/json Warning: 199 - "check lasterror"The output of cl-acltool can be retrieved:
curl -k -u 'cumulus:CumulusLinux!' https://10.0.0.52:8080/acl/lasterrorReturns the result:
{"returncode": 255, "lines": [...]}
The REST API is intended to be used by automation systems and so syntax problems with the ACLs they generate should be rare and are the result of a software bug. A controller using this API should check responses for the presence of the last error Warning, log the lasterror information so that the problem can be debugged, and finally delete all the rules created through the REST API to restore the system to its default state.While this REST API could be used as a convenient way to manually push an ACL to a switch, the API is intended to be part of automation solutions that combine real-time traffic analytics with automated control. Cumulus Linux includes standard sFlow measurement support, delivering real-time network wide visibility to drive solutions that include: DDoS mitigation, enforcing black lists, marking large flows, ECMP load balancing, packet brokers etc.
The acl_server functionality demonstrates the value of the open Linux environment exposed by Cumulus Linux, making it easy to extend the platform using standard Linux tools in order to address operational requirements. Download the free Cumulus Linux VX virtual machine to try these examples yourself.
