\documentclass[a4paper,11pt,notitlepage]{report}
% Henrik Lund Kramshoej, February 2001
% hlk@security6.net,
% My standard packages
\usepackage{zencurity-network-exercises}

\begin{document}

\rm
\selectlanguage{english}

\newcommand{\emne}[1]{Core Infrastructure and BGP Intro workshop}
\newcommand{\kursus}[1]{Core Infrastructure and BGP Intro workshop}
\newcommand{\kursusnavn}[1]{Core Infrastructure and BGP Intro workshop\\ exercises}

\mytitle{Core Infrastructure and BGP Intro}{exercises}


{\bf\LARGE The main exercise is the exercise \ref{ex:vlans-routing-rpf} on page \pageref{ex:vlans-routing-rpf}}

The exercises requires your team to have a Debian 9 installed as described in exercise \ref{ex:basicDebianVM}

The ones before are introducing a lot of tools that may help in debugging networks. Feel free to jump around. \smiley

\pagenumbering{roman}


\setcounter{tocdepth}{0}

\normal

{\color{titlecolor}\tableofcontents}
%\listoffigures - not used
%\listoftables - not used

\normal
\pagestyle{fancyplain}
\chapter*{\color{titlecolor}Preface}
\markboth{Preface}{}

This material is prepared for use in \emph{\kursus} and was prepared by
Henrik Lund Kramshoej, \link{http://www.zencurity.com} .
It describes the networking setup and
applications for trainings and workshops where hands-on exercises are needed.

\vskip 1cm
Further a presentation is used which is available as PDF from kramse@Github\\
Look for \jobname in the repo security-courses.

These exercises are expected to be performed in a training setting with network connected systems. The exercises use a number of tools which can be copied and reused after training. A lot is described about setting up your workstation in the repo

\link{https://github.com/kramse/kramse-labs}



\section*{\color{titlecolor}Prerequisites}

This material expect that participants have a working knowledge of
TCP/IP from a user perspective. Basic concepts such as web site addresses and email should be known as well as IP-addresses and common protocols like DHCP.

\vskip 1cm
Have fun and learn
\eject

% =================== body of the document ===============
% Arabic page numbers
\pagenumbering{arabic}
\rhead{\fancyplain{}{\bf \chaptername\ \thechapter}}

% Main chapters
%---------------------------------------------------------------------
% gennemgang af emnet
% check questions


\chapter*{\color{titlecolor}Introduction to networking}
%\markboth{Introduktion til netværk}{}
\label{chap:intro}

\section*{\color{titlecolor}IP - Internet protocol suite}

It is extremely important to have a working knowledge about IP to implement
secure and robust infrastructures. Knowing about the alternatives while doing
implementation will allow the selection of the best features.

\section*{\color{titlecolor}ISO/OSI reference model}
A very famous model used for describing networking is the ISO/OSI model
of networking which describes layering of network protocols in stacks.

This model divides the problem of communicating into layers which can
then solve the problem as smaller individual problems and the solution
later combined to provide networking.

Having layering has proven also in real life to be helpful, for instance
replacing older hardware technologies with new and more efficient technologies
without changing the upper layers.

In the picture the OSI reference model is shown along side with
the Internet Protocol suite model which can also be considered to have different layers.


\begin{figure}[H]
\label{fig:osi}
\begin{center}
\colorbox{white}{\includegraphics[width=8cm,angle=90]{images/compare-osi-ip.pdf}}
\end{center}
\caption{OSI og Internet Protocol suite}
\end{figure}


\chapter*{\color{titlecolor}Exercise content}
\markboth{Exercise content}{}

Most exercises follow the same procedure and has the following content:
\begin{itemize}
\item {\bf Objective:} What is the exercise about, the objective
\item {\bf Purpose:} What is to be the expected outcome and goal of doing this exercise
\item {\bf Suggested method:} suggest a way to get started
\item {\bf Hints:} one or more hints and tips or even description how to
do the actual exercises
\item {\bf Solution:} one possible solution is specified
\item {\bf Discussion:} Further things to note about the exercises, things to remember and discuss
\end{itemize}

Please note that the method and contents are similar to real life scenarios and does not detail every step of doing the exercises. Entering commands directly from a book only teaches typing, while the exercises are designed to help you become able to learn and actually research solutions.


\chapter{Bonus: Download Kali Linux Revealed (KLR) Book 10 min}
\label{ex:downloadKLR}


\hlkimage{3cm}{kali-linux-revealed.jpg}

\emph{Kali Linux Revealed  Mastering the Penetration Testing Distribution}


{\bf Objective:}\\
We need a Kali Linux for running tools during the course. This is open source, and the developers have released a whole book about running Kali Linux.

This is named Kali Linux Revealed (KLR)

{\bf Purpose:}\\
We need to install Kali Linux in a few moments, so better have the instructions ready.

{\bf Suggested method:}\\
Create folders for educational materials. Go to \link{https://www.kali.org/download-kali-linux-revealed-book/}
Read and follow the instructions for downloading the book.

{\bf Solution:}\\
When you have a directory structure for download for this course, and the book KLR in PDF you are done.

{\bf Discussion:}\\
Linux is free and everywhere. The tools we will run in this course are made for Unix, so they run great on Linux.

Kali Linux is a free pentesting platform, and probably worth more than \$10.000

The book KLR is free, but you can buy/donate, and I recommend it.

\chapter{Bonus: Check your Kali VM, run Kali Linux 30 min}
\label{ex:basicVM}

\hlkimage{10cm}{kali-linux.png}

{\bf Objective:}\\
Make sure your virtual machine is in working order.

We need a Kali Linux for running tools during the course.

{\bf Purpose:}\\
If your VM is not installed and updated we will run into trouble later.

{\bf Suggested method:}\\
Go to \link{https://github.com/kramse/kramse-labs/}

Read the instructions for the setup of a Kali VM.

{\bf Hints:}\\
If you allocate enough memory and disk you wont have problems.

{\bf Solution:}\\
When you have a updated virtualisation software and Kali Linux, then we are good.

{\bf Discussion:}\\
Linux is free and everywhere. The tools we will run in this course are made for Unix, so they run great on Linux.

Kali Linux includes many hacker tools and should be known by anyone working in infosec.




\chapter{Bonus: Wireshark and Tcpdump 15 min}
\label{ex:wireshark-install}

\hlkimage{10cm}{wireshark-http.png}


{\bf Objective:}\\
Try the program Wireshark locally your workstation, or tcpdump

You can run Wireshark on your host too, if you want.

{\bf Purpose:}\\
Installing Wireshark will allow you to analyse packets and protocols

Tcpdump is a feature included in many operating systems and devices to allow packet capture and saving network traffic into files.

{\bf Suggested method:}\\
Run Wireshark or tcpdump from your Kali Linux

The PPA book page 41 describes Your First Packet Capture.

{\bf Hints:}\\
PCAP is a packet capture library allowing you to read packets from the network.
Tcpdump uses libpcap library to read packet from the network cards and save them.
Wireshark is a graphical application to allow you to browse through traffic, packets and protocols.

Both tools are already on your Kali Linux, or do: \verb+apt-get install tcpdump wireshark+

{\bf Solution:}\\
When Wireshark is installed sniff some packets. We will be working with both live traffic and saved packets from files in this course.

If you want to capture packets as a non-root user on Debian, then use the command to add a Wireshark group:
\begin{alltt}
sudo dpkg-reconfigure wireshark-common
\end{alltt}

and add your user to this:
\begin{alltt}
sudo gpasswd -a $USER wireshark
\end{alltt}
Dont forget to logout/login to pick up this new group.

{\bf Discussion:}\\
Wireshark is just an example other packet analyzers exist, some commercial and some open source like Wireshark

We can download a lot of packet traces from around the internet, we might use examples from\\
\link{https://www.bro.org/community/traces.html}

\chapter{Bonus: Capturing TCP Session packets 10 min}
\label{ex:wireshark-capture}

\hlkimage{8cm}{tcp-three-way.pdf}


{\bf Objective:}\\
Sniff TCP packets and dissect them using Wireshark

{\bf Purpose:}\\
See real network traffic, also know that a lot of information is available and not encrypted.

Note the three way handshake between hosts running TCP. You can either use a browser or command line tools like cURL while capturing

\begin{alltt}
curl http://www.zencurity.com
\end{alltt}

{\bf Suggested method:}\\
Open Wireshark and start a capture\\
Then in another window execute the ping program while sniffing

or perform a Telnet connection while capturing data

{\bf Hints:}\\
When running on Linux the network cards are usually named eth0 for the first Ethernet and wlan0 for the first Wireless network card. In Windows the names of the network cards are long and if you cannot see which cards to use then try them one by one.

{\bf Solution:}\\
When you have collected some TCP sessions you are done.

{\bf Discussion:}
Is it ethical to collect packets from an open wireless network?

Also note the TTL values in packets from different operating systems

\chapter{Bonus: Using ping and traceroute 10 min}
\label{ex:ping}

{\bf Objective:}\\
Be able to do initial debugging of network problems using commands ping and traceroute

{\bf Purpose:}\\
Being able to verify connectivity is a basic skill.

{\bf Suggested method:}\\
Use \verb+ping+ and \verb+traceroute+ to test your network connection - can be done one Windows and UNIX.

{\bf Hints:}
\begin{alltt}
$ ping 10.0.42.1
PING 10.0.42.1 (10.0.42.1) 56(84) bytes of data.
64 bytes from 10.0.42.1: icmp_seq=1 ttl=62 time=1.02 ms
64 bytes from 10.0.42.1: icmp_seq=2 ttl=62 time=0.998 ms
^C
--- 10.0.42.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.998/1.012/1.027/0.034 ms
\end{alltt}

Dont forget that UNIX ping continues by default, press ctrl-c to break.

Do the same with traceroute.

{\bf Solution:}\\
Run both programs to local gateway and some internet address by your own choice.

{\bf Discussion:}\\
Note the tool is called tracert on Windows, shortened for some reason.

ICMP is the Internet Control Message Protocol, usually used for errors like host unreachable. The ECHO request ICMP message is the only ICMP message that generates another.

The traceroute programs send packets with low Time To Live (TTL) and receives ICMP messages, unless there is a problem or a firewall/filter. Also used for mapping networks.

{\bf Bonus:}

Whats the difference between:
\begin{list2}
\item {\bfseries traceroute} and {\bfseries traceroute -I}
\item NB: traceroute -I is found on UNIX - traceroute using ICMP pakker
\item Windows tracert by default uses ICMP
\item Unix by default uses UDP, but can use ICMP instead.
\item Lots of traceroute-like programs exist for tracing with TCP or other protocols
\end{list2}



\chapter{Bonus: DNS and Name Lookups 10 min}
\label{ex:basic-dns-lookup}



{\bf Objective:}\\
Be able to do DNS lookups from specific DNS server

{\bf Purpose:}\\
Try doing DNS lookup using different programs

{\bf Suggested method:}\\
Try the following programs:
\begin{itemize}
\item nslookup - UNIX and Windows, but not recommended\\
\verb+nslookup -q=txt -class=CHAOS version.bind. 0+
\item dig - syntax @server domain query-type query-class\\
\verb+dig @8.8.8.8 www.example.com+
\item host - syntaks host [-l] [-v] [-w] [-r] [-d] [-t querytype] [-a] host [server]\\
\verb+host www.example.com 8.8.8.8+
\end{itemize}

{\bf Hints:}\\
Dig is the one used by most DNS admins, I often prefer the host command for the short output.

{\bf Solution:}\\
Shown inline, above.

{\bf Discussion:}\\
The nslookup program does not use the same method for lookup as the standard lookup libraries, results may differ from what applications see.

What is a zone transfer, can you get one using the host command?

Explain forward and reverse DNS lookup.



\chapter{Bonus: Zeek on the web 10min}
\label{ex:zeekweb}


{\bf Objective:} \\
Try Zeek Network Security Monitor - without installing it.


{\bf Purpose:}\\
Show a couple of examples of Zeek scripting, the built-in language found in Zeek Network Security Monitor


{\bf Suggested method:}\\
Go to \link{http://try.bro.org/} and try a few of the examples.

{\bf Hints:}\\
The exercise
\emph{The Summary Statistics Framework} can be run with a specifc PCAP.

\verb+192.168.1.201 did 402 total and 2 unique  requests in the last 6 hours.+

{\bf Solution:}\\
You should read the example \emph{Raising a Notice}. Getting output for certain events may be interesting to you.


{\bf Discussion:}\\
Zeek Network Security Monitor is an old/mature tool, but can still be hard to get started using. I would suggest that you always start out using the packages available in your Ubuntu/Debian package repositories.

They work, and will give a first impression of Zeek. If you later want specific features not configured into the binary packet, then install from source.

Also Zeek uses a broctl program to start/stop the tool, and a few config files which we should look at. From a Debian system they can be found in \verb+/etc/bro+ :

\begin{alltt}
root@NMS-VM:/etc/bro# ls -la
drwxr-xr-x   3 root root  4096 Oct  8 08:36 .
drwxr-xr-x 138 root root 12288 Oct  8 08:36 ..
-rw-r--r--   1 root root  2606 Oct 30  2015 broctl.cfg
-rw-r--r--   1 root root   225 Oct 30  2015 networks.cfg
-rw-r--r--   1 root root   644 Oct 30  2015 node.cfg
drwxr-xr-x   2 root root  4096 Oct  8 08:35 site
\end{alltt}

\chapter{Bonus: Zeek DNS capturing domain names 10min}
\label{ex:zeekdnsbasic}


{\bf Objective:} \\
We will now start using Zeek on our systems.


{\bf Purpose:}\\
Try Zeek with example traffic, and see what happens.


{\bf Suggested method packet capture file:}\\
Note: a dollar sign is the Linux prompt, showing the command after
\begin{alltt}\small
$ cd
$ wget http://downloads.digitalcorpora.org/corpora/network-packet-dumps/2008-nitroba/nitroba.pcap
$ mkdir $HOME/bro;cd $HOME/bro; bro -r ../nitroba.pcap
... bro reads the packets
~/bro$ ls
conn.log  dns.log  dpd.log  files.log  http.log  packet_filter.log
sip.log  ssl.log  weird.log  x509.log
$ less *
\end{alltt}

Use :n to jump to the next file in less, go through all of them.

{\bf Suggested method Live traffic:}\\
Make sure Zeek is configured as a standalone probe and configured for the right interface. Linux used to use eth0 as the first ethernet interface, but now can use others, like ens192 or enx00249b1b2991.

\begin{alltt}
root@NMS-VM:/etc/bro# cat node.cfg
# Example BroControl node configuration.
#
# This example has a standalone node ready to go except for possibly changing
# the sniffing interface.

# This is a complete standalone configuration.  Most likely you will
# only need to change the interface.
[bro]
type=standalone
host=localhost
interface=eth0
...
\end{alltt}


{\bf Hints:}\\
There are multiple commands for showing the interfaces and IP addresses on Linux. The old way is using \verb+ifconfig -a+ newer systems would use \verb+ip a+

Note: if your system has a dedicated interface for capturing, you need to turn it on, make it available. This can be done manually using \verb+ifconfig eth0 up+
{\bf Solution:}\\
When you either run Zeek using a packet capture or using live traffic

Running with a capture can be done using a command line such as:
\verb+bro -r traffic.pcap+

Using broctl to start it would be like this:
\begin{alltt}\small
// install bro first
kunoichi:~ root# broctl
Hint: Run the broctl "deploy" command to get started.

Welcome to BroControl 1.5
Type "help" for help.

[BroControl] > install
creating policy directories ...
installing site policies ...
generating standalone-layout.bro ...
generating local-networks.bro ...
generating broctl-config.bro ...
generating broctl-config.sh ...
...
\end{alltt}

\begin{alltt}\small
// back to Broctl and start it
[BroControl] > start
starting bro
// and then
kunoichi:bro root# cd /var/spool/bro/bro
kunoichi:bro root# tail -f dns.log
\end{alltt}

You should be able to spot entries like this:
\begin{alltt}\small
#fields ts      uid     id.orig_h       id.orig_p       id.resp_h       id.resp_p       proto   trans_id        rtt
     query   qclass  qclass_name     qtype   qtype_name      rcode   rcode_name      AA      TC      RD      RA      Z       answers TTLs    rejected
1538982372.416180	CD12Dc1SpQm42QW4G3	10.xxx.0.145	57476	10.x.y.141	53	udp	20383	0.045021	www.dr.dk	1	C_INTERNET	1	A	0	NOERROR	F	F	T	T	0	www.dr.dk-v1.edgekey.net,e16198.b.akamaiedge.net,2.17.212.93	60.000000,20409.000000,20.000000	F
\end{alltt}

Note: this show ALL the fields captured and dissected by Zeek, there is a nice utility program bro-cut which can select specific fields:

\begin{alltt}\small
root@NMS-VM:/var/spool/bro/bro# cat dns.log | bro-cut -d ts query answers | grep dr.dk
2018-10-08T09:06:12+0200	www.dr.dk	www.dr.dk-v1.edgekey.net,e16198.b.akamaiedge.net,2.17.212.93
\end{alltt}

{\bf Discussion:}\\
Why is DNS interesting?


\chapter{Bonus: Zeek TLS capturing certificates 10min}
\label{ex:zeektlsbasic}


{\bf Objective:} \\
Run more traffic through Zeek, see the various files.


{\bf Purpose:}\\
See that even though HTTPS and TLS traffic is encrypted it often show names and other values from the certificates and servers.


{\bf Suggested method:}\\
Run Zeek capturing live traffic, start https towards some sites. A lot of common sites today has shifted to HTTPS/TLS.


{\bf Hints:}\\
use broctl start and watch the output directory

\begin{alltt}\small
root@NMS-VM:/var/spool/bro/bro# ls *.log
communication.log  dhcp.log files.log known_services.log packet_filter.log  stats.log
stdout.log x509.log conn.log dns.log known_hosts.log loaded_scripts.log  ssl.log
stderr.log weird.log
\end{alltt}

We already looked at \verb+dns.log+, now check \verb+ssl.log+ and \verb+x509.log+

\begin{alltt}\small
root@NMS-VM:/var/spool/bro/bro# grep dr.dk ssl.log
1538983060.546122	CtKYZ625cq3m3jUz9k	10.xxx.0.145	49932	2.17.212.93	443	TLSv12	TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384	secp256r1	www.dr.dk	F	-	h2	T	FzmZCt3o9EYcmNaxIi,FKXcmxQHT3znDDMSj	(empty)	CN=*.dr.dk,O=DR,L=Copenhagen S,ST=Copenhagen,C=DK	CN=GlobalSign Organization Validation CA - SHA256 - G2,O=GlobalSign nv-sa,C=BE	-	-	ok
1538983060.674217	CLjZo51fzuTcvPT0lg	200xxxxb:89b0:5cbf	49933	2a02:26f0:2400:2a1::3f46	443	TLSv12	TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384	secp256r1	asset.dr.dk	F	-	h2	TFEpW9a1IFe6NTUZNpb,FwV50B4CHIwF1CPlul	(empty)	CN=*.dr.dk,O=DR,L=Copenhagen S,ST=Copenhagen,C=DK	CN=GlobalSign Organization Validation CA - SHA256 - G2,O=GlobalSign nv-sa,C=BE	-	-	ok
\end{alltt}

{\bf Solution:}\\
When you have multiple log files with data from Zeek, and have looked into some of them. You are welcome to ask questions and look into more files.


{\bf Discussion:}\\
How can you hide that you are going to HTTPS sites?

Hint: VPN





\chapter{Check your Debian VM 10 min}
\label{ex:basicDebianVM}

\hlkimage{3cm}{debian-9.png}

{\bf Objective:}\\
Make sure your virtual Debian 9 machine is in working order.

We need a Debian 9 Linux for running the router during the course.

{\bf Only one is needed per team that want to do the exercises. }

{\bf Purpose:}\\
If your VM is not installed and updated we will run into trouble later.

{\bf Suggested method:}\\
Go to \link{https://github.com/kramse/kramse-labs/}

Read the instructions for the setup of a Debian VM.

{\bf Hints:}\\
Sometimes having a router with a GUI can help, but today we do it the most basic way. This ensure we have a good understanding of precisely which parts we have changed.

Also Tcpdump can show what packets are sent and received.

{\bf Solution:}\\
When you have a updated virtualisation software and Kali Linux, then we are good.

{\bf Discussion:}\\
Linux is free and everywhere. The tools we will run in this course are made for Unix, so they run great on Linux.



\chapter{VLANs, Routing and RPF - 2h}
\label{ex:vlans-routing-rpf}

{\bf Objective:}\\
Configure a network and connect it to the local internet exchange. We will learn about IP routing, and internet exchanges. We will also be able to configure blocking and firewall rules.

Note: it is recommended to do this in teams with two laptops. One laptop stays connected to the local wifi with internet access, for searching. The other one runs a Debian server.

The one running a Debian server will be configured as a router! YMMV but having an USB Ethernet adapter that can be dedicated and inserted into the VM will probably be the most efficient and ensure that VLAN tagging - required - are working.

You MAY try using the built-in Ethernet in your laptop for this purpose and use \emph{bridging} to connect it to the network.

{\bf Note: the network does NOT need NAT!} You can use NAT on your router, but it is recommended NOT to. If you enable NAT on your router it will be harder to connect back into your network - need to use features like port forwarding.

{\bf Purpose:}\\
The network built for this training allows you to configure network devices without affecting production networks. You can make all the mistakes and no manager will ask you to write incident reports.

Your team will have a prefix of IPv4 /16, example 10.14.0.0/16. The same ID 14 in this example is used for other purposes too.

All your devices must end up in this network.

There are  multiple networks including the other teams, all are in 10/8.

The uplink expects your connection to the rest of the networks are done with a switch using the internet exchange model with a peering network of 10.10.10.0/24. The core network will initially have a static route pointing all of your prefix to your peering address.

Your router will need an interface in this range, to be able to communicate to the internet and the other networks.

{\bf Suggested method:}\\
Follow the instructions below for each part. Use your team and ask questions - learn.

There are some Ansible scripts in the Github repository \url{https://github.com/kramse/kramse-labs} in the directory core-net-lab.

Recommend doing a git clone FIRST, before changing network configuration of the Virtual Machine.

As always there might be some tuning and learning to do on the way.

This is why I have included a lot of bonus exercises in this exercise book.

\subsection*{Enable routing}
{\bf Make sure routing is actually enabled on your device! Sysctl will show the current setting }

Use your favourite editor and activate the line in /etc/sysctl.conf:
\begin{alltt}
user@debian-9-lab:~$ grep forward /etc/sysctl.conf
# Uncomment the next line to enable packet forwarding for IPv4
net.ipv4.ip_forward=1
\end{alltt}

Note: requires a reboot to pick up this change, or set using sysctl.

Changing it can be done using sysctl or echo:
\begin{alltt}
# sysctl -w net.ipv4.ip_forward=1
net.ipv4.ip_forward = 1

# echo 1 > /proc/sys/net/ipv4/ip_forward
\end{alltt}

Check using:
\begin{alltt}
# sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1
\end{alltt}

also install the \verb+vlan+ package using: \verb+apt-get install vlan+

This can of course be automated using Ansible, with this:
\begin{alltt}
  # Set ip forwarding on in /proc and verify token value with the sysctl command
  - sysctl:
      name: net.ipv4.ip_forward
      value: '1'
      sysctl_set: yes

  # Set ip forwarding on in /proc and in the sysctl file and reload if necessary
  - sysctl:
      name: net.ipv4.ip_forward
      value: '1'
      sysctl_set: yes
      state: present
      reload: yes
\end{alltt}

\subsection*{Network Cards}

{\bf Before configuring your Debian as a router, make sure to remove / deactivate any network cards to your virtualisation host}

You should only have the USB Ethernet configured, as a USB device in the virtual machine. Name may vary - on my server it became: \verb+enx00249b1b2991+

So your configuration should be similar to this:
\begin{alltt}
root@NMS-VM:~# ifconfig  -a
enx00249b1b2991: flags=4098<BROADCAST,MULTICAST>  mtu 1500
        ether 00:24:9b:1b:29:91  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 1355  bytes 556600 (543.5 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1355  bytes 556600 (543.5 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
\end{alltt}


\section*{Initial steps to get started}

Start configuring the switch you have.
We can collect logs about network traffic based on generic netflow, specific types DNS/TLS/protocols, and traffic matching advanced rulesets.

Recommend resetting it first time!

also during configuration, remember to {\bf save config} once in a while.

\begin{enumerate}
\item Cable a laptop to any port, except the first one - port 1/0/1
\item Take control of the switch, default settings are in place, see label on bottom and use Ethernet preferably
\item Add VLAN with ID: 2770 Name: KramsIX
\item Configure the Uplink port with VLAN tag: 2770
\item Configure the first port with VLAN tag: 2770\\
If you keep the port in VLAN 1 you should be able to connect to the switch management via this port using tagged or untagged, as you prefer \smiley
\item Configure VLAN interface on your router with the peering IP in the peering LAN 10.10.10.0/24 - if you team ID is 14, then your peering IP is 10.10.10.14/24
\item Ping 10.10.10.1 from your router
\item Add 10.10.10.1 as your default gateway\\
Dont worry about
\end{enumerate}

\hlkimage{10cm}{vlan-tag-kramsix.png}

When your router can ping 10.10.10.1, and possibly the outside world - congratulate yourself! You have just used VLAN tagging successfully!

If your other laptop can also ping your router from the training network, awesome!

Tools to use for debugging, traceroute, nping, arp

PS The "peering LAN" uses tags to avoid the multiple switches with the same initial configuration to interfere. Only allowing VLAN tagged packets ensure only "configured devices" are let in. Real internet exchanges have lots of rules about which devices you may connect and which traffic is allowed.

Your network config should look something like this:
\begin{alltt}
$ cat /etc/network/interfaces
# interfaces(5) file used by ifup(8) and ifdown(8)
# Include files from /etc/network/interfaces.d:
source-directory /etc/network/interfaces.d

auto enx00249b1b2991
iface enx00249b1b2991 inet static
  address 192.168.0.2
  netmask 255.255.255.0

auto vlan2770
iface vlan2770 inet static
	vlan-raw-device enx00249b1b2991
	address 10.10.10.14
	netmask 255.255.255.0
  gateway 10.10.10.1
\end{alltt}

Note: you should probably also add an IP for the management of the router as shown. If you do NOT activate the base network card, the VLAN sub interfaces will not come online!

\section*{Implement your VLAN and IP plan}

Now that your router is connected continue by adding your VLANs and IPs.
\begin{enumerate}
\item Add your VLANs using the names from your plan.\\
If you have no plan then use VLAN 100 LAN, VLAN 200 Wifi
\item Add ports to your VLAN - may be done while defining them too.\\
You may have a VLAN 100 which is intended for LAN traffic then add this as untagged on a port and tagged to the router port 1/0/1
\item Add your VLAN interfaces and IPs to the router\\
Again, if VLAN 100 is the LAN, add an interface to router with this tag and IP 10.14.100.1 - some prefer the first for routers, others the last .254
\item When adding the interface and port for the Wifi - make the port towards the AP untagged in your VLAN initially. The wifi APs are configured with only one SSID and will just bridged this traffic to the Ethernet port.\\
Using VLAN tagging for the wifi, multiple SSIDs require reconfiguration of the wifi AP - you can do this though.
\end{enumerate}

Check using laptop that you can ping your router, before trying to ping other parts of the network. From the router you should also provide DHCP service - to avoid the clients needing a static IP.

If you are new to routing it may be recommended to have no firewall rules initially. If the routing parts work without trouble then enable firewall.

\section*{Advanced variants}
\begin{enumerate}
\item Remove the default route from your router, replace by a BGP connection to the router 10.10.10.1 using BGP with default settings, no password\\
When the BGP connection is working, ask trainer to remove static route
\item Reverse Path Forwarding (RPF) check can be added using Access Control Lists ACLs
\item Run a DMZ with a web server and block everything except 80/tcp and 443/tcp
\end{enumerate}


{\bf Hints:}\\
Use your team, search the internet, ask for help.

This is a complex routing exercise, if you are new to routing, take it easy.

{\bf Solution:}\\
When you have a network that allows you to surf from inside your own network and one that allows traffic from the training network into your network - you are done.

{\bf Discussion:}\\
How much in this exercise is similar to real networks?

I would say a lot. The exercise emulates a large part of the technologies used in real networks, including layer 3 routing having a peering internet exchange and a transit provider. Also the lab networks allows for playing with layer 2 features such as port security settings.


\chapter{Configuration of DHCP server 30min}
\label{ex:dhcpd-config}

{\bf Objective:}\\
Configure DHCPD

{\bf Purpose:}\\
Getting DHCPD configured ensures that normal people can connect devices easily.

{\bf Suggested method:}\\
Look into dhcpd.conf and configure address pool for clients.

{\bf Hints:}\\
DHCPD is the DHCP daemon, helping spirit.

It is configured using a small config file: \verb+/etc/dhcp/dhcpd.conf+

{\bf Solution:}\\
You should hopefully end up with a running configuration which allows clients to get an IP and configuration settings.

Example running config \verb+/etc/dhcp/dhcpd.conf+:

\VerbatimInput{../../../../github/kramse-labs/core-net-lab/files/dhcpd.conf}


{\bf Discussion:}\\
This service is needed in almost any network.

With IPv4 DHCPD is the recommended way.

With IPv6 sometimes a mix of stateless autoconfiguration and DHCPDv6 is used.


\chapter{Bonus: Configuration of Ubound DNS server 20min}
\label{ex:dns-config}


{\bf Objective:}\\
Learn how to run your own resolver.

{\bf Purpose:}\\
DNS is used by all clients today. So we can configure our own DNS resolver, DNS server.

{\bf Suggested method:}\\
Install Unbound which is the software from \url{https://nlnetlabs.nl/projects/unbound/about/}

{\bf Hints:}\\
Use the package system:

\verb+sudo apt install unbound+

Make sure it is enabled for boot:

\begin{alltt}\footnotesize
root@debian-9-lab:~# systemctl enable unbound
Synchronizing state of unbound.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable unbound
\end{alltt}

{\bf Solution:}\\
By default it seems the Debian Unbound has very little configuration, but allows lookup from localhost:

\begin{alltt}\footnotesize
root@debian-9-lab:~# host www.kramse.org
www.kramse.org has address 185.129.60.130
www.kramse.org has IPv6 address 2a06:d380:0:3065::80
\end{alltt}

It would be required to add a little more, starting with access control:

\begin{alltt}\footnotesize
# The server clause sets the main parameters.
server:
        interface: 0.0.0.0
        access-control: 127.0.0.0/8 allow
        access-control: 10.0.0.0/16 allow
        access-control: 192.168.0.0/16 allow
        access-control: 10.0.45.0/24 allow
        access-control: 8.0.0.0/8 allow

\end{alltt}

This allows local clients access to resolving names.

{\bf Discussion:}\\
Unbound is very feature complete and can perform DNSSEC checks etc. We wont be able to configure and use all these features today.



\chapter{Bonus: Configuration of BIRD BGP daemon 40min}
\label{ex:bgp-config}


{\bf Objective:}\\
Learn how to run your BGP service, to announce your network.

{\bf Purpose:}\\
Border Gateway Protocol (BGP) is a very simple yet complicated technology.

\url{https://en.wikipedia.org/wiki/Border_Gateway_Protocol}

Today just realize:
\begin{list2}
\item BGP allows you to tell a network about your IP addresses, named IP prefixes - similar to subnets, like 10.14.0.0/16
\item BGP allows you to receive network prefixes and add them to your local route table.
\end{list2}

The internet is built using BGP and in the core networks, Tier 1 networks there is no default route - no 0.0.0.0 route.



{\bf Suggested method:}\\
Install BIRD which is the software from \url{https://bird.network.cz/}

{\bf Hints:}\\
Use the package system:

\verb+sudo apt install bird+

Make sure it is enabled for boot:

\begin{alltt}\footnotesize
root@debian-9-lab:~# systemctl enable bird
\end{alltt}

{\bf Solution:}\\
When you install BIRD is has a minimal configuration.

You should first make sure it runs

NOTE: This material expect the version 1.6 of BIRD, so use the documentation from:\\
\url{https://bird.network.cz/?get_doc&f=bird.html&v=16}

Method:
\begin{itemize}
\item Make sure process runs, syntax is correct - check logs
\item Make sure it connects to the other party, BGP is 179/TCP
\item Make sure you are sending and receiving the right prefixes
\item Make sure filters are in place - not needed her, but for production setups!
\end{itemize}

Many times a router will NOT announce if the route/prefix is not active in the routing tables on the local system. Making what is called a null route is also recommended, so start out by null-routing your whole network locally.

This also prevents a lot of routing loops!

The end result might be similar to this:
\VerbatimInput{files/bird.conf}
or This
\VerbatimInput{files/bird.conf.real}



{\bf Discussion:}\\
The BIRD project aims to develop a fully functional dynamic IP routing daemon primarily targeted on (but not limited to) Linux, FreeBSD and other UNIX-like systems and distributed under the GNU General Public License.
- source: \url{https://bird.network.cz/}

BIRD is very feature complete and can perform filtering checks etc. We wont be able to configure and use all these features today.


\chapter{How to Configure Mirror Port 10min}
\label{ex:mirrorport}


{\bf Objective:} \\
Mirror ports are a way to copy traffic to Suricata and other devices - for analyzing it. We will go through the steps on a Juniper switch to show how.
Most switches which are configurable have this possibility.


{\bf Purpose:}\\
We want to capture traffic for multiple systems, so we select an appropriate port and copy the traffic. In our setup, we select the uplink port to the internet/router.

It is also possible to buy passive taps, like a fiber splitter, which then takes part of the signal, and is only observable if you look for signal strength on the physical layer.


{\bf Suggested method:}\\
We will configure a mirror port on a Juniper EX2200-C running Junos.

\begin{alltt}
root@ex2200-c# show ethernet-switching-options | display set
set ethernet-switching-options analyzer mirror01 input ingress interface ge-0/1/1.0
set ethernet-switching-options analyzer mirror01 input egress interface ge-0/1/1.0
set ethernet-switching-options analyzer mirror01 output interface ge-0/1/0.0
set ethernet-switching-options storm-control interface all
\end{alltt}

Then configure source ports, the ones in current use and destination to the selected high port.

If using the TP-Link T1500G-10PS then this link should describe the process:\\
{\small\url{https://www.tp-link.com/en/configuration-guides/mirroring_traffic/?configurationId=18210}}

Which describe:
\begin{enumerate}
\item Choose the menu MAINTENANCE > Mirroring
\item Select Edit for the Mirror Session 1
\item In the Destination Port Config section, specify a destination port for the mirroring session, and click Apply
\item In the Source Interfaces Config section, specify the source interfaces and click Apply
\end{enumerate}

Using the command line would be similar to this:
\begin{alltt}
Switch#configure
Switch(config)#monitor session 1 destination interface gigabitEthernet 1/0/7
Switch(config)#monitor session 1 source interface gigabitEthernet 1/0/1-4 both
Switch(config)#monitor session 1 source cpu 1 both
\end{alltt}

The method is very similar across vendors, \verb+monitor session+ is often the same command as shown above.

{\bf Hints:}\\
Selecting a port away from the existing ones allow easy configuration of the source to be like, Source ports 1-4 and destination 7 - and easily expanded when port 5 and 6 are activated.

When checking your own devices this is often called SPAN ports, Mirror ports or similar.

\url{https://en.wikipedia.org/wiki/Port_mirroring}

Cisco has called this Switched Port Analyzer (SPAN) or Remote Switched Port Analyzer (RSPAN), so many will refer to them as SPAN-ports.

{\bf Solution:}\\
When we can see the traffic from the network, we have the port configured - and can run any tool we like. Note: specialized capture cards can often be configured to spread the load of incoming packets onto separate CPU cores for performance. Capturing 100G and more can also be done using switches like the example found on the Zeek web site using an Arista switch 7150.

Cisco also has a feature named RSPAN

\begin{quote}
Remote SPAN (RSPAN): An extension of SPAN called remote SPAN or RSPAN. RSPAN allows you to monitor traffic from source ports distributed over multiple switches, which means that you can centralize your network capture devices. RSPAN works by mirroring the traffic from the source ports of an RSPAN session onto a VLAN that is dedicated for the RSPAN session. This VLAN is then trunked to other switches, allowing the RSPAN session traffic to be transported across multiple switches. On the switch that contains the destination port for the session, traffic from the RSPAN session VLAN is simply mirrored out the destination port.
\end{quote}
Source: {\small\link{https://community.cisco.com/t5/networking-documents/understanding-span-rspan-and-erspan/ta-p/3144951}}



{\bf Discussion:}\\
When is it ethical to capture traffic?


\chapter{Learn about port security - 10 min}
\label{ex:port-security}

{\bf Objective:}\\
See the options available for port security on the local switch

{\bf Purpose:}\\
Even small cheap switches like the ones used in the training have options that can help protect a network. Such as:

\begin{itemize}
\item Max Learned Number of MAC\\

Specify the maximum number of MAC addresses that can be learned on the port. When the learned MAC address number reaches the limit, the port will stop learning. It ranges from 0 to 64. The default value is 64.

\item Exceed Max Learned Trap\\

Enable Exceed Max Learned, and when the maximum number of learned MAC addresses on the specified port is exceeded, a notification will be generated and sent to the management host.

\item Learn Address Mode\\

Select the learn mode of the MAC addresses on the port. Three modes are provided:

Delete on Timeout: The switch will delete the MAC addresses that are not used or updated within the aging time. It is the default setting.

Delete on Reboot: The learned MAC addresses are out of the influence of the aging time and can only be deleted manually. The learned entries will be cleared after the switch is rebooted.

Permanent: The learned MAC addresses are out of the influence of the aging time and can only be deleted manually. The learned entries will be saved even the switch is rebooted.

\item Status when exceeded\\
Drop: When the number of learned MAC addresses reaches the limit, the port will stop learning and discard the packets with the MAC addresses that have not been learned.

Forward: When the number of learned MAC addresses reaches the limit, the port will stop learning but send the packets with the MAC addresses that have not been learned.
\end{itemize}

{\bf Suggested method:}\\
Visit the settings page, configure port security and try running the \verb+macof+ mac overflow tool from a laptop connected on that port.

{\bf Hints:}\\
There may be a configuration guide at:\\
{\small\url{https://www.tp-link.com/en/configuration-guides/configuring_port_security/?configurationId=18227}}

{\bf Solution:}\\
When you have seen the setting, either on the available devices, or searched the internet and found the options available on your favourite device, you are done.

{\bf Discussion:}\\
Port security is often neglected, so a small cabling issue in a single device in an office may take down the whole office location network.

Think about port security when installing new networks, and turn it on immediately before allowing people to connect, as most managers are wary about enabling it afterwards.



\chapter{Bonus: SNMP walk 15min}
\label{ex:snmpwalk}

{\bf Objective:}\\
Run SNMP walk on a switch, \verb+snmpwalk+ see information from device.

Lots of basic information helps defenders - AND attackers.

{\bf Purpose:}\\
SNMP is a default management protocol used in almost any network.

{\bf Suggested method:}\\
Enable SNMPv2 with a community of "public".

Run snmpwalk using community string public.
Command is: \verb+snmpwalk -v 2c -c public system+

%\begin{alltt}
%$
%\end{alltt}

{\bf Hints:}\\
Community strings private and public used to be default for network devices. Today professionel devices have no SNMP configured by default, but lots of networks install the community "public" anyway.

{\bf Solution:}\\
When you have done snmpwalk for at least one device.

{\bf Discussion:}\\
Which part of the information is most relevant to defenders, and attackers.

Also remember on internal LAN segments, use Nmap:
\begin{alltt}
snmp-10.x.y.0.gnmap: nmap -sV -A -p 161 -sU --script=snmp-info -oA snmp-10xy 10.x.y.0/19
snmpscan: nmap -sU -p 161 -oA snmpscan --script=snmp-interfaces -iL targets
\end{alltt}



\chapter{Bonus: Monitoring - setup LibreNMS - 30 min}
\label{ex:librenms-setup}

{\bf Objective:}\\
See and work with LibreNMS - for a little while.

{\bf Purpose:}\\
Show that initial setup of LibreNMS is quite easy, and immediately gives some results.

{\bf Suggested method:}\\
Choose installation method from:\\
\link{https://docs.librenms.org/Installation/}

Prebuilt docker and VM images will be fastest.

{\bf Hints:}\\
As they themselves write on the web page \link{https://www.librenms.org/}

\begin{quote}
LibreNMS is a fully featured network monitoring system that provides a wealth of features and device support.
\end{quote}

If you feel this is too much work, ask for login to the central one used for the core network.

{\bf Solution:}\\
When you have played around with LibreNMS you are done.

It is recommended to look at:
\begin{itemize}
\item How basic information about devices are presented, from devices when added - and nothing more.\\
See how to add a device and add your own. \link{https://docs.librenms.org/Support/Adding-a-Device/}
\item How SNMP location is used to categorize devices and provice maps, see \link{https://docs.librenms.org/Extensions/World-Map/}
\item How protocols like LLDP allow LibreNMS to make maps, see \link{https://docs.librenms.org/Extensions/Network-Map/}
\item How port description can be used for describing ports, \link{https://docs.librenms.org/Extensions/Interface-Description-Parsing/}
\end{itemize}

Most of this happens with very little effort. Just configure devices consistently and they will be presented nicely.

{\bf Discussion:}\\
Have you configured port description? Try it!

Real networks have policies for port description settings.




\chapter{Bonus: IDS with Zeek and Suricata - 10min}
\label{ex:suricata-real-network}

{\bf Objective:}\\
Adding an IDS to your network will help a lot with insights into traffic patterns, and bad traffic.

I recommend the Suricata and Zeek software and use it to monitor your traffic.

{\bf Purpose:}\\
Discuss the concept of IDS and difference between Suricata and Zeek.

{\bf Suggested method:}\\
Configure a mirror port - select a high numbered port not in use.

Use a laptop on the port to verify you get copies of packets on this port.

Then configure a Suricata or Zeek, maybe this course materials can help:\\
\url{https://github.com/kramse/security-courses/tree/master/courses/networking/suricatazeek-workshop}


{\bf Hints:}\\


{\bf Solution:}\\
When your team has configured a mirror port and seen traffic using your IDS or just tcpdump you are done.

{\bf Discussion:}\\
How would you monitor a larger network?



\chapter{Bonus: Nping check ports 10 min}
\label{ex:nping-tcp}
{\bf Objective:} \\
Show the use of Nping tool for checking ports through a network

{\bf Purpose:}\\
Nping can check if probes can reach through a network, reporting success of failure. Allows very specific packets to be sent.

{\bf Suggested method:}\\
Run the command using a common port like Web HTTP:
\begin{alltt}\footnotesize
root@KaliVM:~# nping --tcp -p 80 www.zencurity.com

Starting Nping 0.7.70 ( https://nmap.org/nping ) at 2018-09-07 19:06 CEST
SENT (0.0300s) TCP 10.137.0.24:3805 > 185.129.60.130:80 S ttl=64 id=18933 iplen=40  seq=2984847972 win=1480
RCVD (0.0353s) TCP 185.129.60.130:80 > 10.137.0.24:3805 SA ttl=56 id=49674 iplen=44  seq=3654597698 win=16384 <mss 1460>
SENT (1.0305s) TCP 10.137.0.24:3805 > 185.129.60.130:80 S ttl=64 id=18933 iplen=40  seq=2984847972 win=1480
RCVD (1.0391s) TCP 185.129.60.130:80 > 10.137.0.24:3805 SA ttl=56 id=50237 iplen=44  seq=2347926491 win=16384 <mss 1460>
SENT (2.0325s) TCP 10.137.0.24:3805 > 185.129.60.130:80 S ttl=64 id=18933 iplen=40  seq=2984847972 win=1480
RCVD (2.0724s) TCP 185.129.60.130:80 > 10.137.0.24:3805 SA ttl=56 id=9842 iplen=44  seq=2355974413 win=16384 <mss 1460>
SENT (3.0340s) TCP 10.137.0.24:3805 > 185.129.60.130:80 S ttl=64 id=18933 iplen=40  seq=2984847972 win=1480
RCVD (3.0387s) TCP 185.129.60.130:80 > 10.137.0.24:3805 SA ttl=56 id=1836 iplen=44  seq=3230085295 win=16384 <mss 1460>
SENT (4.0362s) TCP 10.137.0.24:3805 > 185.129.60.130:80 S ttl=64 id=18933 iplen=40  seq=2984847972 win=1480
RCVD (4.0549s) TCP 185.129.60.130:80 > 10.137.0.24:3805 SA ttl=56 id=62226 iplen=44  seq=3033492220 win=16384 <mss 1460>

Max rtt: 40.044ms | Min rtt: 4.677ms | Avg rtt: 15.398ms
Raw packets sent: 5 (200B) | Rcvd: 5 (220B) | Lost: 0 (0.00%)
Nping done: 1 IP address pinged in 4.07 seconds
\end{alltt}

{\bf Hints:} \\
A lot of options are similar to Nmap

{\bf Solution:}\\
When you have tried it towards an open port, a closed port and an IP/port that is filtered you are done.

{\bf Discussion:}\\
A colleague of ours had problems sending specific IPsec packets through a provider. Using a tool like Nping it is possible to show what happens, or where things are blocked.

\eject
Things like changing the TTL may provoke ICMP messages, like this:
\begin{alltt}\footnotesize
root@KaliVM:~# nping --tcp -p 80 --ttl 3 www.zencurity.com

Starting Nping 0.7.70 ( https://nmap.org/nping ) at 2018-09-07 19:08 CEST
SENT (0.0303s) TCP 10.137.0.24:37244 > 185.129.60.130:80 S ttl=3 id=60780 iplen=40  seq=1997801125 win=1480
RCVD (0.0331s) ICMP [10.50.43.225 > 10.137.0.24 TTL=0 during transit (type=11/code=0) ] IP [ttl=62 id=28456 iplen=72 ]
SENT (1.0314s) TCP 10.137.0.24:37244 > 185.129.60.130:80 S ttl=3 id=60780 iplen=40  seq=1997801125 win=1480
RCVD (1.0337s) ICMP [10.50.43.225 > 10.137.0.24 TTL=0 during transit (type=11/code=0) ] IP [ttl=62 id=28550 iplen=72 ]
SENT (2.0330s) TCP 10.137.0.24:37244 > 185.129.60.130:80 S ttl=3 id=60780 iplen=40  seq=1997801125 win=1480
RCVD (2.0364s) ICMP [10.50.43.225 > 10.137.0.24 TTL=0 during transit (type=11/code=0) ] IP [ttl=62 id=28589 iplen=72 ]
SENT (3.0346s) TCP 10.137.0.24:37244 > 185.129.60.130:80 S ttl=3 id=60780 iplen=40  seq=1997801125 win=1480
RCVD (3.0733s) ICMP [10.50.43.225 > 10.137.0.24 TTL=0 during transit (type=11/code=0) ] IP [ttl=62 id=29403 iplen=72 ]
SENT (4.0366s) TCP 10.137.0.24:37244 > 185.129.60.130:80 S ttl=3 id=60780 iplen=40  seq=1997801125 win=1480
RCVD (4.0558s) ICMP [10.50.43.225 > 10.137.0.24 TTL=0 during transit (type=11/code=0) ] IP [ttl=62 id=30235 iplen=72 ]

Max rtt: 38.574ms | Min rtt: 2.248ms | Avg rtt: 13.143ms
Raw packets sent: 5 (200B) | Rcvd: 5 (360B) | Lost: 0 (0.00%)
Nping done: 1 IP address pinged in 4.07 seconds
\end{alltt}


\chapter{Bonus: Try pcap-diff 15 min}
\label{ex:pcap-diff}

{\bf Objective:}\\
Try both getting an utility tool from Github and running an actual useful tool for comparing packet captures.

{\bf Purpose:}\\
Being able to get tools and scripts from Github makes you more effective.

The tool we need today is \link{https://github.com/isginf/pcap-diff}
{\bf Suggested method:}\\
Git clone the repository, follow instructions for running a packet diff.

Try saving a few packets in a packet capture, then using tcpdump read and write a subset - so you end up with two packet captures:
\begin{alltt}\footnotesize
sudo tcpdump -w icmp-dump.cap
// run ping in another window, which probably creates ARP packets
// Check using tcpdump
sudo tcpdump -r icmp-dump.cap arp
reading from file icmp-dump.cap, link-type EN10MB (Ethernet)
10:06:18.077055 ARP, Request who-has 10.137.0.22 tell 10.137.0.6, length 28
10:06:18.077064 ARP, Reply 10.137.0.22 is-at 00:16:3e:5e:6c:00 (oui Unknown), length 28
10:06:24.776987 ARP, Request who-has 10.137.0.6 tell 10.137.0.22, length 28
10:06:24.777107 ARP, Reply 10.137.0.6 is-at fe:ff:ff:ff:ff:ff (oui Unknown), length 28
// Write the dump - but without the ARP packets:
sudo tcpdump -r icmp-dump.cap -w icmp-dump-no-arp.cap not arp
\end{alltt}

With these pcaps you should be able to do:
\begin{alltt}\footnotesize
sudo pip install scapy
git clone https://github.com/isginf/pcap-diff.git
cd pcap-diff/

$ python pcap_diff.py -i ../icmp-dump.cap -i ../icmp-dump-no-arp.cap -o diff.cap
Reading file ../icmp-dump.cap:
Found 23 packets

Reading file ../icmp-dump-no-arp.cap:
Found 19 packets

Diffing packets:

Found 2 different packets

Writing diff.cap
// Try reading the output packet diff:

$ sudo tcpdump -r diff.cap
reading from file diff.cap, link-type EN10MB (Ethernet)
10:06:24.777107 ARP, Reply 10.137.0.6 is-at fe:ff:ff:ff:ff:ff (oui Unknown), length 28
10:06:24.776987 ARP, Request who-has 10.137.0.6 tell 10.137.0.22, length 28
\end{alltt}

Note: I ran these on a Debian, so I needed the sudo, if you run this on Kali there is no need to use sudo.

{\bf Hints:}\\
Git is one of the most popular software development tools, and Github is a very popular site for sharing open source tools.

{\bf Solution:}\\
When you or your team mate has a running pcap-diff then you are done

{\bf Discussion:}\\
I often find that 90\% of my tasks can be done using existing open source tools.

\chapter{Bonus: Discover active systems ping sweep 10 min}
\label{ex:nmap-pingsweep}
\hlkimage{5cm}{nmap-zenmap.png}

{\bf Objective:}\\
Use nmap to discover active systems

{\bf Purpose:}\\
Know how to use nmap to scan networks for active systems.

{\bf Suggested method:}\\
Try different scans,
\begin{itemize}
\item Ping sweep to find active systems
\item Port sweeps to find active systems with specific ports
\end{itemize}

{\bf Hints:} \\
Try nmap in sweep mode - and you may run this from Zenmap

{\bf Solution:}\\
Use the command below as examples:
\begin{itemize}
\item Ping sweep \verb+nmap -sP 10.0.45.*+
\item Port sweeps \verb+nmap -p 80 10.0.45.*+
\end{itemize}

{\bf Discussion:}\\
Quick scans quickly reveal interesting hosts, ports and services

Also now make sure you understand difference between single host scan
10.0.45.123/32, a whole subnet /24 ~250 hosts 10.0.45.0/24 and other more advanced targeteting like 10.0.45.0/25 and 10.0.45.1-10


\chapter{Bonus: Execute nmap TCP and UDP port scan 20 min}
\label{ex:nmap-synscan}


{\bf Objective:} \\
Use nmap to discover important open ports on active systems

{\bf Purpose:}\\
Finding open ports will allow you to find vulnerabilities on these ports.

{\bf Suggested method:}\\
Use \verb+nmap -p 1-1024 server+ to scan the first 1024 TCP
ports and use Nmap without ports. What is scanned then?

Try to use \verb+nmap -sU+ to scan using UDP ports, not really possible if a firewall is in place.

If a firewall blocks ICMP you might need to add \verb+-Pn+ to make nmap scan even if there are no Ping responses

{\bf Hints:} \\
Sample command: \verb+nmap -Pn -sU -p1-1024 server+ UDP port scanning
1024 ports without doing a Ping first

{\bf Solution:}\\
Discover some active systems and most in{ex:basicDebianVM}teresting ports, which are 1-1024 and the built-in list of popular ports.

{\bf Discussion:}\\
There is a lot of documentation about the nmap portscanner, even a book by the author
of nmap. Make sure to visit \link{http://www.nmap.org}

TCP and UDP is very different when scanning. TCP is connection/flow oriented and requires a handshake which is very easy to identify. UDP does not have a handshake and most applications will not respond to probes from nmap. If there is no firewall the operating system will respond to UDP probes on closed ports - and the ones that do not respond must be open.

When doing UDP scan on the internet you will almost never get a response, so you cannot tell open (not responding services) from blocked ports (firewall drop packets). Instead try using specific service programs for the services, sample program could be \verb+nsping+ which sends DNS packets, and will often get a response from a DNS server running on UDP port 53.

\chapter{Bonus: Perform nmap OS detection 10 min}
\label{ex:nmap-os}

{\bf Objective:} \\
Use nmap OS detection and see if you can guess the brand of devices on the network

{\bf Purpose:}\\
Getting the operating system of a system will allow you to focus your next attacks.

{\bf Suggested method:}\\
Look at the list of active systems, or do a ping sweep.

Then add the OS detection using the option \verb+-O+

Better to use -A all the time, includes even more scripts and advanced stuff
See the next exercise.

{\bf Hints:} \\
The nmap can send a lot of packets that will get different responses, depending on the operating system. TCP/IP is implemented using various constants chosen by the implementors, they have chosen different standard packet TTL etc.

{\bf Solution:}\\
Use a command like \verb+nmap -O -p1-100 10.0.45.45+ or  \verb+nmap -A -p1-100 10.0.45.45+


{\bf Discussion:}\\
nmap OS detection is not a full proof way of knowing the actual operating system, but in most cases in can detect the family and in some cases it can identify the exact patch level of the system.


\chapter{Bonus: Logning med syslogd og syslog.conf 10min}
\label{ex:syslogd-basic}

{\bf Objective:} \\
See how server syslog is configured on regular Unix/Linux

{\bf Purpose:}\\
The main idea of this exercise is to understand how easy network connected systems can send log data.


{\bf Suggested method:}\\
Log into your local Linux systems or network devices, see how syslog is configured.

{\bf Hints:}\\
Look in the config file, may be in /etc/syslog  or /etc/syslog-ng/syslog-ng.conf

Sample output from old-skool syslogd
\begin{alltt}
\small
*.err;kern.debug;auth.notice;authpriv.none;mail.crit    /dev/console
*.notice;auth,authpriv,cron,ftp,kern,lpr,mail,user.none /var/log/messages
kern.debug;user.info;syslog.info                        /var/log/messages
auth.info                                               /var/log/authlog
authpriv.debug                                          /var/log/secure
...
# Uncomment to log to a central host named "loghost".
#*.notice;auth,authpriv,cron,ftp,kern,lpr,mail,user.none        @loghost
#kern.debug,user.info,syslog.info                               @loghost
#auth.info,authpriv.debug,daemon.info                           @loghost
\end{alltt}

{\bf Solution:}\\
When you understand how to configure syslog from a couple of devices and has looked up which protocol and port it uses. (default is 514/udp)

{\bf Discussion:}\\
There are syslog senders for Windows too.






\end{document}

\appendix
\rhead{\fancyplain{}{\bf \leftmark}}
%\setlength{\parskip}{5pt}

\normal


\chapter{}
\label{ex:}

{\bf Objective:}\\


{\bf Purpose:}\\


{\bf Suggested method:}\\


{\bf Hints:}\\


{\bf Solution:}\\


{\bf Discussion:}\\
