PLNOG 8: Merike Kaeo - Guide to Building Secure Infrastructures

Guide to Building Secure
Infrastructures
Merike Kaeo
PLNOG – March 5, 2012
merike@isc.org

Agenda
•  What Are We Protecting Against?
•  Proactive Mitigation Techniques
-  Securing The Device
-  Infrastructure Filtering
-  Securing the Routing Infrastructure
-  Securing MPLS
-  Securing DNS
•  Auditing / Logging
•  Using Routing as a Security Tool

What Are We Protecting Against?
Agenda Item

Attackers Have Advantage
• Globally Distributed
•  So Many BotNets to Choose From
•  Lack of Enforced Filtering Helps Keep Spoofed Packets Alive
•  Who Looks At their Logs

Evolution of Attack Landscape
email propagation of malicious code
“stealth”/advanced scanning techniques
widespread attacks using NNTP to distribute attack
widespread attacks on DNS infrastructure
executable code attacks (against browsers)
automated widespread attacks
GUI intruder tools
hijacking sessions
Internet social engineering
attacks
packet spoofing
automated probes/scans
widespread
denial-of-service
attacks
techniques to analyze
code for vulnerabilities
without source code
DDoS attacks
increase in worms
sophisticated command
& control
anti-forensic techniques
home users targeted
distributed attack tools
increase in wide-scale
Trojan horse distribution
Windows-based
remote controllable
Trojans (Back Orifice)
Intruder Knowledge
AttackSophistication
1990 2012

Attacker
Victim
Automated Distributed Denial of Service Attack
Initiate port scan
1
Vulnerable hosts are
compromised and
attack tools
installed
2
Vulnerable hosts are
compromised and
attack tools
installed
2
Further scanning
for compromises
3
Further scanning
for compromises
3
Massive DDoS
attack launched
4

Attack Motivation
•  Criminal
-  Criminal who use critical infrastructure as a
tools to commit crime
-  Their motivation is money
•  War Fighting/Espionage/Terrorist
-  What most people think of when talking about
threats to critical infrastructure
•  Patriotic/Principle
-  Larges group of people motivated by cause –
be it national pride or a passion aka Anonmous

Threat Economy: In the Past
End Value
Espionage
(Corporate/
Government)
Fame
Theft
Writers Asset
Worms
Tool and Toolkit
Writers
Viruses
Trojans
Malware Writers
Compromise
Individual
Host or
Application
Compromise
Environment

Threat Economy: Today
Writers Middle Men
Second Stage
Abusers
Bot-Net Management:
For Rent, for Lease,
for Sale
Bot-Net Creation
Personal
Information
Electronic IP
Leakage
$$$ Flow of Money $$$
Worms
Tool and
Toolkit Writers
Viruses
Trojans
Malware Writers
First Stage
Abusers
Machine
Harvesting
Information
Harvesting
Hacker/Direct
Attack
Internal Theft:
Abuse of
Privilege
Information
Brokerage
Spammer
Phisher
Extortionist/
DDoS-for-Hire
Pharmer/DNS
Poisoning
Identity Theft
Compromised
Host and
Application
End Value
Financial Fraud
Commercial Sales
Fraudulent Sales
Click-Through
Revenue
Espionage
(Corporate/
Government)
Criminal
Competition
Extorted Pay-Offs
Theft
Spyware

Proactive Mitigation Techniques
Agenda Item

Most Common Threats and
Attacks
• Unauthorized access – insecure hosts, cracking
• Eavesdropping a transmission – access to the
medium
– Looking for passwords, credit card numbers, or business
secrets
• Hijacking, or taking over a communication
– Inspect and modify any data being transmitted
• IP spoofing, or faking network addresses
– Impersonate to fool access control mechanisms
– Redirect connections to a fake server
• DOS attacks
– Interruption of service due to system destruction or
using up all available system resources for the service
– CPU, memory, bandwidth

Mistakes IT People Make
-  Connecting systems to the Internet before hardening them.
-  Connecting test systems to the Internet with default accounts/
passwords
-  Failing to update systems when security holes are found
-  Using telnet and other unencrypted protocols for managing
systems, routers, firewalls, and PKI.
-  Giving users passwords over the phone or changing user
passwords in response to telephone or personal requests when
the requester is not authenticated.
-  Failing to maintain and test backups.
-  Running unnecessary services : ftpd, telnetd, finger, rpc, mail,
rservices
-  Implementing firewalls with rules that don't stop malicious or
dangerous traffic - incoming and outgoing.
-  Failing to implement or update virus detection software
-  Failing to educate users on what to look for and what to do
when they see a potential security problem.

Architectural Considerations
•  Addressing Architecture
•  Redundancy Measures
•  Firewall / Load Balancer Placement
•  IPv6 Transition/Co-existence
•  Cloud Paradigms
•  Mobile Traffic Explosion

Securing The Device
Agenda Item

Device Physical Access
•  Equipment kept in highly restrictive environments
•  Console access
-  password protected
-  access via OOB management
-  configure timeouts
•  Individual users authenticated
•  Social engineering training and awareness

Access Control Best Practices
•  Set passwords to something not easily guessed
•  Use single-user passwords (avoid group
passwords)
•  Encrypt the passwords in the configuration files
•  Use different passwords for different privilege
levels
•  Use different passwords for different modes of
access

Telnet using SSH ‘Jumphost’
Peer
Conference
Net
Customer
NOCSyslog, TFTP,
AAA, DNS,
SMTP
NetFlow,
SNMP
1.  SSH to NOC
2.  Telnet to router
1
2

SNMP Best Practices
•  Do not enable read/write access unless really
necessary
•  Choose community strings that are difficult to
guess
•  Limit SNMP access to specific IP addresses
•  Limit SNMP output with views
•  Consider using SNMPv3
-  Integrity and confidentiality utilizing cryptographic
algorithms

Device OOB Management
• Out-of-band device
management should be used
to ensure DoS attacks do not
hinder getting access to critical
infrastructure devices
• Dial-back encrypted modems
are sometimes still used as
backup

Software Upgrade / Integrity
•  Files stored on specific systems with
limited access
•  All access to these systems are
authenticated and audited
•  SCP is used where possible; FTP is
NEVER used; TFTP still used
•  Configuration files are polled and
compared on an hourly basis (RANCID)
•  Filters limit uploading / downloading of
files to specific systems
•  Many system binaries use MD-5 checks
for integrity
•  Configuration files are stored with
obfuscated passwords

Fundamental Device Protection Summary
•  Secure logical access to routers with passwords and timeouts
•  Never leave passwords in clear-text
•  Authenticate individual users
•  Restrict logical access to specified trusted hosts
•  Allow remote vty access only through ssh
•  Disable device access methods that are not used
•  Protect SNMP if used
•  Shut down unused interfaces
•  Shut down unneeded services
•  Ensure accurate timestamps for all logging
•  Create appropriate banners
•  Test device integrity on a regular basis

Infrastructure Filtering
Agenda Item

Infrastructure Filters
•  Permit only required protocols and deny ALL
others to infrastructure space
-  Filters now need to be IPv4 and IPv6!
-  Applied inbound on ingress interfaces
•  Basic premise: filter traffic destined TO your
core routers
•  Develop list of required protocols that are sourced
from outside your AS and access core routers
-  Example: eBGP peering, GRE, IPSec, etc.
-  Use classification filters as required
•  Identify core address block(s)
-  This is the protected address space
-  Summarization is critical for simpler and shorter filters

IPv4 Reserved Addresses
(* these networks may be reallocated)
Description Network
default 0.0.0.0 /8
loopback 127.0.0.0 /8
RFC 1918 10.0.0.0 /8
RFC 1918 172.16.0.0 /12
RFC 1918 192.168.0.0 /16
Net Test 192.0.2.0 /24
Testing devices * 192.18.0.0 /15
IPv6 to IPv4 relay * 192.88.99.0 /24
RFC 1918 nameservers * 192.175.48.0 /24
End-node auto configuration * 169.254.0.0 /16

IPv6 Reserved Addresses
Description Network
unspecified :: /128
loopback ::1 /128
IETF reserved address;IPv4-
compatible IPv6 address
::/96
IPv4-mapped IPv6 address ::ffff:0:0/96
reserved ::/8
unique-local address fc00::/7
multicast address ff00::/8
documentation addresses 2001:db8::/3

IP Fragment Issues
•  Fragmented Packets can cause problems...
-  Fragmented packets can be used as an attack vector to
bypass filters
-  Fragments can increase the effectiveness of some attacks
by making the recipient consume more resources (CPU and
memory) due to fragmentation reassembly
•  Reality Check – Routers & Switches should not be
receiving fragments!
-  In today’s networks, management & control plane traffic
should not be fragmenting.
-  If it does, it means something is BROKE or someone is
attacking you.
•  Recommendation – Filter all fragments to the
management & control plane … logging to monitor for
errors and attacks.

Securing The Routing
Infrastructure
Agenda Item

Saturate the Receive Path
Queues
•  Routers usually have various receive path queues that are
hit as the packet heads for the TCP Stack.
•  Saturation Attacks fill these queues – knocking out valid
packets from the queues.
•  Consequence: BGP Times out – Dropping the BGP Session
ToFab to Other
Line Cards
Forwarding/Feature ASIC/NP/
FPGA Cluster
ASICs
Supporting CPU Receive Path Packets
Route Processor
CPU
Ingress Packets Forwarded Packets
PuntedPackets
Saturate the Supporting ASIC
CPU
Data Plane
Control Plane
Saturate the Raw “Punt”
Queue
Packets Bound
for the LC CPU or
RP
Saturate the Input
Buffers on the RP
Fabric
Interconnect
Saturate the CPU
Management Plane

Generalized TTL Security
Mechanism
•  GTSH is a hack which
protects the BGP peers
from multihop attacks.
•  Routers are configured to
transmit their packets with
a TTL of 255, and to reject
all packets with a TTL
lower than 254 or 253.
•  A device which isn’t
connected between the
routers cannot generate
packets which will be
accepted by either one of
them.
eBGP
Transmits all
packets with a
TTL of 255
Doesn’t accept
packets with a TTL
lower than 254
A
Packets generated
here cannot reach
A with a TTL higher
than 253.

Peer Authentication
•  MD5 Peer authentication can protect
against:
-  Malformed packets tearing down a peering
session
-  Unauthorized devices transmitting routing
information
•  MD5 Peer authentication cannot protect
against:
-  Reset routing protocol sessions due to denial of
service attacks
-  Incorrect routing information being injected by
a valid device which has been compromised

Attacking Routing Data
•  How could you attack
routing data?
•  Modification
-  Direct traffic along an
unprotected path
-  Direct traffic into a
black hole
-  Create a routing loop
•  Overclaiming
-  Injecting nonexistent
destinations
-  A longer prefix!
•  Underclaiming
-  Removing destinations
A
D
B C
10.1.1.0/24
protectedpath
10.1.1.0/24
10.1.1.0/24
10.1.1.0/25
10.1.1.0/24
doesn’t exist

Filtering Provides Some
Protection
• Take care of your
own Network.
-  Filter your
customers
-  Filter you
advertisements
• Net Police Filtering
-  Mitigate the impact
when it happens
• Prefix Filtering and
Max Prefix Limits
The rest
of the
Internet
The rest
of the
Internet
AS 100
AS 300
AS XYZ
AS 500
Lets advertise
the entire
Internet with /24
more specifics

Resource Public Key
Infrastructure (RPKI)
•  Allows us to verify whether an AS is authorized to
announce a specific prefix
•  Main building blocks are trust-anchors, route
origin authorizations and validators
-  Trust-anchors used today are the RIR’s (RIPE, APNIC,
LACNIC, AFRINIC)
-  Route Origin Authorization (ROA’s) are documents used
to link a set of prefixes with an origin ASN. These ROA’s
are created by the maintainers/administrators of an
Autonomous system or Network.
•  ROAs are signed by the resource holders private key and
creates a chain of trust which allows us to authorize
(validate) BGP announcements.

RPKI Resources
•  RIR RPKI Deployment Statistics
-  http://certification-stats.ripe.net/
•  Securing BGP and SIDR
-  http://isoc.org/wp/ietfjournal/?p=2438
•  An APNIC Primer on RPKI
-  http://www.apnic.net/services/services-apnic-provides/
resource-certification/RPKI
•  RIPE RPKI information
-  http://www.ripe.net/lir-services/resource-management/
certification

MPLS Threats
•  Label info disclosure / label enumeration
-  A way to get information about how the
network is built
•  Rogue path switching / rogue destination
switching
-  To be able to inject traffic and compromise the
switching mechanism
•  Label info poisoning / DoS
-  To modify the integrity and availability of the
network

MPLS Security
Recommendations
•  IP/application authentication and encryption
(IPSeC VPN, HTTPS, SIP-S)
•  Authentication and integrity checking (MD5) to
accept LDP updates for trustworthy sources only
•  Security Monitoring and health checking of
network devices to track any changes and
availability issues on the network

MPLS Design Rules
•  Static routing between PE and CE
-  protect against routing protocol attacks
•  Spoofing protections
-  dropping labeled packets from CE / VRF segregation
•  Controlling access to devices utilizing AAA
•  Controlling changes
-  configuration integrity checking / change control mgt
•  ACLs to restrict routing traffic to the peering
interface (when not static)
•  CEs and PEs on different VLANs and different
physical switches
•  Use of firewalls on peering points
-  VPN connected to the Internet

DNS Vulnerabilities
•  Corrupted the data
•  Unauthorized updates
•  Impersonating a primary name server
•  Cache pollution by data spoofing
•  Cache impersonation

DNS Vulnerabilities
master Caching
forwarder
resolver
Zone administrator
Zone file
Dynamic
updates
1!
2!
slaves
3!
Server protection!
4!
5!
Corrupting data! Impersonating master!
Unauthorized updates!
Cache impersonation!
Cache pollution by!
Data spooﬁng!
Data protection!
Altered zone data!

DNS Concerns
•  Many means of poisoning DNS caches
•  Be wary of incorrect use and monitor
authoritative name servers to ensure
correct behavior
•  Consider DNSSEC
-  Assess viability in your environment
-  Requires use of PKI….start getting familiar with
it…..avoidance will lead to later headaches

Logging / Auditing
Agenda Item

Logging
•  Logging servers should be physically and logically
secure
•  Accept messages only from trusted hosts
•  Integrity protect logging messages
•  Encrypt log messages
•  Allow only authorized personal to view logs
•  Any issues with privacy?!?

Syslog
•  Event logs created by syslog daemon
•  Configured in /etc/syslog.conf
•  Usually logs stored in /var/log
-  /var/log/secure: successful and failed logins
-  /var/log/messages: general messages
•  Other information on logged in users can be found in /var/adm/

Syslog Alternatives
•  Syslog-NG
-  More extensive log message filtering
-  More reliable logging over TCP
-  No file log rotation – save to archive location by default
-  Encryption of TCP connection via use of stunnel or a VPN
•  Nsyslogd
-  http://coombs.anu.edu.au/~avalon/nsyslog.html
-  Supports SSL

Automated Log Analysis Tools
•  SWATCH (The Simple Watcher)
-  http://www.oit.ucsb.edu/~eta/swatch/
-  need to write tools
•  LogWatch
-  http://www.logwatch.org/
-  works right out of box but configuration changes require
knowledge of PERL
•  Checksyslog
-  http://www.jammed.com/~jwa/hacks/security/checksyslog/
checksyslog-doc.html
-  very simplistic tool

Benefits of Deploying NTP
•  Very valuable on a global network with network
elements in different time zones
•  Easy to correlate data from a global or a sizable
network with a consistent time stamp
•  NTP based timestamp allows to trace security
events for chronological forensic work
•  Any compromise or alteration is easy to detect as
network elements would go out of sync with the
main ‘clock’
•  Did you there is an NTP MIB? Some think that we
may be able to use “NTP Jitter” to watch what is
happening in the network.

Netflow Tools
•  NfSen - Netflow Sensor
-  http://nfsen.sourceforge.net/
•  NFDUMP
-  http://nfdump.sourceforge.net/
-  FlowCon
-  http://www.cert.org/flocon/

TACACS+ URLs
•  TACACS+ Open Source
 ftp://ftp-eng.cisco.com/pub/tacacs/
 Includes the IETF Draft, Source, and
Specs.
•  Extended TACACS++ server
 http://freshmeat.net/projects/tacpp/
•  TACACS + mods
 http://www.shrubbery.net/tac_plus/

-  tcpdump – http://www.tcpdump.org
-  Wireshark – http://www.wireshark.org
-  Cacti – http://www.cacti.net
-  Scrutinizer (Netflow tool) - http://www.plixer.com
-  Perl Net::RawIP tools for generating attack traffic
-  Ettercap – http://ettercap.sourceforge.net
-  Yersenia – http://yersinia.net
-  nmap – http://nmap.org
-  Good old ping - on a unix host near you
-  Nessus – http://nessus.org
Some Useful Tools

Using Routing as a Security Tool
Agenda Item

Sink Hole Routers/Networks
•  BGP speaking router or workstation that is built to
redirect attacks away from the customer
•  Used to monitor attack noise, scans, data from
mis-configuration and other activity (via the
advertisement of default or unused IP space
•  Traffic is typically diverted via BGP route
advertisements and policies.
•  http://www.nanog.org/mtg-0306/sink.html

The Basic Sinkhole
•  Sinks Holes do not have to be complicated.
•  Some large providers started their Sinkhole with a
spare workstation with free unix, Zebra, and
TCPdump.
•  Some GNU or MRTG graphing and you have a
decent sinkhole.
To ISP
Backbone
Sinkhole
Server
Advertise small
slices of Bogon
and Dark IP space

Expanding the Sinkhole
•  Expand the Sinkhole with a dedicated router into a variety
of tools.
•  Pull the DOS/DDOS attack to the sinkhole and forwards the
attack to the target router.
•  Static ARP to the target router keeps the Sinkhole
Operational – Target Router can crash from the attack and
the static ARP will keep the gateway forwarding traffic to
the Ethernet switch.
To ISP Backbone
To ISP
Backbone
To ISP Backbone
Sinkhole Gateway Target Router
Sniffers and
Analyzers
Static ARP to
Target Router

What to monitor in a Sinkhole?
•  Scans on Dark IP (allocated & announced
but unassigned address space).
-  Who is scoping out the network – pre-attack
planning.
•  Scans on Bogons (unallocated).
-  Worms, infected machines, and Bot creation
•  Backscatter from Attacks
-  Who is getting attacked
•  Backscatter from Garbage traffic
(RFC-1918 leaks)
-  Which customers have misconfiguration or
“leaking” networks.

Sinkhole Precautions
•  Do not allow bogons to leak:
-  BGP “NO_EXPORT” community
-  Explicit Egress Prefix Policies
(community, prefix, etc.)
•  Do not allow traffic to escape the
sinkhole:
-  Backscatter from a Sinkhole defeats the
function of a Sinkhole (egress ACL on
the Sinkhole router)

•  Use BGP routing protocol to trigger network
wide response to an attack flow.
•  Simple static route and BGP allows ISP to trigger
network wide black holes as fast as iBGP can
update the network.
•  Unicast RPF allows for the black hole to include
any packet whose source or destination address
matches the prefix.
•  Effective against spoofed and valid source
addresses.
Remotely Triggered
BlackHole Routing

FIB
---------------------
---------------------
---------------------
---------------------
---------------------
---------------------
---------------------
---------------------
Ingress Packet
Filter
---------------------
---------------------
---------------------
---------------------
Null0/Discard
Packets
Arrive
•  Forward packet to the Bit Bucket
•  Saves on CPU and ACL processing
Egress
Interfac
e
Blackhole Filtering

RTBH in the Network
eBGP
Session
Trigger Router
iBGP
TARGET
Provider Edge Routers
Attack Traffic
BGP Update

Destination-Based RTBH
iBGP
TARGET
PE configured with static
route to unused space set
to Null0 (192.0.2.6/32 set
to Null0)
TR configured to
redistribute static into
every iBGP peer
1 1
Steps:
1.  Preparation
2.  Trigger
3.  Withdrawal
Add static route
which sets next hop
to target destination
(192.0.2.6)
Receives iBGP update
which states next hop
for target is 192.0.2.6/32
2 2
Manually remove
static route which
causes BGP route
withdrawl
Installs new (valid)
route to target 3
3
NOTE: All traffic to
the target is dropped,
even legitimate traffic
Trigger Router

Source-Based RTBH Filtering
•  Ability to drop packets at network edge based on
specific source address
•  Permits legitimate traffic from reaching target
destination
•  Depends on uRPF
-  uRPF Loose Check will passively drop any packet whose source
address is not in the router’s FIB (Forwarding Information Base)
•  Packet dropped if:
-  If router has no entry for source IP address
-  If source IP address entry points to Null0

Source Based Remote Triggered Black Hole
Filtering
•  What do we have?
-  Black Hole Filtering – If the destination address equals Null 0 we
drop the packet.
-  Remote Triggered – Trigger a prefix to equal Null 0 on routers
across the Network at iBGP speeds.
-  uRPF Loose Check – If the source address equals Null 0, we
drop the packet.
•  Put them together and we have a tool to trigger drop for any
packet coming into the network whose source or destination
equals Null 0!

Source-Based RTBH
iBGP
TARGET
PE configured with static
route to unused space
set to Null0 (192.0.2.6/32
set to Null0) and loose
mode uRPF on external
interfaces
TR configured to
redistribute static into
every iBGP peer
1 1
Steps:
1.  Preparation
2.  Trigger
3.  Withdrawal
Add static route
which sets next hop
to target destination
(192.0.2.6)
2
Manually remove
static route which
causes BGP route
withdrawl
3
Receives iBGP update
which states next hop for
target is 192.0.2.6/32. All
traffic from source IP will
fail loose uRPF check.
2
Installs new (valid route to
target
3
NOTE: Only traffic
from the attack
sources get dropped
Trigger Router

RTBH Configuration Example
interface Null0
! avoid backscatter traffic
no ip unreachables
!
router bgp 6665
redestributre static route-map bh-trig
!
route map bh-trig permit 10
match tag 66
set ip next-hop 192.0.2.1
set local-preference 200
set origin igp
! ensure edge router does not readvertise
! prefix to any eBGP peer
set community no-export
!
! make sure no other static routes affected
! by the bh-trig route map
route-map bh-trig deny 22
!
! the manually configured trigger
ip route 192.168.33.0 255.255.255.0 null0 tag66
interface Null0
no ip unreachables
!
ip route 192.0.2.1 255.255.255.255 null0
Trigger Router

Additional RTBH Considerations
•  Avoid intentionally/unintentionally dropping
legitimate traffic
•  Deploy secure BGP features
-  Neighbor authentication
-  Prefix filters
-  ‘TTL hack’
•  Use prefix filters at edge and trigger routers to
ensure essential services (e.g. DNS) not black-
holed by mistake

Simple Best Practices - 1
•  Use least-privileged mode where possible
•  Keep on top of OS releases for your network elements,
particularly if security patches are released
•  When implementing IPv6, be careful and ensure that your
ACLs, filters, CoPP, etc incorporate the fact that all
protocols will start listening on the IPv6 addresses
•  Don’t block all ICMP – there are some really important
parts of it that can break IPv6
•  Give high priority to network control traffic
•  Ideally, have an out-of-band management path to all POPs.
•  Restrict DHCP and Router Advertisements on customer
ports
•  Separate customers into separate VLANs if you can
•  Use local-proxy-arp and private VLANs to restrict device-to-
device communications

•  Use an anomaly detection system – even if it’s just netflow
and a suspicious eye!
•  Use RANCID or similar to monitor configuration changes on
network elements.
•  Ensure you are logging to central locations via syslog /
SNMP traps.
•  Monitor critical network element resources, e.g. memory,
bandwidth utilisation, interface utilisation, RIB/FIB
utilisation, CAM utilisation, etc
•  Always null route unused address space within your network
-  If you have prefixes you know are unused, route them towards null0
on your routers.
-  Prevents ARP cache exhaustion, broadcasts, and prevents address
theft
•  Enable port security and limit the number of MACs on customer
ports

•  Always filter ingress traffic from customers with uRPF or
ACLs (source address validation)
•  Authenticate all of your network protocols
•  Filter BGP sessions ingress and egress
-  Make sure you don’t accept prefixes you don’t want or
shouldn’t carry
•  Set maximum-prefix/prefix-limit on BGP sessions (including
customers, transits, and peers)
•  ALWAYS ENCRYPT YOUR MANAGEMENT TRAFFIC!
-  Avoid the use of clear text as much as possible.
-  Limit clear text traffic to the shortest and most trusted path possible.
•  Have a security plan that includes incident management processes
-  Identify who, what, and how
-  Practice and test the plan
-  Make sure you know how to reach your peers and transit providers,
and how their security plans work!

PLNOG 8: Merike Kaeo - Guide to Building Secure Infrastructures

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a PLNOG 8: Merike Kaeo - Guide to Building Secure Infrastructures

Semelhante a PLNOG 8: Merike Kaeo - Guide to Building Secure Infrastructures (20)

Último

Último (20)

PLNOG 8: Merike Kaeo - Guide to Building Secure Infrastructures