Increase Ubuntu VM Disk Space

I ran into a very familiar problem (for me anyway) on an Ubuntu 18 virtual machine today. It started with, what I thought was, a Cisco ISE issue. Cisco ISE reports that I wanted to write to a repository ended up as empty files (0 bytes). Initial thought was that I ran into an Cisco ISE bug related to repositories, but it turned out that my Ubuntu server had run out of disk space;

Err:2 http://archive.ubuntu.com/ubuntu bionic-updates InRelease
  Error writing to output file - write (28: No space left on device) [IP: 91.189.88.24 80]

A quick df -h revealed that my Ubuntu server had only 4GB (out of the 100GB I assigned in VMWare).

willem@ubuntu:~$ df -h
Filesystem                         Size  Used Avail Use% Mounted on
udev                               967M     0  967M   0% /dev
tmpfs                              200M  1.1M  199M   1% /run
/dev/mapper/ubuntu--vg-ubuntu--lv  3.9G  3.9G    0M 100% /
tmpfs                              997M     0  997M   0% /dev/shm
tmpfs                              5.0M     0  5.0M   0% /run/lock
tmpfs                              997M     0  997M   0% /sys/fs/cgroup
/dev/loop0                          90M   90M     0 100% /snap/core/7713
/dev/loop1                          90M   90M     0 100% /snap/core/7917
/dev/sda2                          976M  222M  688M  25% /boot
tmpfs                              200M     0  200M   0% /run/user/1000
ubuntuvm-disk-size.png

So, now I had to add the unassigned 96GB to the Ubuntu filesystem. Thankfully, askubuntu to the rescue.

root@ubuntu:~# lvm
lvm> lvextend -l +100%FREE /dev/mapper/ubuntu--vg-ubuntu--lv
  Size of logical volume ubuntu-vg/ubuntu-lv changed from 4.00 GiB (1024 extents) to <99.00 GiB (25343 extents).
  Logical volume ubuntu-vg/ubuntu-lv successfully resized.
lvm> exit
  Exiting.
root@ubuntu:~# resize2fs /dev/mapper/ubuntu--vg-ubuntu--lv
resize2fs 1.44.1 (24-Mar-2018)
Filesystem at /dev/mapper/ubuntu--vg-ubuntu--lv is mounted on /; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 13
The filesystem on /dev/mapper/ubuntu--vg-ubuntu--lv is now 25951232 (4k) blocks long.

root@ubuntu:~# df -h
Filesystem                         Size  Used Avail Use% Mounted on
udev                               967M     0  967M   0% /dev
tmpfs                              200M  1.1M  199M   1% /run
/dev/mapper/ubuntu--vg-ubuntu--lv   98G  3.4G   91G   4% /
tmpfs                              997M     0  997M   0% /dev/shm
tmpfs                              5.0M     0  5.0M   0% /run/lock
tmpfs                              997M     0  997M   0% /sys/fs/cgroup
/dev/loop0                          90M   90M     0 100% /snap/core/7713
/dev/loop1                          90M   90M     0 100% /snap/core/7917
/dev/sda2                          976M  222M  688M  25% /boot
tmpfs                              200M     0  200M   0% /run/user/1000
root@ubuntu:~# 
Posted on October 16, 2019 and filed under Linux, Tips'n Tricks.

Cisco ISE v2.6 and Google ChromeOS

While playing around with the new Cisco Identity Service Engine (ISE) v2.6 (patch2) I stumbled upon a security feature while testing Wireless 802.1x access with an Acer Chromebook (ChromeOS v75.0.3770.144). When connecting to the 802.1x enabled SSID the connection failed, while other devices (Windows 10, Apple iOS and MacOS) connected just fine.

The problem is the client EAP handshake and usually this relates to untrusted server certificates. This happens to me a lot since I use different RADIUS services for my testing SSID’s.
So after clearing the SSID settings (forget) on the Chromebook it should work, but it didn’t.

The logging showed that the EAP handshake failed because the client didn’t offer a suitable cipher to the ISE server.

Turns out that Cisco ISE v2.6 has SHA1 disabled by default, and you need to enable it in:

Administration -> System -> Settings -> Security Settings

With the setting ‘Allow SHA1 Ciphers’, and ‘Allow only TLS_RSA_WITH_AES_128_CBC_SHA’ the Chromebook was able to connect to the 802.1x enabled SSID using old/depricated ciphers.

Now I wonder why the Chromebook still uses SHA1 based ciphers for secure communications, since Google Chrome started to abandon SHA1 as one of the first browsers….

Even installing the ‘Powerwash for added security’ feature in ChromeOS didn’t enable or add stronger ciphers on the Chromebook.

Posted on July 31, 2019 and filed under Tips'n Tricks, Security.

Update Python Netaddr OUI Database

For a small project I needed to validate ~1500 MAC addresses on validity and their vendor Organizational Unique Identifier id (OUI). So a bit of Python scripting was in order.

I used a regular expression for basic MAC address validation, and the netaddr module to check the OUI of the MAC Address. A simple example of the code is shown below

#!/usr/bin/env python3

import netaddr as na
import re

_mac = '88-E9-FE-1F-65-7D'
if re.match('[0-9a-f]{2}([-:]?)[0-9a-f]{2}(\\1[0-9a-f]{2}){4}$', _mac.lower()):
    print(f'{_mac} - {na.EUI(_mac).oui.registration().org}')

Checking this MAC address online gives a normal result.

macvendors.png

Python (or specifically netaddr) not so much, so there some work to be done. The error clearly shows that the OUI for that MAC address is not registered (in netaddr’s local database).

netaddr-error.png

The problem is that the OUI ‘database’ from netaddr is (extremely) out-dated, so recently assigned OUI’s are not available, and result in Python script errors.

Unfortunatelly, the netaddr documentation doesn’t give any hint on how to update this database. Some searching on the local filesystem showed that there is a oui.txt file within the directory structure of netaddr (which in my case can be seen in the error shown above).

The latest oui.txt (~0.5MB larger than the netaddr version) can be downloaded @ IEEE (the organization were hardware vendors can request new OUI’s). The file location is: http://standards-oui.ieee.org/oui.txt.
I downloaded the file and replaced the original netaddr version. Running the code again gave no solution, since I got the same error. So back to the drawing board.

In the same directory as the oui.txt is a file called oui.idx. This file contains the decimal value of the OUI, and an offset. It turns out that the netaddr codeused this idx file to quickly skip to the actual vendor information in the oui.txt file. And since my idx file was based on the old oui.txt the vendor could still not be found.

The idx file cannot be found on the internet. It’s not something IEEE provides. It’s a file generated from the information in the oui.txt file.

Solution: In the netaddr directory where the oui.txt and oui.idx is located is a ieee.py script. Run that script, and it creates a new idx file based on the oui.txt file in that directory (as shown in the following example).

myhost:eui myname$ pwd
/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/netaddr/eui
myhost:eui myname$ ls -la
total 12856
drwxr-xr-x   9 myname  admin      288 Jan 26 13:37 .
drwxr-xr-x  11 myname  admin      352 Jan 26 13:37 ..
-rw-r--r--   1 myname  admin    24990 Jan 26 13:37 __init__.py
drwxr-xr-x   4 myname  admin      128 Jan 26 13:37 __pycache__
-rw-r--r--   1 myname  admin    95467 Jan 26 13:37 iab.idx
-rw-r--r--   1 myname  admin  2453271 Jan 26 13:37 iab.txt
-rw-r--r--   1 myname  admin     9500 Jan 26 13:37 ieee.py
-rw-r--r--   1 myname  admin   419098 Jan 26 13:37 oui.idx
-rw-r--r--   1 myname  admin  3566144 Jan 26 13:37 oui.txt

myhost:eui myname$ curl http://standards-oui.ieee.org/oui.txt --output oui.txt
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 4039k  100 4039k    0     0   370k      0  0:00:10  0:00:10 --:--:--  437k

myhost:eui myname$ python3 ieee.py 
myhost:eui myname$ ls -la
total 14336
drwxr-xr-x   9 myname  admin      288 Jan 26 13:37 .
drwxr-xr-x  11 myname  admin      352 Jan 26 13:37 ..
-rw-r--r--   1 myname  admin    24990 Jan 26 13:37 __init__.py
drwxr-xr-x   4 myname  admin      128 Jan 26 13:37 __pycache__
-rw-r--r--   1 myname  admin    95467 May 10 12:14 iab.idx
-rw-r--r--   1 myname  admin  2453271 Jan 26 13:37 iab.txt
-rw-r--r--   1 myname  admin     9500 Jan 26 13:37 ieee.py
-rw-r--r--   1 myname  admin   485973 May 10 12:14 oui.idx
-rw-r--r--   1 myname  admin  4136058 May 10 12:14 oui.txt
myhost:eui myname$ 

After that the output of my script was the following:

/usr/local/bin/python3.7 /Volumes/Python_Scripts/test.py
88-E9-FE-1F-65-7D - Apple, Inc.

Process finished with exit code 0
Posted on May 10, 2019 and filed under Programming, Annoying.

Install Cisco Identity Services Engine v2.4 From USB

The Cisco Identity Service Engine (ISE) is a NAC solution used for accessing the network. The version (while writing this post) is v2.4.

For a new implementation of Cisco ISE I had to re-image 2 SNS-3595 appliances with the latest software. This can be done in various ways;

  1. Write the ISE iso to USB and boot / install from the USB flash-drive

  2. Use the JAVA/HTML5 KVM option through the CICM interface

  3. Hookup a USB DVD player with a dual-layer DVD containing the appropriate ISO file

The preferred option is the USB flash-drive, since it’s the fastest, but only if you are able to boot from USB….. After trying several USB flash drives with the tool recommended in the Cisco manual I gave up. No way that the Boot menu saw the USB flash drive. So after wasting several hours doing that I opted for the KVM install method.

Waking Up inside a Camera Obscura

This weekend I woke up inside an actual camera obscura. Our (hotel) bedroom had Velux roof window which was minimally opened. The tiny openings on the lower side of the window projected the neighboring scenery on our (white) bedroom walls.

Camera Obscura Scene (stitch of multiple photos)

The smaller the hole, the sharper the projected image is. You can even see the beer crates in front of the neighboring house.

Rotated photo showing the beer crates

Rotated photo showing the beer crates

All photos were taken handheld from the bed at ISO30.000 (or higher), so there is wee bit of noise. The photos also show the bed, door-handle and a radiator in the room.

Posted on July 9, 2018 and filed under Personal, Photography.

Juniper SRX, Virtual Routers, and SNMPv3

In this continuing story about Junos and virtual routers an episode about SNMPv3.

A simple SNMPv3 config for Junos would be the following:

set snmp v3 usm local-engine user authpriv authentication-md5 authentication-password My_Password_01
set snmp v3 usm local-engine user authpriv privacy-aes128 privacy-password My_Password_02
set snmp v3 vacm security-to-group security-model usm security-name v3test group v3test
set snmp v3 vacm security-to-group security-model usm security-name authpriv group v3test
set snmp v3 vacm access group v3test default-context-prefix security-model any security-level authentication read-view v3testview
set snmp v3 vacm access group v3test default-context-prefix security-model any security-level authentication write-view v3testview
set snmp v3 vacm access group v3test default-context-prefix security-model any security-level authentication notify-view v3testview
set snmp v3 vacm access group v3test default-context-prefix security-model any security-level privacy read-view v3testview
set snmp v3 vacm access group v3test default-context-prefix security-model any security-level privacy write-view v3testview
set snmp v3 vacm access group v3test default-context-prefix security-model any security-level privacy notify-view v3testview
set snmp v3 snmp-community v3test security-name v3test
set snmp view v3testview oid system include
set snmp view v3testview oid .1 include

Authenticating with the correct credentials (U: authpriv, P: My_Password_01) will give results in a single (default) virtual router.

Using this config in a multiple VR environment will result in Authentication and/or authorization errors. Reason being the not using the root/single VR configuration.

Adding some details to the config, AND altering the actual SNMPv3 query will solve that.

set snmp v3 usm local-engine user authpriv authentication-md5 authentication-password My_Password_01
set snmp v3 usm local-engine user authpriv privacy-aes128 privacy-password My_Password_02
set snmp v3 vacm security-to-group security-model usm security-name authpriv group v3test
set snmp v3 vacm access group v3test context-prefix DEFAULT security-model any security-level authentication read-view v3testview
set snmp v3 vacm access group v3test context-prefix DEFAULT security-model any security-level authentication write-view v3testview
set snmp v3 vacm access group v3test context-prefix DEFAULT security-model any security-level authentication notify-view v3testview
set snmp v3 vacm access group v3test context-prefix DEFAULT security-model any security-level privacy read-view v3testview
set snmp v3 vacm access group v3test context-prefix DEFAULT security-model any security-level privacy write-view v3testview
set snmp v3 vacm access group v3test context-prefix DEFAULT security-model any security-level privacy notify-view v3testview
set snmp v3 snmp-community v3test security-name v3test
set snmp view v3testview oid system include
set snmp view v3testview oid .1 include
set snmp routing-instance-access access-list DEFAULT

The main differences are:

  • context-prefix <VR-NAME>
  • snmp routing-instant-access access-list <VR-NAME>

Having done that, AND adding a context parameter to the actual query will give the correct results.

Posted on June 27, 2018 and filed under Junos, Security, Tips'n Tricks.

Juniper SRX, Routing Instances, and Syslog Challenges

In the previous post I described the issue I had with routing instances and DHCP-relay, and how I fixed it. It turns out that DHCP-relay wasn't my only problem. Turns out that syslog also stopped at the time I implemented the routing instances.

Syslog-gap

To solve this I needed to inject the route to my syslog server (Splunk) in the global routing instance by using policy options.

set policy-options policy-statement syslog-policy term 10 from instance DEFAULT
set policy-options policy-statement syslog-policy term 10 from route-filter 192.168.20.0/24 exact
set policy-options policy-statement syslog-policy term 10 then accept
set policy-options policy-statement syslog-policy then reject

set routing-options instance-import syslog-policy
Posted on June 25, 2018 and filed under Annoying, Security, Tips'n Tricks.

Juniper SRX, Virtual Routers and DHCP Relay

A couple of weeks ago, I started to implement virtual routers in my SRX300. The reason being a new external subnet that  needed to route to a specific security zone. Using the default VR only wouldn't work because of the (single) default route.

Implementing it was fairly easy. The trouble began this week;

  • Wireless controller not accessible
  • Client with weird behaviour
  • etc.

In my network, I have 1 DHCP server serving multiple internal subnets. The (basic) DHCP relay configuration was:

set forwarding-options dhcp-relay maximum-hop-count 10
set forwarding-options dhcp-relay client-response-ttl 10
set forwarding-options dhcp-relay server-group DHCP_Server 192.168.x.x
set forwarding-options dhcp-relay active-server-group DHCP_Server
set forwarding-options dhcp-relay group clients active-server-group DHCP_Server
set forwarding-options dhcp-relay group clients interface ge-0/0/0.1
set forwarding-options dhcp-relay group clients interface ge-0/0/0.20
set forwarding-options dhcp-relay group clients interface ge-0/0/0.30
set forwarding-options dhcp-relay group clients interface ge-0/0/0.200

Turns out that this stops to function when implementing Virtual Routers. Something I forgot to adjust. And since the DHCP scope on my server was set to a lease-time of 14 days.... That means that problems tend to introduce themselves after a couple of days.....

Anyway, after changing the DHCP relay configuration to include the correct Virtual Router name (DEFAULT) everything worked just fine.

set routing-instances DEFAULT forwarding-options dhcp-relay maximum-hop-count 10
set routing-instances DEFAULT forwarding-options dhcp-relay client-response-ttl 10
set routing-instances DEFAULT forwarding-options dhcp-relay server-group DHCP_Server 192.168.x.x
set routing-instances DEFAULT forwarding-options dhcp-relay active-server-group DHCP_Server
set routing-instances DEFAULT forwarding-options dhcp-relay group clients active-server-group DHCP_Server
set routing-instances DEFAULT forwarding-options dhcp-relay group clients interface ge-0/0/0.1
set routing-instances DEFAULT forwarding-options dhcp-relay group clients interface ge-0/0/0.20
set routing-instances DEFAULT forwarding-options dhcp-relay group clients interface ge-0/0/0.30
set routing-instances DEFAULT forwarding-options dhcp-relay group clients interface ge-0/0/0.200

So. DHCP is a bit like DNS. Both have timers (TTL and lease-time) that might bite you in the butt.

Posted on June 10, 2018 and filed under Annoying, Junos, Security.

Juniper vSRX Firewall and VMWare Workstation 14

For a work related project, I wanted to run the Juniper vSRX firewall (v15.1X49-D110) on my work laptop by using VMWare Workstation Pro 14. Unfortunately, the installation (importing the Juniper vSRX OVA file resulted in a VMWare Workstation crash.