Dressing Up Your Scripts With GUI Elements
I’m working on another “weekend” project that has been bubbling for a long time. I use the Sucuri Web Application Firewall (WAF) on all my sites. The primary purpose of a WAF is to block bad requests which is great, but is has the side effect of making traffic analysis difficult because website logs are in two different places. The “good” requests make it to my web server and are in my access logs. The “bad” requests that are blocked by the WAF obviously don’t make it through to my server access logs. While Sucuri offers System Information and Event Management (SIEM) integration for enterprise customers, regular customers have to make API calls to pull event data, called “audit trails”, from the WAF Application Programming Interface (API).
I am building a little script named Tiny SIEM to handle those audit trails and provide some rudimentary analysis for us regular folks.
I am not a developer. I am a sysadmin that builds discreet, small tools to achieve a single task. I always favour simplicity and ease of development over the user experience because the users of my tools are always higly technical. Except when they’re not.
Sucuri WAF customers are not always highly technical. Technical people would have no problem configuring and using Tiny SIEM, but I’m looking to make it slightly easier. I emphasize the word “slightly” – it’s still going to be a script because my mission in life is to replace everything with a small shell script – and it’s still going to assume it is running on a Linux box because that’s my world view.
I know from experience that non-technical users are going to mess up the configuration if they have to type manual entries into a config file. To address this, I am using YAD to display GUI dialog boxes in my script to collect the data Tiny SIEM needs to do its job. This allows me to prompt for the specific information I want, and to validate that input much easier than making users write whatever they want into the config file.
What is YAD?
YAD is “Yet Another Dialogue” application written by Victor Ananajevsky in 2016 [SourceForge code repo link]. The last commit was 2017 so it’s no longer in development, but for my purposes it doesn’t need to be. It’s able to do everything I want and because my use-case is single user, local mode, I don’t see a situation where a critical security update would be needed. YAD is availble in the Ubuntu software repositories and I suspect other repos as well. It requires the GTK libraries so if you’re already running Gnome it will be a small install using something like:
sudo apt install yad
The “Yet Another…” naming convention is popular with code authors who are developing their own way of doing something that has been done before. Other applications that can provide graphical dialogue boxes in scripts are Zenity, Dialog, Whiptail and probably others.
Using YAD
There are tons of YAD usage examples here, so I won’t go into too much detail in this post. What I am more interested in is how to parse and validate the input. Let’s go back to my dialogue box image above and populate it with some data.
I use this data to populate a configuration file. When Tiny SIEM launches, it looks around to see if it has been configured yet. One of the things it looks for is an existing configuration file. Tiny SIEM needs my Sucuri API credentials to grab the audit trails, and it needs to know the domain these credentials belong to in order to properly name the audit trail files that it will download. I collect that info in a YAD box and, after doing some basic validation, I write it to the conf file.
$ cat tinysiem.conf DOMAIN=linkcho.mp APIKEY=MYAPIKEY APISECRET=API_SECRET
The next time Tiny SIEM runs, it will recognize that it has been configured and it will not prompt for this information. Future iterations of Tiny SIEM will likely support multiple domains, but you have to start somewhere.
YAD uses the pipe symbol | as a field delimeter which is sort of odd, but it works well enough for my purposes because I don’t expect to encounter any legitiate pipes in the data I am collecting from users. I use simple and widely availble tools like awk to write this data to the configuration file.
# Display the YAD window
res=yad --title="" --text="Please enter your Sucuri info:" --form --field="Sucuri API Key" --field="Sucuri API Secret" --field="Domain name"
# Validate data here....
# Write to configuration file echo $res |awk -F| '{print “DOMAIN=”$3}' >> tinysiem.conf echo $res |awk -F| '{print “APIKEY=“$1}' >> tinysiem.conf echo $res |awk -F| '{print “APISECRET=“$2}' >> tinysiem.conf
Regardless of whether it prompts for initial configuration data or not, Tiny SIEM will them move on to prompting for the date range of audit trails to download and analyze. YAD provides a nice date dialogue box complete with picker.
yad —title=“” —text=“Select date range of audit trails to collect:” —form —field=“Start Date”:DT —field “End Date”:DT
My selections are returned in the same type of pipe-delimeted format when the dialogue closes.
2020-05-01|2020-05-27|
I now have everything I need to make the API call to Sucuri to get the WAF audit trails for my linkcho.mp domain. The next part of the script will be a little harder because the API does not allow me to say “give me all the audit trails from May 1st to May 27th”. I can only get one day at a time so I will need to loop through the days between the start and end dates which can get complicated if the date range spans months or even years. There is also the case where there may be no audit trails for a specified date, perhaps because the user picked a start date prior to deploying the Sucuri WAF.
Those are all problems for another day, however. This post was to get your started with YAD and the concept of using graphical dialogue boxes in scripts.
Happy prompting!
my shorter content on the fediverse: https://the.mayhem.academy/@jdw