DDoS
Monitoring/Mitigation
using fastnetmon and ExaBGP
(Dan Dargel/Michael Hare)
2015-11-17
 University of Wisconsin-Platteville
◦ ~8900 students and ~1000 staff
 Network Architect
◦ Design, Implementation, and Operation of campus
networks including fiber and copper infrastructure
 Employed fulltime at UW-Platteville since 1993
Dan Dargel
 There are many forms of DoS attacks, too many to discuss
here. Many different tools are needed to mitigate them.
 We will discuss how we handle the most common form
attack we have experienced
◦ Distributed DoS
◦ More specifically Amplified or
Distributed Reflective DoS (DRDoS)
Spoofed request traffic results in large unsolicited response traffic
from legitimate hosts (primarily UDP)
Denial of Service (DoS) Attacks
 First attacks were small and brief but were blocked by the firewall. They
primarily went unnoticed and didn’t show on traffic graphs.
 As attacks grew some started to briefly knock down the firewall. These were
often misdiagnosed or attributed to other factors. Obtaining evidence of an
attack and its nature was difficult.
 As scale and duration increased, critical outages occurred and were identified,
but there were not the means to quickly mitigate the attacks.
 Later, suspicions were confirmed that the DRDoS (Distributed Reflective DoS)
attacks were gamers trying to knock other gamers out of the game. No services
were directly targeted, but infrastructure fell down causing outages.
DDoS Attack Growth we Experienced
 DDoS attacks have grown in scale and frequency
 DRDoS has created many times larger attacks
◦ Tens to hundreds of thousands of hosts, Mpps, and Gbps
 Although firewalls block packets, it can’t handle the
flows/sec and starts to fall down.
 WAN links may become saturated
--What in your infrastructure will fall down first?
DDoS Attacks
 DoS attacks are about resource exhaustion
 Know where your resource limits/bottlenecks are
◦ WAN bandwidth
◦ Firewall/IPS flows/sec, pps, bps
◦ Router/Switch specs
◦ DNS server queries/sec, cpu, bps
◦ Logging rates
 Anything stateful or having a table may become
exhausted
Know/learn your limits
 Paloalto PA-5050 (Active/Passive HA)
◦ 10Gb/s Firewall throughput
◦ 5Gb/s Threat Protect throughput
◦ Normally < 2.6Gbps for UWPlatt
◦ 2M max sessions
◦ Normally <150k for UWPlatt
◦ 120k new sessions/sec
 Log rate of inbound denys may be overwhelming
◦ (Consider not logging inbound traffic that is normally denied which is
destined to user endpoints)
◦ But it may reduce your visibility of attacks
Firewall specs
 Monitor your network to establish a normal baseline
 Determine thresholds to detect abnormalities
◦ They may differ by time of day, or year, or device
 Establish monitoring/alerts/logs to know when you are or
were under attack and to determine the nature of the attack
 Monitoring needs to be realtime and fine granularity.
 Some interactive troubleshooting tools:
◦ iftop, dnstop, parse_fw_traffic w/report interval
Monitor your network
 Providers and customers need to communicate actionable
information in near realtime.
 Providers need to implement means to address attacks that
customers can use/trigger/opt into.
 Providers need to police inbound customer traffic for IP
spoofing and potential attack traffic.
 Customers need to police their networks for botted systems
and address outbound attacks and address spoofing. Block
spoofing with ACLs/URPF/Policies
Providers and Customers need to
work together and communicate
 http://bcop.nanog.org/index.php/DDoS-DoS-attack-BCOP
◦ Details what to do before/during/after an attack
◦ Lists some tools
A great resource, Read it!
 Incorporate potential for DDoS attack into network
design and addressing
◦ Location and roles of DNS servers
◦ Hierarchy of firewalls and routers
◦ Segregation so that an attack on one area may not impact
another
◦ Datacenters
◦ DNS servers
◦ Residence networks
◦ Academic networks
◦ Business office networks
◦ Retail/Operations networks
Network Architechture
 Cloud DDoS scrubbing services $$
◦ Route service thru vendor to scrub attack traffic and tunnel legit traffic to server
◦ Use for determined attacks. May need on retainer. Setup architecture in advance.
 Soak up the attack $$$
◦ Increase the scale, size, bandwidth of service to handle all attack traffic
◦ Distribute service to many locations. Enlist aid of peers.
 Use DDoS mitigation appliances $
◦ Doesn’t protect your WAN link bandwidth or ISP
 Use network infrastructure tools (from ISP); very scalable
◦ BGP blackhole
◦ BGP flowspec
◦ ACLs/Rate limits
◦ Use for common but not coordinated and determined attacks
◦ Means accepting some collateral damage or objective of attack
Ways to mitigate attacks
Distributed Reflective DoS
(DRDoS)
Requests with source IP address of victim spoofed
Distributed Reflected DoS
(DRDoS)
Protocol
Bandwidth
Amplification Factor
Vulnerable Command Protocol/Port
DNS 28 to 54 see: TA13-088A [4] UDP/53
NTP 556.9 see: TA14-013A [5] UDP/123
SNMPv2 6.3 GetBulk request UDP/161
NetBIOS 3.8 Name resolution UDP/137
SSDP 30.8 SEARCH request UDP/1900
CharGEN 358.8
Character generation
request
UDP/19
QOTD 140.3 Quote request UDP/17
BitTorrent 3.8 File search
Kad 16.3 Peer list exchange
Quake Network Protocol 63.9 Server info exchange
Steam Protocol 5.5 Server info exchange
Multicast DNS (mDNS) 2 to 10 Unicast query UDP/5353
RIPv1 131.24 Malformed request UDP/520
Portmap (RPCbind) 7 to 28 Malformed request UDP/111
Source: https://www.us-cert.gov/ncas/alerts/TA14-017A
Mitigation
 ACLs/Policers on ISP routers
◦ SSDP
◦ Chargen
◦ NTP
◦ DNS?
◦ UDP fragments?
 Attack detection and response
◦ BGP blackhole (RTBH, RealTime BlackHole)
◦ BGP flowspec
Fastnetmon/ExaBGP Architecture
DDoS attack
DDoS attack mitigation
fastnetmon
 Supports many capture/flow methods
◦ NetFlow, IPFIX, sFLOW, SnabbSwitch, netmap, PF_RING, PCAP
 Incoming and Outgoing traffic
◦ On same interface or two different mirrored interfaces
 Triggers on per IP thresholds for packets/bytes/flows per second
 Integration with ExaBGP for blackhole routes or flowspec for well
know attacks
 Detects a DDoS attack in a few seconds
 Can support rates of up to 10Gbps and 12Mpps with certain hardware
and netmap. Much more with flow based methods, but are slower to
detect.
 Provides flow summary and TCPdump like trace, can collect pcap
dumps of attack traffic
 Has had significant enhancements over the last 6 months
 syn_flood
◦ TCP packets with enabled SYN flag
 udp_flood
 icmp_flood
 ip_fragmentation_flood
◦ IP packets with MF flag set or with non zero fragment
offset
Fastnetmon
Supported attack detection
/etc/fastnetmon.confenable_ban = on
ban_time = 3600
ban_for_pps = on
ban_for_bandwidth = on
ban_for_flows = on
threshold_pps = 40000
threshold_mbps = 500
threshold_flows = 2000
ban_details_records_count = 1000
redis_port = 6379
redis_host = 127.0.0.1
check_period = 1
sort_parameter = packets
max_ips_in_list = 9
notify_script_path = /usr/local/bin/notify_about_attack.sh
redis_enabled = no
interfaces = p2p1
netflow = off
netflow_port = 2055
netflow_host = 0.0.0.0
sflow = off
sflow_port = 6343
sflow_host = 0.0.0.0
mirror = on
mirror_netmap = off
pcap = off
average_calculation_time = 5
enable_connection_tracking = on
enable_pf_ring_zc_mode = off
process_incoming_traffic = on
process_outgoing_traffic = on
/etc/networks_list137.104.0.0/16
/etc/networks_whitelist
fastnetmon_client
FastNetMon v1.0 FastVPS Eesti OU (c) VPS and dedicated: http://FastVPS.host
IPs ordered by: packets
Incoming traffic 10345 pps 52 mbps 641 flows
137.104.255.235 549 pps 5 mbps 0 flows
137.104.241.115 89 pps 0 mbps 0 flows
137.104.224.134 225 pps 2 mbps 0 flows
137.104.232.80 352 pps 0 mbps 8 flows
137.104.230.0 340 pps 0 mbps 11 flows
137.104.226.91 311 pps 0 mbps 21 flows
137.104.174.178 333 pps 2 mbps 1 flows
137.104.231.219 318 pps 3 mbps 1 flows
137.104.234.112 288 pps 1 mbps 5 flows
Outgoing traffic 9048 pps 20 mbps 595 flows
137.104.255.235 245 pps 0 mbps 0 flows
137.104.232.80 352 pps 0 mbps 9 flows
137.104.230.0 340 pps 0 mbps 11 flows
137.104.174.178 292 pps 2 mbps 1 flows
137.104.213.201 297 pps 2 mbps 1 flows
137.104.48.239 262 pps 1 mbps 2 flows
137.104.249.195 273 pps 0 mbps 6 flows
137.104.238.83 268 pps 0 mbps 12 flows
137.104.241.115 35 pps 0 mbps 0 flows
Internal traffic 0 pps 0 mbps
Other traffic 0 pps 0 mbps
Screen updated in: 0 sec 376762 microseconds
Traffic calculated in: 0 sec 70307 microseconds
Total amount of not processed packets: 16904
Packets received: 6973552161
Packets dropped: 0
Packets dropped: 0.0 %
Configuration params:
We call ban script: yes
Packets per second: 20000
Mbps per second: 500
Flows per second: 2000
Ban list:
137.104.110.213/46649 pps incoming at 17_09_15_15:25:12
/var/log/fastnetmon_attacks/…
IP: 137.104.247.176
Initial attack power: 21209 packets per second
Peak attack power: 21209 packets per second
Attack direction: incoming
Attack protocol: udp
Total incoming traffic: 195 mbps
Total outgoing traffic: 0 mbps
Total incoming pps: 21209 packets per second
Total outgoing pps: 34 packets per second
Total incoming flows: 463 flows per second
Total outgoing flows: 1 flows per second
Average incoming traffic: 195 mbps
Average outgoing traffic: 0 mbps
Average incoming pps: 21209 packets per second
Average outgoing pps: 34 packets per second
Average incoming flows: 463 flows per second
Average outgoing flows: 1 flows per second
Incoming tcp traffic: 0 mbps
Outgoing tcp traffic: 0 mbps
Incoming tcp pps: 0 packets per second
Outgoing tcp pps: 0 packets per second
Incoming udp traffic: 785 mbps
Outgoing udp traffic: 0 mbps
Incoming udp pps: 85145 packets per second
Outgoing udp pps: 51 packets per second
Incoming icmp traffic: 0 mbps
Outgoing icmp traffic: 0 mbps
Incoming icmp pps: 0 packets per second
Outgoing icmp pps: 0 packets per second
2015-05-03 23:49:39.598987 61.161.79.181:19 > 137.104.247.176:29864 protocol: udp packets: 1 size: 1514 bytes sample ratio: 1
2015-05-03 23:49:39.599023 119.97.206.251:19 > 137.104.247.176:29864 protocol: udp packets: 1 size: 1514 bytes sample ratio: 1
2015-05-03 23:49:39.599027 61.128.110.198:0 > 137.104.247.176:0 protocol: udp packets: 1 size: 1514 bytes sample ratio: 1
2015-05-03 23:49:39.599027 60.190.2.90:19 > 137.104.247.176:29864 protocol: udp packets: 1 size: 1514 bytes sample ratio: 1
2015-05-03 23:49:39.599031 61.183.40.34:0 > 137.104.247.176:0 protocol: udp packets: 1 size: 1514 bytes sample ratio: 1
2015-05-03 23:49:39.599031 119.97.206.251:0 > 137.104.247.176:0 protocol: udp packets: 1 size: 690 bytes sample ratio: 1
2015-05-03 23:49:39.599035 60.190.2.90:0 > 137.104.247.176:0 protocol: udp packets: 1 size: 1514 bytes sample ratio: 1
2015-05-03 23:49:39.599037 60.190.2.90:0 > 137.104.247.176:0 protocol: udp packets: 1 size: 1514 bytes sample ratio: 1
2015-05-03 23:49:39.599039 60.190.2.90:0 > 137.104.247.176:0 protocol: udp packets: 1 size: 1514 bytes sample ratio: 1
2015-05-03 23:49:39.599041 60.190.2.90:0 > 137.104.247.176:0 protocol: udp packets: 1 size: 727 bytes sample ratio: 1
/etc/exabgp/exabgp.conf# exabgp.conf
# Used to inject blackhole routes into uwsys.net within 137.104.0.0/16
#
# Blackhole Communities:
# uwsysnet_blackhole 3128:911 blackhole this route in AS3128 and upstreams
# uwsysnet_blackhole_internet 3128:912 blackhole this route in upstreams but NOT AS3128#
# Well-Known Communities:
# no-export 65535:65281 do not advertise to any eBGP peers
# no-advertise 65535:65282 do not advertise to any BGP peer
# local-as 65535:65283 do no advertise this route to peers outside the local as
group sysnet_blackhole {
local-as 65060;
peer-as 3128;
router-id 143.235.40.27;
local-address 143.235.40.27;
hold-time 180;
graceful-restart 1200;
family {
ipv4 unicast;
}
static {
# route 10.10.10.1/32 next-hop 192.0.2.1 community 3128:911;
# route 10.10.01.1/32 next-hop 192.0.2.1 community [ 3128:911 65535:65281 ];
# The next line is used to indicate where to automatically add routes at, do not edit it!
# INSERT_NEW
# 2015-09-04 21:46:31 - auto-blachole incoming
route 137.104.212.131/32 next-hop 192.0.2.1 community [3128:911];
# 2015-07-08 03:07:18 - auto-blachole incoming
# 2015-07-08 04:16:18 - route 137.104.231.0/32 next-hop 192.0.2.1 community [3128:911];
}
neighbor 143.235.32.14 {
}
neighbor 143.235.32.15 {
}
}
 QUIC protocol (trips pps limit)
◦ Recommend to trigger on flows/sec and set high Mbps
and pps thresholds
 Whitelist DNS and other servers or just generate
alerts only and use ExaBGP manually
 Is the attack actually backscatter from an attack
on someone else?
False Positives
 Create ACL like rules that can be advertised to upstream providers
 Providers can implement filters in their core or at their edge to
block/rate limit traffic
 Rule action can potentially be:
◦ Accept
◦ Discard
◦ Rate-limit
◦ Redirect
◦ Redirect-next-hop
◦ Copy
◦ Mark
◦ Action sample|terminal|sample-terminal
BGP flowspec
/etc/fastnetmon.conf (flowspec)
# This options are mandatory for Flow Spec attack detector
collect_attack_pcap_dumps = on
process_pcap_attack_dumps_with_dpi = on
exabgp = on
exabgp_command_pipe = /var/run/exabgp.cmd
exabgp_community = 65001:666
exabgp_next_hop = 10.0.3.114
exabgp_flow_spec_announces = on
# Please switch off unicast BGP announces with ExaBGP because they are not compatible with Flow Spec
exabgp_announce_whole_subnet = no
exabgp_announce_host = no
 Currently supports only most popular amplification attack types
◦ DNS amplification (drop all udp traffic originating from 53 port)
◦ NTP amplification (drop all udp traffic originating from 123 port)
◦ SSDP amplification (drop all udp traffic originating from 1900 port)
◦ SNMP amplification (drop all udp traffic originating from 161 port)
Fastnetmon/ExaBGP Architecture
(flowspec)
/etc/exabgp/exabgp.conf (flowspec)
# flowspec syntax:
# flow {
# route give-me-a-name
# route-distinguisher|rd 255.255.255.255:65535|65535:65536|65536:65535; (optional)
# next-hop 1.2.3.4; (to use with redirect-to-nexthop)
# match {
# source 10.0.0.0/24;
# source ::1/128/0;
# destination 10.0.1.0/24;
# port 25;
# source-port >1024
# destination-port =80 =3128 >8080&<8088;
# protocol [ udp tcp ]; (ipv4 only)
# next-header [ udp tcp ]; (ipv6 only)
# fragment [ not-a-fragment dont-fragment is-fragment first-fragment last-fragment ]; (ipv4 only)
# packet-length >200&<300 >400&<500;
# flow-label >100&<2000; (ipv6 only)
# }
# then {
# accept;
# discard;
# rate-limit 9600;
# redirect 30740:12345;
# redirect 1.2.3.4:5678;
# redirect 1.2.3.4;
# redirect-next-hop;
# copy 1.2.3.4;
# mark 123;
# action sample|terminal|sample-terminal;
# }
# }
# }
#
# one or more match term, one action
# fragment code is totally untested
/etc/exabgp/exabgp.conf (flowspec)
group sysnet_flowspec {
local-as 65060;
peer-as 3128;
router-id 143.235.40.27;
local-address 143.235.40.27;
hold-time 180;
graceful-restart 1200;
family {
ipv4 flow;
}
flow {
route {
match {
source 205.213.14.55/32;
destination 137.104.167.144/32;
source-port =443;
protocol tcp;
}
then {
discard;
}
}
}
neighbor 143.235.40.19 {
}
neighbor 143.235.40.18 {
}
}
 Much of the attack traffic may be fragmented
packets
 Non-initial fragments may be 2/3 to 3/4 of the
traffic.
 SRC/DST ports of non-initial fragments can’t be
identified in a stateless manner, making ACLs and
flowspec rules difficult, but rate limits and QoS
may help
Non-initial fragments
 Separate Authoritative vs Recursive resolver DNS
servers
 Mix of offsite and onsite authoritative DNS servers
◦ Be prepared to isolate them
◦ Don’t allow inbound access to all of your onsite DNS
servers
 Require clients to use your onsite recursive
resolvers (US-CERT TA15-240A)
 Use servers that are hardened and have
mitigation features
DNS infrastructure
 DDoS Mitigation
◦ http://bcop.nanog.org/index.php/DDoS-DoS-attack-BCOP
 BGP Blackhole (RTBH) and flowspec
◦ http://www.cisco.com/web/about/security/intelligence/blackhole.pdf
◦ https://kb.wisc.edu/uwsysnet/search.php?q=blackhole&cat=0
◦ https://www.nanog.org/sites/default/files/wed.general.trafficdiversion.serodio.10.pdf
 Fastnetmon:
◦ https://ripe71.ripe.net/wp-content/uploads/presentations/17-RIPE71_new_slides.pdf
◦ https://github.com/pavel-odintsov/fastnetmon
◦ https://github.com/pavel-odintsov/fastnetmon/blob/master/docs/EXABGP_INTEGRATION.md
◦ https://github.com/pavel-odintsov/fastnetmon/blob/master/docs/BGP_FLOW_SPEC.md
 ExaBGP
◦ https://github.com/Exa-Networks/exabgp
◦ https://www.m00nie.com/?s=exabgp
 DNS
◦ https://www.us-cert.gov/ncas/alerts/TA14-017A
 Firewall on Demand
◦ https://www.terena.org/activities/tf-noc/meeting5/slides/20120216-firewall.pdf
◦ http://www.terena.org/activities/tf-msp/meetings/20141127/slides/Yannis.pptx
Resources
/usr/local/bin/notify_about_attack.sh
#!/usr/bin/env bash
# Blackhole and IP address and notify the NOC
# $1 client_ip_as_string
# $2 data_direction
# $3 pps_as_string
# $4 action (ban or unban)
email_notify=“noc@somewhere.edu"
if [ "$4" = "unban" ]; then
# Unban actions if used
/usr/local/sbin/auto-blackhole remove:$1
exit 0
fi
if [ "$4" = "ban" ]; then
cat | mail -s "FastNetMon Guard: IP $1 $2 attack with power $3 pps" $email_notify;
# You can add ban code here!
exit 0
fi
if [ "$4" == "attack_details" ]; then
cat | mail -s "FastNetMon Guard: IP $1 $2 attack with power $3 pps" $email_notify;
/usr/local/sbin/auto-blackhole $1 $2
exit 0
fi
/usr/local/sbin/auto-blackhole
#!/usr/bin/perl
# This script will prompt for and IP to be blackholed.
#
# It will check the IP is valid
# It will blackhole traffic to this IP upsteams too by announcing transit
# provider communities too.
#
# It will also mail the NOC team when a prefix is announced and exabgp
# has been restarted.
#
# Blackhole Communities:
# uwsysnet_blackhole 3128:911 blackhole this route in AS3128 and upstreams
# uwsysnet_blackhole_internet 3128:912 blackhole this route in upstreams but NOT AS3128
# Transit_A - xxx:xxx
# Transit_B - xxx:xxx
#
# Well-Known communities
# no-export - 65535:65281 # do not advertise to any eBGP peers
# no-advertise - 65535:65282 # do not advertise to any BGP peer
# local-as - 65535:65283 # do not advertise this route to peers outside the local as
#
# If parameters are IP-addr Comment, then ask no questions
#
# Originally from www.m00nie.com
#
##############################################
# Some packages we use
use NetAddr::IP;
use Data::Validate::IP;
use Tie::File;
use Net::SMTP::Multipart;
use File::Basename;
use POSIX qw/strftime/;
# This is the exaBGP config file location
$exabgpConf = "/etc/exabgp/exabgp.conf";
# Hash we use to validate BGP subnets
my %prefix;
######################################################
/usr/local/sbin/exabgp_reload
#!/bin/bash
# This script should read the PID of exabgp from a file
# then check if that PID is running and reload it :)
#
# Originally from www.m00nie.com
PID_FILE=/var/run/exaBGP/exabgp_PID
if [ -f "${PID_FILE}" ]; then
# The file exists so read the PID
PID=`head -n 1 $PID_FILE`
# Check is the process is actuall running
if [ -n "`ps -p ${PID} | grep ${PID}`" ]; then
echo exaBGP is already running [$PID].
# It is so lets reload the config :)
echo sending sighup to reload config...
# Use below for exaBGP < 3.2 (Thanks to Roberto Saavedra for noting this)
# kill -SIGHUP $PID
kill -SIGUSR1 $PID
echo Reload complete
exit
else
# Shouldnt really get here
echo PID file exists but the PID is not running!
exit
fi
fi
# No PID file
echo No PID file found at $PID_FILE
9534715

9534715

  • 1.
    DDoS Monitoring/Mitigation using fastnetmon andExaBGP (Dan Dargel/Michael Hare) 2015-11-17
  • 2.
     University ofWisconsin-Platteville ◦ ~8900 students and ~1000 staff  Network Architect ◦ Design, Implementation, and Operation of campus networks including fiber and copper infrastructure  Employed fulltime at UW-Platteville since 1993 Dan Dargel
  • 3.
     There aremany forms of DoS attacks, too many to discuss here. Many different tools are needed to mitigate them.  We will discuss how we handle the most common form attack we have experienced ◦ Distributed DoS ◦ More specifically Amplified or Distributed Reflective DoS (DRDoS) Spoofed request traffic results in large unsolicited response traffic from legitimate hosts (primarily UDP) Denial of Service (DoS) Attacks
  • 4.
     First attackswere small and brief but were blocked by the firewall. They primarily went unnoticed and didn’t show on traffic graphs.  As attacks grew some started to briefly knock down the firewall. These were often misdiagnosed or attributed to other factors. Obtaining evidence of an attack and its nature was difficult.  As scale and duration increased, critical outages occurred and were identified, but there were not the means to quickly mitigate the attacks.  Later, suspicions were confirmed that the DRDoS (Distributed Reflective DoS) attacks were gamers trying to knock other gamers out of the game. No services were directly targeted, but infrastructure fell down causing outages. DDoS Attack Growth we Experienced
  • 5.
     DDoS attackshave grown in scale and frequency  DRDoS has created many times larger attacks ◦ Tens to hundreds of thousands of hosts, Mpps, and Gbps  Although firewalls block packets, it can’t handle the flows/sec and starts to fall down.  WAN links may become saturated --What in your infrastructure will fall down first? DDoS Attacks
  • 6.
     DoS attacksare about resource exhaustion  Know where your resource limits/bottlenecks are ◦ WAN bandwidth ◦ Firewall/IPS flows/sec, pps, bps ◦ Router/Switch specs ◦ DNS server queries/sec, cpu, bps ◦ Logging rates  Anything stateful or having a table may become exhausted Know/learn your limits
  • 7.
     Paloalto PA-5050(Active/Passive HA) ◦ 10Gb/s Firewall throughput ◦ 5Gb/s Threat Protect throughput ◦ Normally < 2.6Gbps for UWPlatt ◦ 2M max sessions ◦ Normally <150k for UWPlatt ◦ 120k new sessions/sec  Log rate of inbound denys may be overwhelming ◦ (Consider not logging inbound traffic that is normally denied which is destined to user endpoints) ◦ But it may reduce your visibility of attacks Firewall specs
  • 8.
     Monitor yournetwork to establish a normal baseline  Determine thresholds to detect abnormalities ◦ They may differ by time of day, or year, or device  Establish monitoring/alerts/logs to know when you are or were under attack and to determine the nature of the attack  Monitoring needs to be realtime and fine granularity.  Some interactive troubleshooting tools: ◦ iftop, dnstop, parse_fw_traffic w/report interval Monitor your network
  • 9.
     Providers andcustomers need to communicate actionable information in near realtime.  Providers need to implement means to address attacks that customers can use/trigger/opt into.  Providers need to police inbound customer traffic for IP spoofing and potential attack traffic.  Customers need to police their networks for botted systems and address outbound attacks and address spoofing. Block spoofing with ACLs/URPF/Policies Providers and Customers need to work together and communicate
  • 10.
     http://bcop.nanog.org/index.php/DDoS-DoS-attack-BCOP ◦ Detailswhat to do before/during/after an attack ◦ Lists some tools A great resource, Read it!
  • 11.
     Incorporate potentialfor DDoS attack into network design and addressing ◦ Location and roles of DNS servers ◦ Hierarchy of firewalls and routers ◦ Segregation so that an attack on one area may not impact another ◦ Datacenters ◦ DNS servers ◦ Residence networks ◦ Academic networks ◦ Business office networks ◦ Retail/Operations networks Network Architechture
  • 12.
     Cloud DDoSscrubbing services $$ ◦ Route service thru vendor to scrub attack traffic and tunnel legit traffic to server ◦ Use for determined attacks. May need on retainer. Setup architecture in advance.  Soak up the attack $$$ ◦ Increase the scale, size, bandwidth of service to handle all attack traffic ◦ Distribute service to many locations. Enlist aid of peers.  Use DDoS mitigation appliances $ ◦ Doesn’t protect your WAN link bandwidth or ISP  Use network infrastructure tools (from ISP); very scalable ◦ BGP blackhole ◦ BGP flowspec ◦ ACLs/Rate limits ◦ Use for common but not coordinated and determined attacks ◦ Means accepting some collateral damage or objective of attack Ways to mitigate attacks
  • 13.
    Distributed Reflective DoS (DRDoS) Requestswith source IP address of victim spoofed
  • 14.
    Distributed Reflected DoS (DRDoS) Protocol Bandwidth AmplificationFactor Vulnerable Command Protocol/Port DNS 28 to 54 see: TA13-088A [4] UDP/53 NTP 556.9 see: TA14-013A [5] UDP/123 SNMPv2 6.3 GetBulk request UDP/161 NetBIOS 3.8 Name resolution UDP/137 SSDP 30.8 SEARCH request UDP/1900 CharGEN 358.8 Character generation request UDP/19 QOTD 140.3 Quote request UDP/17 BitTorrent 3.8 File search Kad 16.3 Peer list exchange Quake Network Protocol 63.9 Server info exchange Steam Protocol 5.5 Server info exchange Multicast DNS (mDNS) 2 to 10 Unicast query UDP/5353 RIPv1 131.24 Malformed request UDP/520 Portmap (RPCbind) 7 to 28 Malformed request UDP/111 Source: https://www.us-cert.gov/ncas/alerts/TA14-017A
  • 15.
    Mitigation  ACLs/Policers onISP routers ◦ SSDP ◦ Chargen ◦ NTP ◦ DNS? ◦ UDP fragments?  Attack detection and response ◦ BGP blackhole (RTBH, RealTime BlackHole) ◦ BGP flowspec
  • 16.
  • 17.
  • 18.
  • 19.
    fastnetmon  Supports manycapture/flow methods ◦ NetFlow, IPFIX, sFLOW, SnabbSwitch, netmap, PF_RING, PCAP  Incoming and Outgoing traffic ◦ On same interface or two different mirrored interfaces  Triggers on per IP thresholds for packets/bytes/flows per second  Integration with ExaBGP for blackhole routes or flowspec for well know attacks  Detects a DDoS attack in a few seconds  Can support rates of up to 10Gbps and 12Mpps with certain hardware and netmap. Much more with flow based methods, but are slower to detect.  Provides flow summary and TCPdump like trace, can collect pcap dumps of attack traffic  Has had significant enhancements over the last 6 months
  • 20.
     syn_flood ◦ TCPpackets with enabled SYN flag  udp_flood  icmp_flood  ip_fragmentation_flood ◦ IP packets with MF flag set or with non zero fragment offset Fastnetmon Supported attack detection
  • 21.
    /etc/fastnetmon.confenable_ban = on ban_time= 3600 ban_for_pps = on ban_for_bandwidth = on ban_for_flows = on threshold_pps = 40000 threshold_mbps = 500 threshold_flows = 2000 ban_details_records_count = 1000 redis_port = 6379 redis_host = 127.0.0.1 check_period = 1 sort_parameter = packets max_ips_in_list = 9 notify_script_path = /usr/local/bin/notify_about_attack.sh redis_enabled = no interfaces = p2p1 netflow = off netflow_port = 2055 netflow_host = 0.0.0.0 sflow = off sflow_port = 6343 sflow_host = 0.0.0.0 mirror = on mirror_netmap = off pcap = off average_calculation_time = 5 enable_connection_tracking = on enable_pf_ring_zc_mode = off process_incoming_traffic = on process_outgoing_traffic = on
  • 22.
  • 23.
    fastnetmon_client FastNetMon v1.0 FastVPSEesti OU (c) VPS and dedicated: http://FastVPS.host IPs ordered by: packets Incoming traffic 10345 pps 52 mbps 641 flows 137.104.255.235 549 pps 5 mbps 0 flows 137.104.241.115 89 pps 0 mbps 0 flows 137.104.224.134 225 pps 2 mbps 0 flows 137.104.232.80 352 pps 0 mbps 8 flows 137.104.230.0 340 pps 0 mbps 11 flows 137.104.226.91 311 pps 0 mbps 21 flows 137.104.174.178 333 pps 2 mbps 1 flows 137.104.231.219 318 pps 3 mbps 1 flows 137.104.234.112 288 pps 1 mbps 5 flows Outgoing traffic 9048 pps 20 mbps 595 flows 137.104.255.235 245 pps 0 mbps 0 flows 137.104.232.80 352 pps 0 mbps 9 flows 137.104.230.0 340 pps 0 mbps 11 flows 137.104.174.178 292 pps 2 mbps 1 flows 137.104.213.201 297 pps 2 mbps 1 flows 137.104.48.239 262 pps 1 mbps 2 flows 137.104.249.195 273 pps 0 mbps 6 flows 137.104.238.83 268 pps 0 mbps 12 flows 137.104.241.115 35 pps 0 mbps 0 flows Internal traffic 0 pps 0 mbps Other traffic 0 pps 0 mbps Screen updated in: 0 sec 376762 microseconds Traffic calculated in: 0 sec 70307 microseconds Total amount of not processed packets: 16904 Packets received: 6973552161 Packets dropped: 0 Packets dropped: 0.0 % Configuration params: We call ban script: yes Packets per second: 20000 Mbps per second: 500 Flows per second: 2000 Ban list: 137.104.110.213/46649 pps incoming at 17_09_15_15:25:12
  • 25.
    /var/log/fastnetmon_attacks/… IP: 137.104.247.176 Initial attackpower: 21209 packets per second Peak attack power: 21209 packets per second Attack direction: incoming Attack protocol: udp Total incoming traffic: 195 mbps Total outgoing traffic: 0 mbps Total incoming pps: 21209 packets per second Total outgoing pps: 34 packets per second Total incoming flows: 463 flows per second Total outgoing flows: 1 flows per second Average incoming traffic: 195 mbps Average outgoing traffic: 0 mbps Average incoming pps: 21209 packets per second Average outgoing pps: 34 packets per second Average incoming flows: 463 flows per second Average outgoing flows: 1 flows per second Incoming tcp traffic: 0 mbps Outgoing tcp traffic: 0 mbps Incoming tcp pps: 0 packets per second Outgoing tcp pps: 0 packets per second Incoming udp traffic: 785 mbps Outgoing udp traffic: 0 mbps Incoming udp pps: 85145 packets per second Outgoing udp pps: 51 packets per second Incoming icmp traffic: 0 mbps Outgoing icmp traffic: 0 mbps Incoming icmp pps: 0 packets per second Outgoing icmp pps: 0 packets per second 2015-05-03 23:49:39.598987 61.161.79.181:19 > 137.104.247.176:29864 protocol: udp packets: 1 size: 1514 bytes sample ratio: 1 2015-05-03 23:49:39.599023 119.97.206.251:19 > 137.104.247.176:29864 protocol: udp packets: 1 size: 1514 bytes sample ratio: 1 2015-05-03 23:49:39.599027 61.128.110.198:0 > 137.104.247.176:0 protocol: udp packets: 1 size: 1514 bytes sample ratio: 1 2015-05-03 23:49:39.599027 60.190.2.90:19 > 137.104.247.176:29864 protocol: udp packets: 1 size: 1514 bytes sample ratio: 1 2015-05-03 23:49:39.599031 61.183.40.34:0 > 137.104.247.176:0 protocol: udp packets: 1 size: 1514 bytes sample ratio: 1 2015-05-03 23:49:39.599031 119.97.206.251:0 > 137.104.247.176:0 protocol: udp packets: 1 size: 690 bytes sample ratio: 1 2015-05-03 23:49:39.599035 60.190.2.90:0 > 137.104.247.176:0 protocol: udp packets: 1 size: 1514 bytes sample ratio: 1 2015-05-03 23:49:39.599037 60.190.2.90:0 > 137.104.247.176:0 protocol: udp packets: 1 size: 1514 bytes sample ratio: 1 2015-05-03 23:49:39.599039 60.190.2.90:0 > 137.104.247.176:0 protocol: udp packets: 1 size: 1514 bytes sample ratio: 1 2015-05-03 23:49:39.599041 60.190.2.90:0 > 137.104.247.176:0 protocol: udp packets: 1 size: 727 bytes sample ratio: 1
  • 27.
    /etc/exabgp/exabgp.conf# exabgp.conf # Usedto inject blackhole routes into uwsys.net within 137.104.0.0/16 # # Blackhole Communities: # uwsysnet_blackhole 3128:911 blackhole this route in AS3128 and upstreams # uwsysnet_blackhole_internet 3128:912 blackhole this route in upstreams but NOT AS3128# # Well-Known Communities: # no-export 65535:65281 do not advertise to any eBGP peers # no-advertise 65535:65282 do not advertise to any BGP peer # local-as 65535:65283 do no advertise this route to peers outside the local as group sysnet_blackhole { local-as 65060; peer-as 3128; router-id 143.235.40.27; local-address 143.235.40.27; hold-time 180; graceful-restart 1200; family { ipv4 unicast; } static { # route 10.10.10.1/32 next-hop 192.0.2.1 community 3128:911; # route 10.10.01.1/32 next-hop 192.0.2.1 community [ 3128:911 65535:65281 ]; # The next line is used to indicate where to automatically add routes at, do not edit it! # INSERT_NEW # 2015-09-04 21:46:31 - auto-blachole incoming route 137.104.212.131/32 next-hop 192.0.2.1 community [3128:911]; # 2015-07-08 03:07:18 - auto-blachole incoming # 2015-07-08 04:16:18 - route 137.104.231.0/32 next-hop 192.0.2.1 community [3128:911]; } neighbor 143.235.32.14 { } neighbor 143.235.32.15 { } }
  • 28.
     QUIC protocol(trips pps limit) ◦ Recommend to trigger on flows/sec and set high Mbps and pps thresholds  Whitelist DNS and other servers or just generate alerts only and use ExaBGP manually  Is the attack actually backscatter from an attack on someone else? False Positives
  • 29.
     Create ACLlike rules that can be advertised to upstream providers  Providers can implement filters in their core or at their edge to block/rate limit traffic  Rule action can potentially be: ◦ Accept ◦ Discard ◦ Rate-limit ◦ Redirect ◦ Redirect-next-hop ◦ Copy ◦ Mark ◦ Action sample|terminal|sample-terminal BGP flowspec
  • 30.
    /etc/fastnetmon.conf (flowspec) # Thisoptions are mandatory for Flow Spec attack detector collect_attack_pcap_dumps = on process_pcap_attack_dumps_with_dpi = on exabgp = on exabgp_command_pipe = /var/run/exabgp.cmd exabgp_community = 65001:666 exabgp_next_hop = 10.0.3.114 exabgp_flow_spec_announces = on # Please switch off unicast BGP announces with ExaBGP because they are not compatible with Flow Spec exabgp_announce_whole_subnet = no exabgp_announce_host = no  Currently supports only most popular amplification attack types ◦ DNS amplification (drop all udp traffic originating from 53 port) ◦ NTP amplification (drop all udp traffic originating from 123 port) ◦ SSDP amplification (drop all udp traffic originating from 1900 port) ◦ SNMP amplification (drop all udp traffic originating from 161 port)
  • 31.
  • 32.
    /etc/exabgp/exabgp.conf (flowspec) # flowspecsyntax: # flow { # route give-me-a-name # route-distinguisher|rd 255.255.255.255:65535|65535:65536|65536:65535; (optional) # next-hop 1.2.3.4; (to use with redirect-to-nexthop) # match { # source 10.0.0.0/24; # source ::1/128/0; # destination 10.0.1.0/24; # port 25; # source-port >1024 # destination-port =80 =3128 >8080&<8088; # protocol [ udp tcp ]; (ipv4 only) # next-header [ udp tcp ]; (ipv6 only) # fragment [ not-a-fragment dont-fragment is-fragment first-fragment last-fragment ]; (ipv4 only) # packet-length >200&<300 >400&<500; # flow-label >100&<2000; (ipv6 only) # } # then { # accept; # discard; # rate-limit 9600; # redirect 30740:12345; # redirect 1.2.3.4:5678; # redirect 1.2.3.4; # redirect-next-hop; # copy 1.2.3.4; # mark 123; # action sample|terminal|sample-terminal; # } # } # } # # one or more match term, one action # fragment code is totally untested
  • 33.
    /etc/exabgp/exabgp.conf (flowspec) group sysnet_flowspec{ local-as 65060; peer-as 3128; router-id 143.235.40.27; local-address 143.235.40.27; hold-time 180; graceful-restart 1200; family { ipv4 flow; } flow { route { match { source 205.213.14.55/32; destination 137.104.167.144/32; source-port =443; protocol tcp; } then { discard; } } } neighbor 143.235.40.19 { } neighbor 143.235.40.18 { } }
  • 34.
     Much ofthe attack traffic may be fragmented packets  Non-initial fragments may be 2/3 to 3/4 of the traffic.  SRC/DST ports of non-initial fragments can’t be identified in a stateless manner, making ACLs and flowspec rules difficult, but rate limits and QoS may help Non-initial fragments
  • 35.
     Separate Authoritativevs Recursive resolver DNS servers  Mix of offsite and onsite authoritative DNS servers ◦ Be prepared to isolate them ◦ Don’t allow inbound access to all of your onsite DNS servers  Require clients to use your onsite recursive resolvers (US-CERT TA15-240A)  Use servers that are hardened and have mitigation features DNS infrastructure
  • 36.
     DDoS Mitigation ◦http://bcop.nanog.org/index.php/DDoS-DoS-attack-BCOP  BGP Blackhole (RTBH) and flowspec ◦ http://www.cisco.com/web/about/security/intelligence/blackhole.pdf ◦ https://kb.wisc.edu/uwsysnet/search.php?q=blackhole&cat=0 ◦ https://www.nanog.org/sites/default/files/wed.general.trafficdiversion.serodio.10.pdf  Fastnetmon: ◦ https://ripe71.ripe.net/wp-content/uploads/presentations/17-RIPE71_new_slides.pdf ◦ https://github.com/pavel-odintsov/fastnetmon ◦ https://github.com/pavel-odintsov/fastnetmon/blob/master/docs/EXABGP_INTEGRATION.md ◦ https://github.com/pavel-odintsov/fastnetmon/blob/master/docs/BGP_FLOW_SPEC.md  ExaBGP ◦ https://github.com/Exa-Networks/exabgp ◦ https://www.m00nie.com/?s=exabgp  DNS ◦ https://www.us-cert.gov/ncas/alerts/TA14-017A  Firewall on Demand ◦ https://www.terena.org/activities/tf-noc/meeting5/slides/20120216-firewall.pdf ◦ http://www.terena.org/activities/tf-msp/meetings/20141127/slides/Yannis.pptx Resources
  • 37.
    /usr/local/bin/notify_about_attack.sh #!/usr/bin/env bash # Blackholeand IP address and notify the NOC # $1 client_ip_as_string # $2 data_direction # $3 pps_as_string # $4 action (ban or unban) email_notify=“noc@somewhere.edu" if [ "$4" = "unban" ]; then # Unban actions if used /usr/local/sbin/auto-blackhole remove:$1 exit 0 fi if [ "$4" = "ban" ]; then cat | mail -s "FastNetMon Guard: IP $1 $2 attack with power $3 pps" $email_notify; # You can add ban code here! exit 0 fi if [ "$4" == "attack_details" ]; then cat | mail -s "FastNetMon Guard: IP $1 $2 attack with power $3 pps" $email_notify; /usr/local/sbin/auto-blackhole $1 $2 exit 0 fi
  • 38.
    /usr/local/sbin/auto-blackhole #!/usr/bin/perl # This scriptwill prompt for and IP to be blackholed. # # It will check the IP is valid # It will blackhole traffic to this IP upsteams too by announcing transit # provider communities too. # # It will also mail the NOC team when a prefix is announced and exabgp # has been restarted. # # Blackhole Communities: # uwsysnet_blackhole 3128:911 blackhole this route in AS3128 and upstreams # uwsysnet_blackhole_internet 3128:912 blackhole this route in upstreams but NOT AS3128 # Transit_A - xxx:xxx # Transit_B - xxx:xxx # # Well-Known communities # no-export - 65535:65281 # do not advertise to any eBGP peers # no-advertise - 65535:65282 # do not advertise to any BGP peer # local-as - 65535:65283 # do not advertise this route to peers outside the local as # # If parameters are IP-addr Comment, then ask no questions # # Originally from www.m00nie.com # ############################################## # Some packages we use use NetAddr::IP; use Data::Validate::IP; use Tie::File; use Net::SMTP::Multipart; use File::Basename; use POSIX qw/strftime/; # This is the exaBGP config file location $exabgpConf = "/etc/exabgp/exabgp.conf"; # Hash we use to validate BGP subnets my %prefix; ######################################################
  • 40.
    /usr/local/sbin/exabgp_reload #!/bin/bash # This scriptshould read the PID of exabgp from a file # then check if that PID is running and reload it :) # # Originally from www.m00nie.com PID_FILE=/var/run/exaBGP/exabgp_PID if [ -f "${PID_FILE}" ]; then # The file exists so read the PID PID=`head -n 1 $PID_FILE` # Check is the process is actuall running if [ -n "`ps -p ${PID} | grep ${PID}`" ]; then echo exaBGP is already running [$PID]. # It is so lets reload the config :) echo sending sighup to reload config... # Use below for exaBGP < 3.2 (Thanks to Roberto Saavedra for noting this) # kill -SIGHUP $PID kill -SIGUSR1 $PID echo Reload complete exit else # Shouldnt really get here echo PID file exists but the PID is not running! exit fi fi # No PID file echo No PID file found at $PID_FILE

Editor's Notes

  • #18 &amp;lt;number&amp;gt;