1 05-Security


Previous: 04-NetworkData.html

1.1 Audio-recording

1.2 Opening thoughts

05-Security/windows_firewall.jpeg
Side-channels are the most common attacks!

1.3 IDS and firewall Introduction

1.3.1 Firewalls

1.3.2 Design requirements

1.3.3 Firewall characteristics

1.3.3.1 Firewall Access Policy

1.3.3.2 Firewalls can filter by

1.3.3.3 Capabilities

1.3.3.4 Limitations

1.4 Types of firewall

05-Security/f1-crop_fw.png

1.4.1 Packet filtering firewall (a) above

Packet filtering firewall stores tables of rules (chains)
05-Security/image7.png

  1. Inbound mail from an external source is allowed (port 25 is for SMTP incoming).
  2. This rule is intended to allow a response to an inbound SMTP connection.
  3. Outbound mail to an external source is allowed.
  4. This rule is intended to allow a response to an inbound SMTP connection.
  5. This is an explicit statement of the default policy. All rule sets include this rule implicitly as the last rule.

1.4.1.1 Advantages

1.4.1.2 Weaknesses

1.4.2 Stateful inspection firewall (c) below

A TCP packet tries to get past the firewall on the way to the bar.
Firewall says “hey, you’re out of order”.

05-Security/f1-crop_fw.png
* Statefulness tightens rules for TCP traffic by creating a directory of outbound TCP connections.
* There is an entry for each currently established connection.
* Packet filter allows incoming traffic to high numbered ports only for those packets that fit the profile of one of the entries in this directory.
* Reviews packet information, but also records information about TCP connections
* Keeps track of TCP sequence numbers to prevent attacks that depend on the sequence number

Ask:
* Does this remind you of any other protocol/service we have talked about recently?
* What about incoming UDP?

Stateful Inspection Firewall needs to keep a dynamically changing table of connections:
05-Security/image8.png
Table of outgoing connections determines which incoming connections are allowed.

1.4.3 Application layer firewall / proxy (b) below

05-Security/f1-crop_fw.png

Application level gateways can be:

Network based (e.g., big brother your employees to the extreme)

Host based (e.g., don’t trust your own applications, privacy firewall)

Note: In my opinion, one very cool project would be making an open-snitch/little-snitch/zone-alarm like firewall out of SELinux.

1.4.4 Circuit level proxy firewall (d) below

05-Security/f1-crop_fw.png

1.4.4.1 Circuit-Level Gateway/Proxy

A kind of:
https://en.wikipedia.org/wiki/Proxy_server

1.4.4.1.1 SOCKS5

https://en.wikipedia.org/wiki/SOCKS

Another example:
Tor sets up a SOCKS proxy that does not require authentication for applications running on localhost
Those applications may send data to the socks proxy, and have that data relayed through the Tor network.
You can re-configured your regular browser or any other application with SOCKS settings to run through the Tor browser’s Tor process in this way.

https://en.wikipedia.org/wiki/Tor_network

demo in class

sudo dnf install tor
sudo systemctl enable tor
sudo systemctl start tor
# route firefox settings through socks/9050 with DNS too

Another fun example (check out in class):
https://ma.ttias.be/socks-proxy-linux-ssh-bypass-content-filters/
05-Security/ssh_socks5_proxy_linux.png

1.5 Firewall location and configuration

1.5.1 Bastion hosts

1.5.2 Host-based firewalls

1.5.3 Personal firewall

1.5.3.1 netfilter and iptables

https://en.wikipedia.org/wiki/Netfilter
https://www.netfilter.org/

1.5.4 Locations

Firewall locations and demilitarized zone (DMZ)
05-Security/f3-crop_fw.png

IPSec based VPN
05-Security/f4-crop_fw.png

Distributed firewall locations
05-Security/f5-crop_fw.png

1.5.5 Firewall Topologies

1.6 Linux standard firewall: IPtables

https://en.wikipedia.org/wiki/Iptables
https://en.wikipedia.org/wiki/Netfilter

Note: I’ve had numerous students say that this section of the class helped them pass an interview or even make it through an internship, learning IPTables that is.

1.6.1 IPtables, netfilter, kernel networking

05-Security/Linux-Netfilter-Stack-974x1024.png

IPtables and netfilter

User-space:

Kernel:

Hardware / interfaces:

Where in OS?

1.6.2 Architecture

IPtables and netfilter
05-Security/a8_f3.png

IPtables and netfilter
05-Security/iptables_chains.png

IPtables and netfilter
05-Security/Figure-1-Packet-filtering-in-iptables.png

IPtables and netfilter
05-Security/DM_NF.PNG

IPtables and netfilter
05-Security/netfilter.png

IPtables and netfilter
05-Security/FW-IDS-iptables-Flowchart-2014-09-25.png

IPtables and netfilter
05-Security/iptables-packet-traverse-map-2.png

IPtables and netfilter
05-Security/Netfilter-packet-flow.png

1.6.2.1 Chains in tables

05-Security/iptables-filter-nat-mangle-tables.png
As a packet triggers a netfilter hook, the associated chains will be processed as they are listed in the table above from top-to-bottom, with rules processed from top to bottom.

1.6.2.2 Tables

filter table is one of the most widely used tables in iptables.
The filter table is used to make decisions about whether to let a packet continue to its intended destination or to deny its request.
In firewall parlance, this is known as “filtering” packets.
This table provides the bulk of functionality that people think of when discussing firewalls.

nat table is used to implement network address translation rules.
As packets enter the network stack, rules in this table will determine whether and how to modify the packet’s source or destination addresses in order to impact the way that the packet and any response traffic are routed.

mangle table is used to alter the IP headers of the packet in various ways.
You can adjust the TTL (Time to Live) value of a packet, either lengthening or shortening the number of valid network hops the packet can sustain.

The iptables firewall is stateful, meaning that packets are evaluated in regards to their relation to previous packets.
The connection tracking features built on top of the netfilter framework allow iptables to view packets as part of an ongoing connection or session instead of as a stream of discrete, unrelated packets.
The connection tracking logic is usually applied very soon after the packet hits the network interface.
The raw table has a very narrowly defined function.
Its only purpose is to provide a mechanism for marking packets in order to opt-out of connection tracking.

The security table is used to set internal SELinux security context marks on packets
This affects how SELinux or other systems that can interpret SELinux security contexts handle the packets.
These marks can be applied on a per-packet or per-connection basis.

Chains in tables
05-Security/iptables-filter-nat-mangle-tables.png

1.6.2.3 Chains rely on kernel hooks

Netfilter Kernel Hooks

1.6.2.4 Chains

As you can see, the names of the built-in chains mirror the names of the netfilter hooks they are associated with:

1.6.2.5 Rules

Rules in chains
05-Security/iptables-table-chain-rule-structure.png
Rules are also processed in order, often with a catch-all at the end.

1.6.2.6 Traversal order

Chain Traversal Order Assuming that the server knows how to route a packet and that the firewall rules permit its transmission, the following flows represent the paths that will be traversed in different situations:

IPtables and netfilter flow
05-Security/10822f1.png

Targets (another chain to send to) A target is the action that are triggered when a packet meets the matching criteria of a rule.
Targets are generally divided into two categories:

1.7 Stateful connection tracking

1.7.1 TCP connections

TCP state tracking: connection

For a stateful firewall:
05-Security/state-tcp-connecting.png

TCP state tracking: closing
05-Security/state-tcp-closing.png

TCP state tracking: client sub-connection
05-Security/state-tcp-client-subconn.png

TCP state tracking: server sub-connection
05-Security/state-tcp-server-subconn.png

1.7.2 UDP “connection” tracking

UDP state tracking: “connection”
05-Security/state-udp-connection.png
Watches inverted port numbers.

State Explanation: NEW

State Explanation: ESTABLISHED

State Explanation: RELATED

State Explanation: INVALID

State Explanation: UNTRACKED

05-Security/FW_demo.sh

Note:

#!/bin/bash

# Read:
# man iptables
# man iptables-extensions
# sudo iptables -m conntrack -h

########## INFO AND DISPLAY
# list of common ports in
cat /etc/services

# Run: netstat -lntu
#    -l  prints only listening sockets
#    -n  shows port number
#    -t  enables listing of tcp ports
#    -u  enables listing of udp ports
sudo netstat -lntu

# To display existing IPtables rules
echo before
echo | sudo iptables -L -v
echo | sudo iptables -S

# If you are running Fedora: https://fedoraproject.org/wiki/FirewallD
#sudo dnf install iptables-services
#sudo systemctl mask firewalld.service
#sudo systemctl enable iptables.service
#sudo systemctl enable ip6tables.service
#sudo systemctl stop firewalld.service
#sudo systemctl start iptables.service
#sudo systemctl start ip6tables.service

# STEP 0: clear all old rultes
sudo iptables -F # (--flush or -F)
sudo iptables -F -t mangle
sudo iptables -F -t nat

sudo iptables -X # (--delete-chain or -X)
sudo iptables -X -t mangle
sudo iptables -X -t nat

# STEP 1: set default policies for each chain, using (--policy or -P)
sudo iptables -P INPUT DROP
sudo iptables -P FORWARD DROP
sudo iptables -P OUTPUT DROP

# STEP 2: Add new rules to each chain (INPUT, FORWARD, OUTPUT) using this syntax:

# sudo iptables -A  -i <interface> -p <protocol (tcp/udp)> -s <source> --dport <port no.>  -j <target>

########## INPUT CHAIN

# As network traffic generally needs to be two-way,
# incoming and outgoing to work properly,
# it is typical to create a firewall rule that allows established and related incoming traffic,
# so that the server will allow return traffic to outgoing connections initiated by the server itself.
# This command will allow that:
#old syntax: sudo iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
sudo iptables -A INPUT -m conntrack --ctstate RELATED, ESTABLISHED -j ACCEPT

# Local traffic accepted
sudo iptables -A INPUT -i lo -j ACCEPT

# Simple version of SSH incoming OK, stateless
sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT

# SSH incoming OK, stateful
sudo iptables -A INPUT -i eth0 -p tcp --dport 22 -m conntrack --ctstate NEW, ESTABLISHED -j ACCEPT

# Accept packets from trusted IP addresses
sudo iptables -A INPUT -s 192.168.0.4 -j ACCEPT               # change the IP address as appropriate
sudo iptables -A INPUT -s 192.168.0.0/24 -j ACCEPT            # using standard slash notation
sudo iptables -A INPUT -s 192.168.0.0/255.255.255.0 -j ACCEPT # or using a subnet mask

# To block network connections that originate from a specific IP address,
# 15.15.15.51 for example, run this command:
sudo iptables -A INPUT -s 15.15.15.51 -j DROP

# Accept tcp packets on destination port 6881 (bittorrent)
sudo iptables -A INPUT -p tcp --dport 6881 -j ACCEPT

# Some network traffic packets get marked as invalid.
# Sometimes it can be useful to log this type of packet but often it is fine to drop them.
# Do so with this command:
sudo iptables -A INPUT -m conntrack --ctstate INVALID -j DROP

# To allow all incoming HTTPS (port 443) connections run these commands:
sudo iptables -A INPUT -p tcp --dport 443 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
sudo iptables -A OUTPUT -p tcp --sport 443 -m conntrack --ctstate ESTABLISHED -j ACCEPT

# Default catch-all in case you did not have a secure default policy
sudo iptables -A INPUT -j REJECT

########## FORWARD CHAIN

# Assuming eth0 is your external network,
# and eth1 is your internal network,
# this will allow your internal to access the external:
sudo iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT

sudo iptables -A FORWARD -j REJECT

########## OUTPUT CHAIN
sudo iptables -A OUTPUT -o lo -j ACCEPT

# HTTPS port allowed out, but not HTTP port
sudo iptables -A OUTPUT -p tcp --dport https -j ACCEPT
# sudo iptables -A OUTPUT -p tcp --dport http -j ACCEPT

# DNS allowed out on 53
sudo iptables -A OUTPUT -p udp --dport domain -j ACCEPT

# Output SSH allowed.
# You may want to allow outgoing traffic of all established connections,
# which are typically the response to legitimate incoming connections.
# This command will allow that:
sudo iptables -A OUTPUT -o eth0 -p tcp --sport 22 -m conntrack --ctstate ESTABLISHED -j ACCEPT

# Block a particular website (e.g., facebook):
# host -t a www.facebook.com says ip is:
sudo iptables -A OUTPUT -d 157.240.2.35 -j DROP

# Final catch-all in case you did not have a secure default policy
sudo iptables -A OUTPUT -j REJECT

# Note: this line assumes Fedora, and Debian is different.
# The rest above should be cross-distro
sudo service iptables save

echo after
echo | sudo iptables -L -v
echo | sudo iptables -S

++++++++++++++++++++++++++++ Cahoot-05-1

++++++++++++++++++++++++++++ Cahoot-05-2

Notes:

https://en.wikipedia.org/wiki/PF_(firewall)
BSD based firewall that you may encounter,
particularly given the dominance of BSD-based firewall distributions like pfSense and OPNSense.

1.8 IPS/IDS Intrusion Prevention/Dection Systems

1.8.1 Classes of Intruders

1.8.1.1 Intruders - Activists

1.8.1.2 Intruders - State-Sponsored Organizations

1.8.1.3 Intruders - Others

1.8.2 Intruder skill levels

1.8.2.1 Intruder Skill Levels - Apprentice

1.8.2.2 Intruder Skill Levels - Journeyman

1.8.2.3 Intruder Skill Levels - Master

1.8.3 Examples of Intrusion

1.8.4 Intruder Behavior

1.8.4.1 Target Acquisition and Information Gathering

1.8.4.2 Initial Access

1.8.4.3 Privilege Escalation

1.8.4.4 Information Gathering or System Exploit

1.8.4.5 Maintaining Access

1.8.4.6 Covering Tracks

1.8.5 Intrusion detection

1.8.5.1 Definitions

Security Intrusion:
A security event, or a combination of multiple security events, that constitutes a security incident in which an intruder gains, or attempts to gain, access to a system (or system resource) without having authorization to do so.

Intrusion Detection:
A security service that monitors and analyzes system events for the purpose of finding, and providing real-time or near real-time warning of, attempts to access system resources in an unauthorized manner.

1.8.5.2 Intrusion Detection System (IDS)

1.8.5.2.1 Host-based IDS (HIDS)
1.8.5.2.2 Network-based IDS (NIDS)
1.8.5.2.3 Distributed or hybrid IDS

Combines information from a number of sensors, often both host and network based, in a central analyzer that is able to better identify and respond to intrusion activity

Discrimination between normal an intruder behavior
05-Security/f1-crop.png

1.8.5.3 IDS requirements

1.8.5.4 Analysis Approaches

  1. Anomaly detection
  1. Signature/Heuristic detection
1.8.5.4.1 1. Anomaly based detection

Statistical
Analysis of the observed behavior using univariate, multivariate, or time-series models of observed metrics.

Knowledge based
Approaches use an expert system that classifies observed behavior according to a set of rules that model legitimate behavior.

Machine learning
Approaches automatically determine a suitable classification model from the training data using data mining techniques: Bayesian networks, Markov models, Neural Networks, Fuzzy logic, Genetic algorithms, Clustering, and Reinforcement learning.

1.8.5.4.2 2. Signature or heuristic based detection

Signature approaches

Rule-based heuristic identification

++++++++++++++++++++ Cahoot-05-3

1.8.6 Host-based intrusion detection (HIDS)

1.8.6.1 Data sources and sensors

1.8.6.2 Anomaly based detection

1.8.6.3 Signature or heuristic based detection

1.8.6.4 Distributed HIDS

Three main components:

  1. Host agent module:
  2. LAN monitor agent module:
  3. Central manager module:
05-Security/f2-crop.png

Agent architecture
05-Security/f3-crop.png

1.8.7 Network-based NIDS

1.8.7.1 Types of network sensors

Sensor types: inline and passive

Passive NIDS sensor
05-Security/f4-crop.png

1.8.7.2 Sensor locations

Sensor deployment locations
05-Security/f5-crop.png

1.8.7.3 Intrusion detection techniques

Attacks suitable for signature detection

Attacks suitable for anomaly detection

Stateful Protocol Analysis (SPA)

1.8.7.4 Logging alerts

Typical information logged by a NIDS sensor includes:

1.8.8 Distributed or hybrid HIDS

1.8.9 ID data standards

IETF Intrusion Detection Working Group
Purpose is to define data formats and exchange procedures for sharing information of interest to intrusion detection and response systems and to management systems that may need to interact with them.

General message exchange framework
05-Security/f7-crop.png

1.8.9.0.1 General message exchange framework

1.9 Example IDS/IPS: Snort

05-Security/snort_00.png
05-Security/snort_01.png
05-Security/snort_02.png
05-Security/snort_03.png

++++++++++++++++++ Cahoot-05-4

1.10 Other firewalls, and firewall and router distributions

Check these out in class, sort tables by license:

1.10.1 pf (a firewall) and pfSense (a production OS)

pf is the openbsd firewall

pfSense is a firewall distribution

OPNsense is a fork of pfSense

More info on how to set up pfSense and Snort in ra05-Firewall-IPS

1.11 Honeypots

https://en.wikipedia.org/wiki/Honeypot_(computing)
(show this link)

1.11.1 Honeypot types

Most are server honeypots, but some are clients.

1.11.1.1 Pure honeypots

1.11.1.2 Low interaction honeypot

1.11.1.3 High interaction honeypot

1.11.1.4 Client honeypot

https://en.wikipedia.org/wiki/Client_honeypot

1.11.2 Applications

1.11.3 Honeypot locations

05-Security/f8-crop.png

1.11.4 Example honeypots and demos

05-Security/honeypots.png

1.11.4.1 Attack maps

Some derived from honeypots, others from actual attack, network, and malware statistics

“When you go after honey with a balloon, the great thing is to not let the bees know you’re coming.”
- Winnie the Pooh

+++++++++++++++++ Cahoot-05-5

2 DoS (Denial of Service)

3 Definitions

Denial-of-Service (DoS) Attack The NIST Computer Security Incident Handling Guide defines a DoS attack as:
“An action that prevents or impairs the authorized use of networks, systems, or applications by exhausting resources such as central processing units (CPU), memory, bandwidth, and disk space.”

Categories of resources that could be attacked:

Network bandwidth

System resources

Application resources

Varieties of end users as both attackers and victims
05-Security/f1-crop-dos.png

4 DoS Attacks

https://en.wikipedia.org/wiki/Denial-of-service_attack

4.1 Classic DoS Attacks

4.2 Source Address Spoofing

4.3 SYN spoofing

TCP 3-way handshake: SYN, SYN-ACK, ACK
05-Security/f2-crop-dos.png

TCP SYN Spoofing Attack
05-Security/f3-crop-dos.png

SYN spoofing versus classic flooding

5 Flooding attacks

5.1 ICMP

Flooding Attacks: ICMP
Note: ICMP is the topic up next.

ICMP flood

5.2 UDP

Flooding Attacks: UDP

UDP flood

5.3 TCP

Flooding Attacks: TCP

TCP SYN flood

6 DDoS

Singe versus multiple attackers

Distributed Denial of Service DDoS Attacks

6.1 Handlers

Attacker can use handlers for efficiency and stealth
05-Security/f4-crop-dos.png

7 Application-based bandwidth attack

7.1 SIP

DoS on a SIP server
05-Security/f5-crop-dos.png

7.2 HTTP

7.2.1 HTTP Flood

Hypertext Transfer Protocol (HTTP) Attacks

HTTP flood

7.2.2 Slowloris

Hypertext Transfer Protocol (HTTP) Attacks

Slowloris

8 Reflection Attacks

Reflection using TCP SYN

DNS reflection attack exploits recursive DNS:

9 Amplification attack

Broadcast to intermediaries who performs reflection attack
05-Security/f7-crop-dos.png

DNS Amplification Attacks

10 Denial-of-service as a service

11 DoS Defenses

11.1 Dos Prevention

11.2 Responding to DoS Attacks

Good Incident Response Plan, example:

  1. Identify type of attack
  2. Have ISP trace packet flow back to source
  3. Implement contingency plan
  4. Update incident response plan

12 TLS

(Transport Layer Security)

IntroNetworks:
http://intronetworks.cs.luc.edu/current2/uhtml/publickey.html#tls

Computer-Networking:
https://www.computer-networking.info/2nd/html/protocols/tls.html

13 Introduction

What is Transport Layer Security?

13.1 Timeline

05-Security/TLS_Timeline_thumb.png

13.2 Purpose

A Secure Channel:

13.3 Network stack

TLS is actually application layer
05-Security/00.png

However, it can behave like a transport layer service

13.4 Protection?

Just wrap your socket:

#!/usr/bin/python3
# -*- coding: utf-8 -*-

import ssl
import base64
import socket

cc = socket.socket(family=socket.AF_INET, type=socket.SOCK_STREAM)
cc.connect(("smtp.gmail.com", 587))

cc.send("helo tester.com\r\n")
cc.send("starttls\r\n")

scc = ssl.wrap_socket(cc)
scc.send("auth login\r\n")

scc.send(base64.b64encode("username") + "\r\n")
scc.send(base64.b64encode("password") + "\r\n")

14 Protocols

TLS Structure

Handshake protocol

Record protocol

14.1 Overview

TLS protocol stack
05-Security/f4-crop-internetsec.png

14.2 Handshake protocol

High level overview
05-Security/TLS-client-server1.png

Pseudo TLS handshake
05-Security/01.png

During the handshake phase, Bob needs to

TLS handshake
05-Security/f6-crop-internetsec.png

RSA handshake
05-Security/03.png
Ks is server’s public key

TLS handshake details

The steps of the real SSL handshake are as follows:

  1. The client sends a list of cryptographic algorithms it supports, along with a client nonce.
  2. From the list, the server chooses a symmetric algorithm (for example, AES), a public key algorithm (for example, RSA with a specific key length), and a MAC algorithm. It sends back to the client its choices, as well as a certificate and a server nonce.
  3. The client verifies the certificate, extracts the server’s public key, generates a Pre-Master Secret (PMS), encrypts the PMS with the server’s public key, and sends the encrypted PMS to the server.
  4. Using the same key derivation function (as specified by the SSL standard), the client and server independently compute the Master Secret (MS) from the PMS and nonces. The MS is then sliced up to generate the two encryption and two MAC keys. Furthermore, when the chosen symmetric cipher employs CBC (such as 3DES or AES), then two Initialization Vectors (IVs)—one for each side of the connection—are also obtained from the MS. Henceforth, all messages sent between client and server are encrypted and authenticated (with the MAC).
  5. The client sends a MAC of all the handshake messages.
  6. The server sends a MAC of all the handshake messages.

The last two steps protect the handshake from tampering.

Timing and computational cost
05-Security/handshake1.png

14.2.1 Cipher options

Many options for public key method (handshake, key exchange, authentication)
05-Security/sub0.png

Many options and for private key choice (data transmission)
05-Security/sub1.png

Many options for integrity as well (data transmission validity)
05-Security/sub2.png

14.3 TLS Record

protocol: data transmission itself
05-Security/02.png

05-Security/f5-crop-internetsec.png

Application layer, but acts like transport
05-Security/protocol.png

14.4 Heartbeat protocol

Serves two purposes

14.5 Alert protocol

14.6 Change Cipher Spec protocol

Purpose of this message is to cause the pending state to be copied into the current state, which updates the cipher suite to be used on this connection.

15 Perfect forward secure?

What happens if the server’s private key is stolen, hacked, or subpoenaed?

15.1 DH

Diffie-Hellman-Merkle to the rescue
05-Security/Diffie-Hellman_Key_Exchange-modified.png

Diffie-Hellman Key Exchange Algorithm
05-Security/04.png

Diffie-Hellman Key Exchange
05-Security/f8-crop-asymmetric.png

Why DH?
And what about authentication??

15.2 Classic vs. DH

RSA
05-Security/ssl_handshake_rsa.png

DH
05-Security/ssl_handshake_diffie_hellman.png

15.3 How?

To make your server perfect forward secure, if you are using python:

SSLContext.set_ciphers(DHE-RSA)

Options include:

DiffieHellman key exchange-based PFSs
(DHE-RSA, DHE-DSA) and

Elliptic curve DiffieHellman-based PFSs
(ECDHE-RSA, ECDHE-ECDSA)

15.4 UDP / SSL

Examples:

15.4.1 VOIP / ZRTP

15.4.2 OpenVPN

https://openvpn.net/community-resources/openvpn-cryptographic-layer/

15.5 IPSec

04-NetworkData.html

Next: 06-NetworkControl.html