iRules LX Sideband Connection
Problem this snippet solves: Sideband connections in traditional TCL iRules can be large, complex and difficult to support. Additionally doing something with the information retrieved (such as JSON) may require the use of regular expressions to parse the content before it can be used, something to be avoided if at all possible due to the performance overhead. Using the inbuilt capabilities of Node.js, sideband calls in iRules LX are much easier to implement and with a range of inbuilt as well as NPM packages, the possibilities are endless. To make the external request, the example uses 'https' package from the standard library, however many more are available via NPM such as 'request' which is much simpler to use and doesn't need to chuck the response. The advantage of using the standard library in this instance is this can be done 'out of the box' and doesn't require the use of NPM. In this simple example, a traditional iRule requests the object 'title', which is a JSON object from a publicly available API (https://jsonplaceholder.typicode.com/). { "userId": 1, "id": 1, "title": "delectus aut autem", "completed": false } iRules LX will, make the call using the standard 'https' library, parse the JSON data and return the value for 'title' to the calling iRule, which will be then returned to the user as an HTTP response How to use this snippet: Add the following iRule to yout iRules LX Workspace. This will make an RPC call to iRules LX, using the plugin 'ilx_pl' and the extension 'ilx_ext' You can however call this what you like providing your update the ILX::init command to reflect this. when HTTP_REQUEST { # pass argument to ILX in form of a requested JSON object: # {"userId": 1,"id": 1,"title": "delectus aut autem","completed": false} set arg title set ilx_handle [ILX::init "ilx_pl" "ilx_ext"] if {[catch {ILX::call $ilx_handle "httpRequest" $arg} result]} { log local0.error "Client - [IP::client_addr], ILX failure: $result" HTTP::respond 400 content "<html>There has been an error.</html>" return } HTTP::respond 200 content $result log local0. "retrieved parsed JSON value for $arg: $result" } Use the iRules LX code below for the index.js file, within your workspace Code : var https = require("https"); var f5 = require("f5-nodejs"); var ilx = new f5.ILXServer(); function httpRequest (req, res) { https.get('https://jsonplaceholder.typicode.com/todos/1', function (resp) { var data = ''; // A chunk of data has been recieved. resp.on('data', function (chunk) { data += chunk; }); // The whole response has been received. Parse JSON resp.on('end', function () { res.reply(JSON.parse(data).title); }); }).on("error", function (err) { console.log("Error: " + err.message); }); } ilx.addMethod('httpRequest', httpRequest); ilx.listen(); Tested this on version: 12.1
/stats returning JSON nested objects instead of array?
I noticed that requesting a list of virtuals returns a JSON array, while the stats for the same collection returns nested objects. Is this intentional? https://hostname/mgmt/tm/ltm/virtual << returns JSON array https://hostname/mgmt/tm/ltm/virtual/stats << returns JSON nested objects ` Details (tweaked to protect the innocent): `https://hostname/mgmt/tm/ltm/virtual?$select=destination,name { "kind": "tm:ltm:virtual:virtualcollectionstate", "selfLink": "https://localhost/mgmt/tm/ltm/virtual?$select=destination%2Cname&ver=12.1.2", "items": [ { "name": "vs_vlan1", "destination": "/Common/10.15.15.0:0" }, { "name": "vs_vlan2", "destination": "/Common/any:0" } ] } The above output stores the virtuals (and its details) in an array. However, /stats changes that to nested objects: https://hostname/mgmt/tm/ltm/virtual/stats?$select=destination,tmName { "kind": "tm:ltm:virtual:virtualcollectionstats", "selfLink": "https://localhost/mgmt/tm/ltm/virtual/stats?$select=destination%2Cname%2CtmName&ver=12.1.2", "entries": { "https://localhost/mgmt/tm/ltm/virtual/~Common~vs_vlan1/stats": { "nestedStats": { "entries": { "destination": { "description": "10.15.15.0:any" }, "tmName": { "description": "/Common/vs_vlan1" } } } }, "https://localhost/mgmt/tm/ltm/virtual/~Common~vs_vlan2/stats": { "nestedStats": { "entries": { "destination": { "description": "any:any" }, "tmName": { "description": "/Common/vs_vlan2" } } } } } }Working with iControl REST Data on the Command Line
I'm still pretty entrenched in "old school" iControl with the soap interface, but with Colin's new series on the iControl REST interface underway, I thought I'd start taking more than a glance. While Colin's sed-fu in his latest article is impressive, I want to see the json data returned from iControl REST calls parsed properly (no offense, Colin!) This can be done with any number of bash, perl, python, and more tools, but I ran across one on twitter last night that is somewhat magical. jq is a single binary you can download and it just works. So why bother? Well, as Colin pointed out, the returned json data (by default) is none too fabulous in format: But with jq, you get nice pretty text with field callouts (jq .): But wait! There's more! You can also narrow the selection to the fields you want (jq '{ name, apiAnonymous }'): If you want to pull all the rules together, but still only return the name and code, just index by item (jq '.items[] | { name, partition, apiAnonymous }'):How to still get alerts from an allowed JSON profile?
I have a configuration similar to below in ASM v12, and would like to be able to still get an alert when the exact attack signature would be met: /allowed/url.html with header based JSON profile "allow SQL signature X" This "SQL signature X" is in blocking for the rest of the site, but I would still like to get an alert if it is seen on the /allowed/url.html Is it possible for that to happen, or since it is in the allowed url in the JSON profile is that not an option? Thanks!
