It has been a while since the last post about Ansible network automation, and today let’s change that. In this post, we are going to look at how to verify if a Cisco IOS-based device has a login banner and the correct one is set. Originally, I did not want to cover Ansible playbooks that a Network Configuration Management (NCM) software can perform. However, since there are a lot of organizations that do not have NCM, I figured I should include it anyway in case folks are interested in learning.
This post contains affiliate links, which means I may earn a commission if you click through and make a purchase. This comes at no additional cost to you. Full disclosure here.
Is setting a login banner important? I am not a legal expert, so I am not going to try to answer that from a legal standpoint. However, I do want to point out that a lot of security guides out there recommend that you configure it. For example, CIS IOS Benchmark, NSA Network Infrastructure Security Guide, and Cisco IOS XE Hardening Guide.
The Ansible playbook
The playbook is pretty straightforward. Essentially, it checks if the device(s) has a login banner configured or not. If it does not have a login banner, our playbook will set it. When the device has a login banner configured, it will check if it is the same as what is in the playbook. If it matches, then it will leave it alone. If it does not match, then our playbook will set the correct banner.
Breaking it down
To help those folks who are new to Ansible, I will break down each section of the playbook.
---
- name: Configure Login Banner on Cisco IOS
hosts: MYSW
gather_facts: noThe playbook begins by specifying its name, followed by the host or group of hosts to run the playbook against. In this case, MYSW is actually the name of the variable I set in the group_vars/MYSW.yml directory. This file also contains necessary information, like username, password, connection plugin, etc.
The following line tells Ansible not to gather facts about the hosts before running the playbook. Facts are information about the hosts, such as their operating system, IP address, etc.
Note
Since this is a lab environment, I am using plaintext. In production, you would want to use Ansible Vault.
---
# Default Connectivity Variables
# This is group_vars/MYSW.yml file
ansible_user: andrew
ansible_ssh_pass: My_Password_Here
ansible_network_os: ios
ansible_connection: network_cli
ansible_become: yes
ansible_become_method: enable
ansible_become_password: My_Enable_Password_Here
ansible_ssh_common_args: '-F cisco.cfg'Task
In this one and only task, we are using the cisco.ios.ios_banner module to apply our banner. If your organization does not have one yet, you might want to involve your legal department to come up with one.
tasks:
- name: Apply login banner
cisco.ios.ios_banner:
banner: login
text: |
*******************************************************************
* *
* * * * NETWORKJUTSU * * * *
* * * * WARNING NOTICE: * * * *
* *
* This system is restricted solely to NetworkJutsu authorized *
* users for legitimate business purposes only. The actual *
* or attempted unauthorized access, use, or modification of *
* this system is strictly prohibited by NetworkJutsu. *
* Unauthorized users are subject to disciplinary *
* proceedings and/or criminal and civil penalties under *
* state, federal, or other domestic foreign laws. The *
* use of this system may be monitored and recorded for *
* administrative and security reasons. Anyone accessing *
* this system expressly consents to such monitoring and *
* is advised that if monitoring reveals possible evidence *
* of criminal activity, NetworkJutsu may provide evidence *
* of such activity to law enforcement officials. All *
* users must comply with NetworkJutsu instructions *
* regarding the protection of NetworkJutsu information assets. *
* *
*******************************************************************
state: present
notify: Save configurationThe task begins by specifying the name. This serves as a description for the task so you know what is happening.
Followed by the module that knows how to manage banners on Cisco IOS devices. You can read the Cisco module here.
The next line specifies which banner type we want to configure. In this case, we specified the login type, which appears immediately after successfully initiating an SSH connection to a Cisco IOS device.
Followed by the text parameter. This is where we put the desired banner. The pipe ( | ) is YAML syntax meaning “keep this as a multi-line block, preserving line breaks.”
Want to learn more about Ansible?
Learn how to automate using Ansible
The next line declares the desired end state. Since it is set to present, then the banner should exist. If the banner already matches, it will do nothing. If the banner is not configured, Ansible will configure it.
Followed by the notify keyword, which is a handler trigger. If this task changes anything, it notifies a handler, which is defined in the next section, named “Save configuration,” to run at the end.
Handler
A handler is a special task that only runs when triggered by the notify keyword. Think of it as a “run this later, but only if needed” instruction. Handlers wait until all regular tasks finish, then execute once, even if notified multiple times.
handlers:
- name: Save configuration
cisco.ios.ios_command:
commands: write memoryThe handler begins by specifying the name. This serves as a description for the handler. The name must exactly match the string in the task’s notify. That’s the link connecting them. If they don’t match, the handler will not be triggered.
Followed by the module, which is named cisco.ios.ios_command. This module runs raw operational commands on the device. You can read the Cisco module here.
The next line is the actual command sent to the Cisco IOS device. In this case, we are saving the running configuration to startup configuration.
Running the playbook
Now we are ready to run the playbook against the host or group of hosts. In this case, it is calling a group, but the group only has one device. We are going to run the playbook three times, but with different scenarios to demonstrate how it behaves.
No login banner configured
Let’s log into the switch and display the running configuration.
SW1#sh run | i banner login
SW1#Now let’s run the playbook and see what happens.
andrew@ansible:~$ ansible-playbook banner.yml
PLAY [Configure Login Banner on Cisco IOS] **********************************************************************************************************************************************
TASK [Apply login banner] ***************************************************************************************************************************************************************
changed: [SW1]
RUNNING HANDLER [Save configuration] ****************************************************************************************************************************************************
ok: [SW1]
PLAY RECAP ******************************************************************************************************************************************************************************
SW1 : ok=2 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0According to the output, the task has a changed status. As the status implies, Ansible changed the configuration since it does not have the login banner configured.
Verification
Let’s go back to the switch and display the configuration.
SW1#sh run | b banner login
banner login ^C
*******************************************************************
* *
* * * * NETWORKJUTSU * * * *
* * * * WARNING NOTICE: * * * *
* *
* This system is restricted solely to NetworkJutsu authorized *
* users for legitimate business purposes only. The actual *
* or attempted unauthorized access, use, or modification of *
* this system is strictly prohibited by NetworkJutsu. *
* Unauthorized users are subject to disciplinary *
* proceedings and/or criminal and civil penalties under *
* state, federal, or other domestic foreign laws. The *
* use of this system may be monitored and recorded for *
* administrative and security reasons. Anyone accessing *
* this system expressly consents to such monitoring and *
* is advised that if monitoring reveals possible evidence *
* of criminal activity, NetworkJutsu may provide evidence *
* of such activity to law enforcement officials. All *
* users must comply with NetworkJutsu instructions *
* regarding the protection of NetworkJutsu information assets. *
* *
*******************************************************************
^C
<-- Output omitted for brevity -->Wrong login banner configured
In this scenario, we configured the switch with a test login banner, as you can see below.
SW1#sh run | b banner login
banner login ^C
TEST BANNER
^C
<-- Output omitted for brevity -->Now let’s run the playbook and see what happens.
andrew@ansible:~$ ansible-playbook banner.yml
PLAY [Configure Login Banner on Cisco IOS] **********************************************************************************************************************************************
TASK [Apply login banner] ***************************************************************************************************************************************************************
changed: [SW1]
RUNNING HANDLER [Save configuration] ****************************************************************************************************************************************************
ok: [SW1]
PLAY RECAP ******************************************************************************************************************************************************************************
SW1 : ok=2 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 As expected, the output is the same as our previous test.
Verification
Let’s go back to the switch and display the configuration.
SW1#sh run | b banner login
banner login ^C
*******************************************************************
* *
* * * * NETWORKJUTSU * * * *
* * * * WARNING NOTICE: * * * *
* *
* This system is restricted solely to NetworkJutsu authorized *
* users for legitimate business purposes only. The actual *
* or attempted unauthorized access, use, or modification of *
* this system is strictly prohibited by NetworkJutsu. *
* Unauthorized users are subject to disciplinary *
* proceedings and/or criminal and civil penalties under *
* state, federal, or other domestic foreign laws. The *
* use of this system may be monitored and recorded for *
* administrative and security reasons. Anyone accessing *
* this system expressly consents to such monitoring and *
* is advised that if monitoring reveals possible evidence *
* of criminal activity, NetworkJutsu may provide evidence *
* of such activity to law enforcement officials. All *
* users must comply with NetworkJutsu instructions *
* regarding the protection of NetworkJutsu information assets. *
* *
*******************************************************************
^C
<-- Output omitted for brevity -->Correct login banner configured
In this last scenario, we left the switch alone and just reran the playbook.
andrew@ansible:~$ ansible-playbook banner.yml
PLAY [Configure Login Banner on Cisco IOS] **********************************************************************************************************************************************
TASK [Apply login banner] ***************************************************************************************************************************************************************
ok: [SW1]
PLAY RECAP ******************************************************************************************************************************************************************************
SW1 : ok=1 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 The output differs from the first and second run because Ansible did not change the switch’s configuration this time. In the task section, the task status (or task result) shows ok instead of changed. Notice, too, that the handler output is absent. Since there was no change, the task did not notify the handler, so it never triggered. This is idempotency in action. Running the same playbook repeatedly yields the same result without making redundant changes.
Final words
With a single playbook, we applied a login banner to a Cisco IOS switch (or group of hosts), saved the configuration through a handler, and most importantly, did it all idempotently.
The key takeaway? Ansible describes the desired state rather than a list of commands. This is the declarative nature of Ansible. Run the playbook once, and it makes the change. Run it again, and Ansible recognizes everything already matches, so it does nothing. No unnecessary saves.
Give it a try in your own lab and see idempotency in action. Happy automating!
Disclosure
AndrewRoderos.com is a participant of a few referral programs, an affiliate advertising program designed to provide a means for sites to earn advertising fees by advertising and linking to company websites.
BUY ME COFFEE
Did you find this content useful?
If so, show your appreciation by buying me a coffee!
