Side-channels are the most common attacks!
Previous: 04-NetworkData.html
document.querySelector('video').playbackRate = 1.2
Side-channels are the most common attacks!
Packet filtering firewall stores tables of rules (chains)
**A TCP packet tries to get past the firewall on the way to the bar.**
**Firewall says "hey, you're out of order".**
* 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:
Table of outgoing connections determines which incoming connections are
allowed.
Application level gateways can be:
Network based (e.g., big brother your employees to the
extreme)
* Also called an application proxy
* Acts as a relay of application-level traffic
* User contacts gateway using a TCP/IP application
* User is authenticated
* Gateway contacts application on remote host and relays TCP segments
between server and user
* Must have proxy code for each application
* May restrict application features supported
Host based (e.g., don’t trust your own applications, privacy
firewall)
* Function by determining whether a process should accept any given
connection.
* A host-based application firewall can monitor any application input,
output, and/or system service calls made from, to, or by an
application.
* This is done by examining information passed through system calls
instead of or in addition to a network stack.
* AppArmon or SELinux can do this
* https://github.com/evilsocket/opensnitch (a decent/interesting Linux
implementation of this idea)
* Note: there are a couple older attempts at this idea, but the above
seems to be the cleanest on Linux
Note: In my opinion, one very cool project would be making an open-snitch/little-snitch/zone-alarm like firewall out of SELinux.
A kind of:
https://en.wikipedia.org/wiki/Proxy_server
https://en.wikipedia.org/wiki/SOCKS
* Designed to provide a framework for client-server applications in
TCP/UDP domains to conveniently and securely use the services of a
network firewall
* Client application contacts SOCKS server, authenticates, sends relay
request
* Server evaluates and either establishes or denies the connection
* SOCKS server proxies TCP connections to an arbitrary IP address, and
provides a means for UDP packets to be forwarded.
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
* A Tor user’s SOCKS-aware applications can be configured to direct
their network traffic through a Tor instance’s SOCKS interface, which is
listening on TCP port 9050 (for standalone Tor) or 9150 (for Tor Browser
bundle) at localhost.
* Tor periodically creates virtual circuits through the Tor network
through which it can multiplex and onion-route that traffic to its
destination.
* Once inside a Tor network, the traffic is sent from router to router
along the circuit, ultimately reaching an exit node at which point the
cleartext packet is available and is forwarded on to its original
destination.
* Viewed from the destination, the traffic appears to originate at the
Tor exit node.
* A Tor non-exit relay with a maximum output of 239.69 kbit/s
* Tor’s application independence sets it apart from most other anonymity
networks: it works at the Transmission Control Protocol (TCP) stream
level.
* Applications whose traffic is commonly anonymized using Tor include
Internet Relay Chat (IRC), instant messaging, and World Wide Web
browsing.
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/
https://en.wikipedia.org/wiki/Netfilter
https://www.netfilter.org/
stateless packet filtering (IPv4 and IPv6)
stateful packet filtering (IPv4 and IPv6)
build internet firewalls based on stateless and stateful packet filtering
deploy highly available stateless and stateful firewall clusters
use NAT and masquerading for sharing internet access if you don’t have enough public IP addresses
use NAT to implement transparent proxies
aid the tc and iproute2 systems used to build sophisticated QoS and policy routers
do further packet manipulation (mangling) like altering the TOS/DSCP/ECN bits of the IP header
Much more to come later (below)
Firewall locations and demilitarized zone (DMZ)
IPSec based VPN
Distributed firewall locations
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.
IPtables and netfilter
User-space:
* Iptables resides in what we call the user-space, this is your
interface to the firewall for setting up your firewall rules.
* The same applies to ip6tables, nft, etc.
Kernel:
* netfilter, the framework which iptables configures.
* Netfilter implements a series of ‘hooks’ that inspect packets in the
protocol stack, such as IPv4.
* These hooks allow for kernel modules to interact with them.
* Iptables has a huge list of kernel modules used for its firewalling
capabilities.
* We have everything from tcp and udp to
pkttype (Packet Type).
* In fact if you want to see a list of iptables kernel modules,
type:
sudo cat /proc/net/ip_tables_matches
Hardware / interfaces:
* Network adapters; eth0, eth1, etc.
* Netfilter uses prerouting and postrouting to and from the network
stack to inspect packets sent and received on each interface.
Where in OS?
* Packet inspection is done at the kernel layer with netfilter
* All the firewall rules and tools to manage the firewall reside in the
user-space.
IPtables and netfilter
IPtables and netfilter
IPtables and netfilter
IPtables and netfilter
IPtables and netfilter
IPtables and netfilter
IPtables and netfilter
IPtables and netfilter
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.
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
Netfilter Kernel Hooks
5 netfilter hooks that programs can register with.
As packets progress through the stack, they will trigger the kernel modules that have registered with these hooks.
Hooks that a packet will trigger depends on whether the packet is incoming or outgoing, the packet’s destination, and whether the packet was dropped or rejected at a previous point.
NF_IP_PRE_ROUTING:
NF_IP_LOCAL_IN:
NF_IP_FORWARD:
NF_IP_LOCAL_OUT:
NF_IP_POST_ROUTING:
As you can see, the names of the built-in chains mirror the names of the netfilter hooks they are associated with:
Rules in chains
Rules are also processed in order, often with a catch-all at the
end.
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:
Incoming packets destined for the local system:
PREROUTING -> INPUT
Incoming packets destined to another host:
PREROUTING -> FORWARD -> POSTROUTING
Locally generated packets:
OUTPUT -> POSTROUTING
IPtables and netfilter flow
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:
TCP state tracking: connection
For a stateful firewall:
TCP state tracking: closing
TCP state tracking: client sub-connection
TCP state tracking: server sub-connection
UDP state tracking: “connection”
Watches inverted port numbers.
State Explanation: NEW
* The NEW state tells us that the packet is the first packet that we
see.
* This means that the first packet that the conntrack module sees,
within a specific connection, will be matched.
* For example, if we see a SYN packet and it is the first packet in a
connection that we see, it will match.
* However, the packet may as well not be a SYN packet and still be
considered NEW.
* This may lead to certain problems in some instances, but it may also
be extremely helpful when we need to pick up lost connections from other
firewalls, or when a connection has already timed out, but in reality is
not closed.
State Explanation: ESTABLISHED
* The ESTABLISHED state has seen traffic in both directions and will
then continuously match those packets.
* ESTABLISHED connections are fairly easy to understand.
* The only requirement to get into an ESTABLISHED state is that one host
sends a packet, and that it later on gets a reply from the other
host.
* The NEW state will upon receipt of the reply packet to or through the
firewall change to the ESTABLISHED state.
* ICMP reply messages can also be considered as ESTABLISHED, if we
created a packet that in turn generated the reply ICMP message.
State Explanation: RELATED
* The RELATED state is one of the more tricky states.
* A connection is considered RELATED when it is related to another
already ESTABLISHED connection.
* What this means, is that for a connection to be considered as RELATED,
we must first have a connection that is considered ESTABLISHED.
* The ESTABLISHED connection will then spawn a connection outside of the
main connection.
* The newly spawned connection will then be considered RELATED, if the
conntrack module is able to understand that it is RELATED.
* Some good examples of connections that can be considered as RELATED
are the FTP-data connections that are considered RELATED to the FTP
control port, and the DCC connections issued through IRC.
* This could be used to allow ICMP error messages, FTP transfers and
DCC’s to work properly through the firewall.
* Do note that most TCP protocols and some UDP protocols that rely on
this mechanism are quite complex and send connection information within
the payload of the TCP or UDP data segments, and hence require special
helper modules to be correctly understood.
State Explanation: INVALID
* The INVALID state means that the packet can’t be identified or that it
does not have any state.
* This may be due to several reasons, such as the system running out of
memory or ICMP error messages that do not respond to any known
connections.
* Generally, it is a good idea to DROP everything in this state.
State Explanation: UNTRACKED
* This is the UNTRACKED state.
* In brief, if a packet is marked within the raw table with the NOTRACK
target, then that packet will show up as UNTRACKED in the state
machine.
* This also means that all RELATED connections will not be seen, so some
caution must be taken when dealing with the UNTRACKED connections since
the state machine will not be able to see related ICMP messages et
cetera.
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:
* IPtables and netfilter are the dominant firewall technology in the
Linux world, but there are some other contenders:
https://en.wikipedia.org/wiki/Nftables
* nftables is set to replace much of netfilter (it is indeed
nicer)
* The syntax is a bit different
* nftables is configured via the user-space utility nft, while netfilter
is configured via the utilities iptables, ip6tables, arptables and
ebtables frameworks.
* The phase-out of netfilter is slow.
https://en.wikipedia.org/wiki/PF_(firewall)
* is a BSD based firewall that you may encounter, particularly given the
dominance of BSD-based firewall distributions like pfSense and
OPNSense.
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.
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
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.
Signature approaches
* Match a large collection of known patterns of malicious data against
data stored on a system or in transit over a network
* The signatures need to be large enough to minimize the false alarm
rate, while still detecting a sufficiently large fraction of malicious
data
* Widely used in anti-virus products, network traffic scanning proxies,
and in NIDS
Rule-based heuristic identification
* Involves the use of rules for identifying known penetrations or
penetrations that would exploit known weaknesses
* Rules can also be defined that identify suspicious behavior, even when
the behavior is within the bounds of established patterns of usage
* Typically rules used are specific
* SNORT is an example of a rule-based NIDS
++++++++++++++++++++ Cahoot-05-3
Three main components:
Agent architecture
Sensor types: inline and passive
Passive NIDS sensor
Sensor deployment locations
Attacks suitable for signature detection
* Application layer reconnaissance and attacks
* Transport layer reconnaissance and attacks
* Network layer reconnaissance and attacks
* Unexpected application services
* Policy violations
Attacks suitable for anomaly detection
* Denial-of-service (DoS) attacks
* Scanning
* Worms
Stateful Protocol Analysis (SPA)
* Subset of anomaly detection that compares observed network traffic
against predetermined universal vendor supplied profiles of benign
protocol traffic
* This distinguishes it from anomaly techniques trained with
organization specific traffic protocols
* Understands and tracks network, transport, and application protocol
states to ensure they progress as expected
* A key disadvantage is the high resource use it requires
Typical information logged by a NIDS sensor includes:
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
++++++++++++++++++ Cahoot-05-4
Check these out in class, sort tables by license:
*
https://en.wikipedia.org/wiki/List_of_router_and_firewall_distributions
* https://en.wikipedia.org/wiki/Comparison_of_firewalls
pf is the openbsd firewall
* https://www.openbsd.org/faq/pf/index.html
* https://en.wikipedia.org/wiki/PF_(firewall)
pfSense is a firewall distribution
* https://www.pfsense.org/
* https://en.wikipedia.org/wiki/PfSense
* https://www.pfsense.org/download/ (community edition available as
iso)
* pfSense is an open source firewall/router computer software
distribution based on FreeBSD.
* It is installed on a physical computer or a virtual machine to make a
dedicated firewall/router for a network.
* It can be configured and upgraded through a web-based interface, and
requires no knowledge of the underlying FreeBSD system to manage.
* IDS/IPS systems like SNORT are well-integrated into the platform
OPNsense is a fork of pfSense
* https://docs.opnsense.org/history/thefork.html
* https://en.wikipedia.org/wiki/OPNsense
* https://opnsense.org/
More info on how to set up pfSense and Snort in ra05-Firewall-IPS
https://en.wikipedia.org/wiki/Honeypot_(computing)
(show this link)
Most are server honeypots, but some are clients.
https://en.wikipedia.org/wiki/Client_honeypot
* Client Honeypots are active security devices in search of malicious
servers that attack clients.
* The client honeypot poses as a client and interacts with the server to
examine whether an attack has occurred.
* Often the focus of client honeypots is on web browsers, but any client
that interacts with servers can be part of a client honeypot (for
example ftp, ssh, email, etc.).
Some derived from honeypots, others from actual attack, network, and
malware statistics
* https://norse-corp.com/map/
* https://www.digitalattackmap.com/
* https://cybermap.kaspersky.com/
* https://threatmap.checkpoint.com/ThreatPortal/livemap.html
* https://threatmap.fortiguard.com/
*
https://www.akamai.com/es/es/resources/visualizing-akamai/real-time-web-monitor.jsp?tab=attacks&theme=dark
* https://map.lookingglasscyber.com/
* https://threatbutt.com/map/
* https://talosintelligence.com/fullpage_maps/pulse
*
https://www.sophos.com/en-us/threat-center/threat-monitoring/threatdashboard.aspx
* https://www.fireeye.com/cyber-map/threat-map.html
“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
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
* Dependent on the capacity of the network links connecting a server to
the Internet
* For most organizations this is their connection to their Internet
Service Provider (ISP)
* Overwhelm any legitimate traffic, denying legitimate users access to
the server
System resources
* Aims to overload or crash the network handling software
* Include temporary buffers used to hold arriving packets, tables of
open connections, etc
Application resources
* Typically involves a number of valid requests, which intentionally
consume significant resources (e.g., database query), thus limiting the
ability of the server to respond to requests from other users
Varieties of end users as both attackers and victims
https://en.wikipedia.org/wiki/Denial-of-service_attack
TCP 3-way handshake: SYN, SYN-ACK, ACK
TCP SYN Spoofing Attack
SYN spoofing versus classic flooding
Flooding Attacks: ICMP
Note: ICMP is the topic up next.
ICMP flood
* E.g., ping flood using ICMP echo request
packets
* Traditionally network administrators allow such packets into their
networks because ping is a useful network diagnostic tool
* More recently, block packets to pass through their firewalls.
* So, attackers use other ICMP packet types that are needed correct
operation of TCP/IP
* Filtering some of these critical ICMP packet types would degrade or
break normal TCP/IP network behavior.
* ICMP destination unreachable and time exceeded packets are examples of
such critical packet types.
* Further, because these packets include part of some notional erroneous
packet that supposedly caused the error being reported, they can be made
comparatively large, increasing their effectiveness in flooding the
link.
Flooding Attacks: UDP
UDP flood
* For example, some servers and routers have diagnostic echo services
running
* Uses UDP packets directed to some port number on the target
system
* Spoofed source addresses are normally used if the attack is generated
using a single source system, for the same reasons as with ICMP flood
attacks.
* If multiple systems are used for the attack, often the real addresses
of the compromised, zombie, systems are used.
* When multiple systems are used, the consequences of both the reflected
flow of packets and the ability to identify the attacker are
reduced.
Flooding Attacks: TCP
TCP SYN flood
* Sends TCP packets to the target system
* Total volume of packets is the aim of the attack rather than the
system code
* Effect similar to the SYN spoofing attack, but, it is the total volume
of packets that is the aim of the attack rather than the system
code.
* Check out python code (showed before)!
Singe versus multiple attackers
* All of these flooding attack variants are limited in the total volume
of traffic that can be generated if just a single system is used to
launch the attack, which is also easy to trace
* By using multiple systems, the attacker can scale up the volume of
attack scale
* By directing the attack through intermediaries, the attacker is
further distanced from the target and significantly harder to locate and
identify.
* Indirect attack types that utilize multiple systems include:
* Distributed denial-of-service attacks
* Reflector attacks
* Amplifier attacks
Distributed Denial of Service DDoS Attacks
* Use of multiple systems to generate attacks
* Attacker uses a flaw in operating system or in a common application to
gain access and installs their program on it (zombie)
* Large collections of such systems under the control of one attacker’s
control can be created, forming a botnet
Attacker can use handlers for efficiency and stealth
DoS on a SIP server
Hypertext Transfer Protocol (HTTP) Attacks
HTTP flood
* Bombards Web servers with HTTP requests
* Consumes considerable resources
* Spidering: Bots starting from a given HTTP link and following all
links on the provided Web site recursively
Hypertext Transfer Protocol (HTTP) Attacks
Slowloris
* HTTP specs state a blank line indicates the end of request headers and
the beginning of the payload, if any.
* Once the entire request is received, the Web server may then respond
by sending the object.
* Slowloris sends an incomplete request that does not include the
terminating newline sequence.
* Then, send additional header lines to keep the connection alive, but
never send terminating newline sequence.
* Web server keeps the connection open, expecting more information to
complete the request.
* Eventually consumes Web server’s connection capacity
* Utilizes legitimate HTTP traffic, not malformed or buggy
* Existing intrusion detection and prevention solutions that rely on
signatures to detect attacks will generally not recognize
Slowloris
* Can you easily program a bot to perform this attack?
Reflection using TCP SYN
* A variant of reflection attack uses TCP SYN packets and exploits the
normal three-way handshake used to establish a TCP connection.
* The attacker sends a number of SYN packets with spoofed source
addresses to the chosen intermediaries.
* In turn the intermediaries respond with a SYN-ACK packet to the
spoofed source address, which is actually the target system.
* The attacker uses this attack with a number of intermediaries, to
avoid detection and bandwidth constraints.
* The aim is to generate high enough volumes of packets to flood the
link to the target system.
* The target system will respond with a RST packet for any that get
through, but by then the attack has already succeeded in overwhelming
the target’s network link.
DNS reflection attack exploits recursive DNS:
* Normal on left
* Attack on right
* (port 7 is echo)
Broadcast to intermediaries who performs reflection attack
DNS Amplification Attacks
* Example: Use packets directed at a legitimate DNS server as the
intermediary system, with the source address spoofed as the
victim’s
* Attacker creates a series of DNS requests containing the spoofed
source address of the target system
* Exploit DNS behavior to convert a small request to a much larger
response of a big DNS resource record (amplification)
* Target is flooded with larger responses
* Basic defense against this attack is to prevent the use of spoofed
source addresses
Good Incident Response Plan, example:
* Details on how to contact technical personal for ISP
* Needed to impose traffic filtering upstream
* Details of how to respond to the attack
(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
What is Transport Layer Security?
* Probably the Internet’s most important security protocol
* Designed over 20 years ago by Netscape for Web transactions (Back
then, called Secure Sockets Layer)
* But used for just about everything you can think of: (HTTP, SSL-VPNs,
E-mail, Voice/video, IoT, etc)
* Maintained by the Internet Engineering Task Force
* Now at version 1.2
A Secure Channel
* Client connects to a known server (e.g., it has the domain name)
* Server is (almost) always authenticated as part of TLS
* Client may or may not be authenticated by TLS; often authenticated by
the application, e.g., with a password
* After setup, data is encrypted and authenticated, though what
“authenticated” means to the server is fuzzy
TLS is actually application layer
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")TLS Structure
Handshake protocol
* Establish shared keys (typically using public key cryptography)
* Negotiate algorithms, modes, parameters
* Authenticate one or both sides
Record protocol
* Carry individual messages
* Protected under symmetric keys
TLS protocol stack
High level overview
Pseudo TLS handshake
During the handshake phase, Bob needs to
* establish a TCP connection with Alice,
* verify that Alice is really Alice, and
* send Alice a master secret key, which will be used by both Alice and
Bob to generate all the symmetric keys they need for the SSL
session.
* because the certificate has been certified by a CA, Bob knows for sure
that the public key in the certificate belongs to Alice.
* Bob then generates a Master Secret (MS) (which will only be used for
this SSL session), encrypts the MS with Alice’s public key to create the
Encyrpted Master Secret (EMS), and sends the EMS to Alice.
* Alice decrypts the EMS with her private key to get the MS.
* After this phase, both Bob and Alice (and no one else) know the master
secret for this SSL session.
TLS handshake
RSA handshake
* Ks is server’s public key
TLS handshake details
* SSL does not mandate that Alice and Bob use a specific symmetric key
algorithm, a specific public-key algorithm, or a specific MAC.
* Instead, SSL allows Alice and Bob to agree on the cryptographic
algorithms at the beginning of the SSL session, during the handshake
phase.
* During the handshake phase, Alice and Bob send nonces to each other,
which are used in the creation of the session keys:
* EB = session encryption key for data sent from Bob to
Alice
* MB = session MAC key for data sent from Bob to Alice
* EA = session encryption key for data sent from Alice to
Bob
* MA = session MAC key for data sent from Alice to Bob
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
Many options for public key method (handshake, key exchange,
authentication)
Many options and for private key choice (data transmission)
Many options for integrity as well (data transmission validity)
protocol: data transmission itself
Application layer, but acts like transport
Serves two purposes
* First, it assures the sender that the recipient is still alive, even
though there may not have been any activity over the underlying TCP
connection for a while.
* Second, the heartbeat generates activity across the connection during
idle periods, which avoids closure by a firewall that does not tolerate
idle connections.
What happens if the server’s private key is stolen, hacked, or subpoenaed?
Diffie-Hellman-Merkle to the rescue
Diffie-Hellman Key Exchange Algorithm
Diffie-Hellman Key Exchange
Why DH?
* and what about authentication??
RSA
DH
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)examples:
https://openvpn.net/community-resources/openvpn-cryptographic-layer/
Next: 06-NetworkControl.html