Tuesday, 18 February 2020

[Solved] Snort: ERROR: Can't initialize DAQ pfring (-1) -

I came across this error after performing a regular system update on CentOS 7. Although it's a rather generic looking error message it turned out to be quite a trivial problem.

The pfring driver (provided by daq_pfring) had been compiled against the latest kernel version - however for whatever reason an older kernel was being loaded by default by the bootloader.

This can be evidenced by running:

uname -r

and a rpm -qa | grep kernel

To correct this issue:

grub2-set-default 0 # presuming menu item 0 is the kernel you want listed in: /boot/efi/EFI/centos/grub.cfg (which is usually the case.)

and then confirm with:

grub2-editenv list

Restart the machine and then check the kernel / test snort again:

shutdown -r now

sudo service snort status

Tuesday, 14 January 2020

Visualising data from iperf with rrd

The purpose of this test was to test the availability of bandwidth on a leased line while ensuring that the test itself didn't saturate the line.

We'll firstly run our iperf server in daemon mode:

iperf3 --server --daemon --logfile iperf_stdout.txt --pidfile iperf3.pid

Since this will be a long term test we'll ensure that there is no timeout on the test and that intervals of 1 second are reported (since we'll be using this for rrd input):

iperf3 -b 20M -c hlxscript01.hlx.int -i 1 -t 0 -V --logfile log.txt &

In the above example I'm sending a stream traffic equalling 20Mbits. If you wish to saturate the line you will need to remove this and also likely tweak with threads and the TCP window size in order to get optimum results.

Now in order to use our client log (log.txt) for use with rrd we'll need to extract the timestamp along with the recorded speed, feed it into the rrd file and finally generate the graph. I've created a simple shell script to do just that:


epoc=$(date "+%s")

iperf_results=( $(cat log.txt | grep -o '[0-9]\+\.[0-9]\+ Mbits\/sec' | cut -d " " -f 1) )

rrdtool create iperf.rrd --step=1 --start=$epoc-$results_count DS:ds1:GAUGE:1:U:U RRA:AVERAGE:0.5:1:$results_count

START=$(expr $epoc - $results_count)
for (( i = 0; i < ${COUNT}; i++ )); do
rrdtool update iperf.rrd ${START}:${VALUE}
START=$(expr ${START} + 1)

rrdtool graph iperf.png --start $epoc-$results_counts --end now DEF:ds1a=iperf.rrd:ds1:AVERAGE LINE1:ds1a#FF0000:"Sinus line"


Tuesday, 10 September 2019

Locking down ISAKMP / IPSec (UDP 500 , 4500 and IP 50) on the ASA 5500 Series

By default when enabling ISAKMP / IPSec on an interface the ASA permits access to the service (UDP 500, 4500 and IPSec) to everyone. However in some circumstances where you can reliably predict the source of VPN initiaitors you should ideally lock down access. Unfortuantely this can't be performed via apply an ACL to the interface and instead needs to be performed via the control pane.

We'll firstly need to obtain a list of the IP's in tunnel groups and add them to an ACL e.g.:

access-list outside-control-plane extended permit udp host <REMOTE PEER #1> host <ASA-VPN-ENABLED-INTERFACE> eq 500
access-list outside-control-plane extended permit udp host <REMOTE PEER #2> host <ASA-VPN-ENABLED-INTERFACE> eq 500
access-list outside-control-plane extended deny udp any any eq 500

access-list outside-control-plane extended permit udp host <REMOTE PEER #1> host <ASA-VPN-ENABLED-INTERFACE> eq 4500
access-list outside-control-plane extended permit udp host <REMOTE PEER #2> host <ASA-VPN-ENABLED-INTERFACE> eq 4500
access-list outside-control-plane extended deny udp any any eq 4500

access-list outside-control-plane extended permit ipsec host <REMOTE PEER #1> host <ASA-VPN-ENABLED-INTERFACE>
access-list outside-control-plane extended permit ipsec host <REMOTE PEER #2> host <ASA-VPN-ENABLED-INTERFACE>
access-list outside-control-plane extended deny ipsec any any

access-group outside-control-plane in interface outside-pri control-plane

Note: The above examples presume you do NOT have any IPSec VPN servers behind the firewall.

We can also perform the same for SSL VPNs:

access-list outside-control-plane extended permit tcp host <REMOTE PEER #1> host <ASA-VPN-ENABLED-INTERFACE> eq 443
access-list outside-control-plane extended permit tcp host <REMOTE PEER #2> host <ASA-VPN-ENABLED-INTERFACE> eq 443
access-list outside-control-plane extended deny tcp any <ASA-VPN-ENABLED-INTERFACE> eq 443

Thursday, 8 August 2019

Setting up bonding with LACP using the ip command in Linux

This can be accomplished quite quickly with the IP command if you only need it temporarily:

ip link add bond0 type bond
ip link set bond0 down
ip link set bond0 type bond mode 802.3ad
ip link set enp1s0 down
ip link set enp1s0 master bond0
ip link set enp2s0 down
ip link set enp2s0 master bond0
ip link set bond0 up

and to remove the bonding we can issue:

ip link del bond0
ip link set enp1s0 up
ip link set enp2s0 up

Quickstart: Installing Arch Linux 2019.X

Firstly download the latest iso image from one of the mirrors below:

wget https://www.mirrorservice.org/sites/ftp.archlinux.org/iso/2019.08.01/archlinux-xxxx.xx.xx-x86_64.iso
and then write it to your preferred media:
dd bs=8M if=archlinux-xxxx.xx.xx-x86_64.iso of=/dev/sdX | sync
Upon booting the image select the default selection to boot Arch.

This will get you into the system under the root user.

The setup portion is a Gentoo style approach of efffectively 'assembling' the system yourself.

From here we'll firstly partition the disks:
sdX               8:0    0 1000G  0 disk 

In this example we'll create three partitions - one for the root fs, another for our home fs and finally one for swap.
parted -a optimal /dev/sdXhyu
mktable gpt
mkpart ESP boot fat32 0% 500MB
mkpart root ext4 500MB 250000MB
mkpart home ext4 250GB 750GB
mkpart swap ext4 750GB 800GB
set 1 boot on
Create the filesystems with:
mkfs.msdos /dev/sdX1
mkfs.ext4 /dev/sdX2
mkfs.ext4 /dev/sdX3
mkfs.ext4 /dev/sdX4
mkswap /dev/sdX4
swapon /dev/sdX4
Proceed by mounting the file systems:
mount -t auto /dev/sdX2 /mnt
mkdir -P /mnt/boot/EFI && mount -t auto /dev/SdX1 /mnt/boot/EFI
mkdir /mnt/home && mount -t auto /dev/SdX3 /mnt/home
We'll need the network setup at this point so we can access the arch repo's:
and then pull down all the nessasery compontents for the root fs:
pacstrap /mnt base base-devel
Once complete we'll need to generate the fstab for the new system:
genfstab -U /mnt >> /mnt/etc/fstab
and then change our root password by chrooting into the new system along with the hostname:
arch-chroot /mnt
hostname arch-box
We'll also configure regional and time settings with:
ln -sf /usr/share/zoneinfo/<region>/<city> /etc/localtime
hwclock --systohc
printf "LANG=en_GB.UTF-8" > /etc/locale.conf
export LANG=en_GB.UTF-8
I'm going to use KDE Plasma for the desktop environment:
pacman -S xorg xorg-server xorg-xinit plasma-meta sddm
Finally we will configure grub:
pacman -S grub efibootmgr dosfstools os-prober mtools
grub-install --target=x86_64-efi --efi-directory=/boot/EFI --bootloader-id=grub_uefi --recheck
grub-mkconfig -o /boot/grub/grub.cfg
Exit the jail:
and restart:
shutdown -r now
Once booted into the new OS we'll setup the network configuration - for this example I'll be setting up DHCP.

With Arch we have a few options for network configuration - either netctl or networkd (a newer component.)
vi /etc/netctl/enp2s0
Description=LAN interface
Ensure the interface will come up on boot by issuing:
netctl enable enp2s0
Enable and start the DHCP service with:
systemctl enable dhcpcd
systemctl start dhcpcd
and then attempt to start the interface with:
netctl start enp2s0

Friday, 12 July 2019

Using Juniper SRX devices as routers

The SRX series are part of Junipers security line of products and provide firewall among a host of other security features such as IDS and IPS.

However you can effectively use the SRX range as a traditional router by changing the forwarding mode from flow based (stateful inspected) to packet based (stateless per packet inspection.)

You can verify the forwarding mode by issuing:

show security flow status

We should firstly ensure we remove any existing security configuration from the device with:

delete security

and then ensure the forwarding mode is set to 'packet based':

set security forwarding-options family mpls mode packet-based

commit it and then reboot:

run request system reboot

Upon restart check the forwarding mode again with:

show security flow status

Thursday, 4 July 2019

Configuring an Etherchannel (with LACP) between JunOS and Cisco IOS

Juniper JunOS

Firstly create the aggregated interface:

edit chassis
set aggregated-devices ethernet device-count 2

edit interfaces
set ae0 aggregated-ether-options

and define the LACP interval period (i.e. the rate at which the device will send / receive LACP protocol messages):

set aex aggregated-ether-options lacp periodic fast

By default the 'lacp periodic fast' sets the transmission rate to 1 second.

Note: It's important that the rate is matched on the other end as well.

We'll now associate our interfaces with the aggregated link we've just configured:

edit interfaces
edit ge-0/0/1
set ether-options 802.3ad ae0
edit ge-0/0/2
set ether-options 802.3ad ae0

Cisco IOS

conf t
int range gi1/0/1-2
channel-protocol lacp
channel-group 1 mode active
lacp rate fast
no shut

int po1
description etherchannel