Transcript 20130614-FLRSSERCA-DMZ

June 14th 2013 – FLR/SSERCA Meeting
Jason Zurawski – Internet2/ESnet
Things That Go Bump in the Net: Implementing
and Securing a Scientific Network
Outline
•
•
•
•
Science DMZ Overview
Science DMZ Examples
Network Performance Expectations
Campus Security
2 – 3/26/2016, © 2013 Internet2/ESnet
[email protected]
Science DMZ Overview
• The data mobility performance requirements for data intensive
science are beyond what can typically be achieved using traditional
methods
–
–
–
–
–
Default host configurations (TCP, filesystems, NICs)
Converged network architectures designed for commodity traffic
Conventional security tools and policies
Legacy data transfer tools (e.g. SCP)
Wait-for-trouble-ticket operational models for network performance
• The Science DMZ model describes a performance-based approach
– Dedicated infrastructure for wide-area data transfer
• Well-configured data transfer hosts with modern tools
• Capable network devices
• High-performance data path which does not traverse commodity LAN
– Proactive operational models that enable performance
• Well-deployed test and measurement tools (perfSONAR)
• Periodic testing to locate issues instead of waiting for users to complain
– Security posture well-matched to high-performance science applications
3 – 3/26/2016, © 2013 Internet2/ESnet
[email protected]
Science DMZ Overview
WAN
perfSONAR
10G
10GE
Border Router
10GE
Per-service
security policy
control points
Clean,
High-bandwidth
WAN path
High performance
Data Transfer Node
with high-speed storage
perfSONAR
10GE
Site / Campus
access to Science
DMZ resources
Enterprise Border
Router/Firewall
10GE
Site / Campus
LAN
perfSONAR
Science DMZ
Switch/Router
4 – 3/26/2016, © 2013 Internet2/ESnet
[email protected]
Science DMZ (In One Slide)
• Consists of 3 key components, all required:
• “friction free” network path
– Highly capable network devices (wire-speed, deep queues)
– Virtual circuit (implementation agnostic - e.g. SDN in any flavor)
connectivity option
– Security policy and enforcement specific to science workflows
– Located at or near site perimeter if possible
• Dedicated, high-performance data movers
– a.k.a.: Data Transfer Node (DTN)
– Optimized bulk data transfer tools such as GlobusOnline/GridFTP
• Performance measurement/test node
– perfSONAR
Source: B. Tierney @ ESnet
• Details at: http://fasterdata.es.net/science-dmz/
5 – 3/26/2016, © 2013 Internet2/ESnet
[email protected]
Outline
•
•
•
•
Science DMZ Overview
Science DMZ Examples
Network Performance Expectations
Campus Security
6 – 3/26/2016, © 2013 Internet2/ESnet
[email protected]
Science DMZ With Virtual Circuits/SDN
WAN
perfSONAR
10G
Routed
Clean,
High-bandwidth
path to/from
WAN
10G
Virtual Circuit
10GE
10GE
perfSONAR
10GE
Site / Campus
access to Science
DMZ resources
Enterprise Border
Router/Firewall
10GE
Site / Campus
LAN
perfSONAR
Science DMZ
Switch/Router
Site/Campus
Virtual Circuits
Nx10GE
Border Router
Per-service
security policy
control points
Dedicated
path for virtual
circuit traffic
High performance
Data Transfer Node
with high-speed storage
7 – 3/26/2016, © 2013 Internet2/ESnet
[email protected]
Research Project Requirements
• Some research projects are networking research projects
– The network is both the environment and the subject of research
– Science DMZ is a good fit for several reasons
• Isolate research from production when research is in the unstable phase
• Separation of administrative control
•
Some research projects need high-performance end to end
networking, but are not network research
– HEP/LHC, Astronomy, “Big Data,” etc.
– The Science DMZ is production cyberinfrastructure
• Ideally, both network research and production data-intensive
science could coexist
8 – 3/26/2016, © 2013 Internet2/ESnet
[email protected]
WAN
perfSONAR
Research
Science DMZ
Switch/Router
Research DTN
perfSONAR
Science DMZ With Separate Research Area
Research
WAN path
perfSONAR
Enterprise Border
Router/Firewall
Production DTN
Site / Campus
LAN
Site / Campus
access to Science
DMZ resources
perfSONAR
Production
Science DMZ
Switch/Router
Production
WAN path
Border Router
Per-service
security policy
control points
Science DMZ
Connections
9 – 3/26/2016, © 2013 Internet2/ESnet
[email protected]
WAN
perfSONAR
Research
Science DMZ
Switch/Router
Research DTN
perfSONAR
Science DMZ With Separate Research Area
Research
WAN path
perfSONAR
Enterprise Border
Router/Firewall
Production DTN
Site / Campus
LAN
Site / Campus
access to Science
DMZ resources
perfSONAR
Production
Science DMZ
Switch/Router
Production
WAN path
Border Router
Per-service
security policy
control points
Science DMZ
Connections
10 – 3/26/2016, © 2013 Internet2/ESnet
[email protected]
Science DMZ – Flexible Design Pattern
• The Science DMZ design pattern is highly adaptable to research
• Deploying a research Science DMZ is straightforward
– The basic elements are the same
• Capable infrastructure designed for the task
• Test and measurement to verify correct operation
• Security policy well-matched to the environment, application set is strictly
limited to reduce risk
– Connect the research DMZ to other resources as appropriate
• The same ideas apply to supporting an SDN effort
– Test/research areas for development
– Transition to production as technology matures and need dictates
– One possible trajectory follows…
11 – 3/26/2016, © 2013 Internet2/ESnet
[email protected]
WAN
Research DTN
perfSONAR
SDN
SDN
Science DMZ
Switch/Router
perfSONAR
Science DMZ – Separate SDN Connection
SDN
Path
High
performance
routed path
Border Router
Per-service
security policy
control points
perfSONAR
Site / Campus
access to Science
DMZ resources
Production
Science DMZ
Switch/Router
perfSONAR
Science DMZ
Connections
Enterprise Border
Router/Firewall
Site / Campus
LAN
Production DTN
12 – 3/26/2016, © 2013 Internet2/ESnet
[email protected]
WAN
Research DTN
perfSONAR
Research
Science DMZ
Switch/Router
perfSONAR
Science DMZ – Production SDN
SDN
High
performance
routed path
SDN
Path
Border Router
Per-service
security policy
control points
perfSONAR
Site / Campus
access to Science
DMZ resources
Production SDN
Science DMZ
Switch/Router
perfSONAR
Science DMZ
Connections
Enterprise Border
Router/Firewall
Site / Campus
LAN
Production DTN
13 – 3/26/2016, © 2013 Internet2/ESnet
[email protected]
WAN
Research DTN
perfSONAR
Research
Science DMZ
Switch/Router
perfSONAR
Science DMZ – SDN Campus Border
High
performance
multi-service
path
Border Router
Per-service
security policy
control points
perfSONAR
Site / Campus
access to Science
DMZ resources
Production SDN
Science DMZ
Switch/Router
perfSONAR
Science DMZ
Connections
Enterprise Border
Router/Firewall
Site / Campus
LAN
Production DTN
14 – 3/26/2016, © 2013 Internet2/ESnet
[email protected]
Production SDN/DMZ Services
• As your Science DMZ acquires SDN capabilities, how will they be
used?
• The existence proof is a powerful thing
– Find a project, make it better
– Operational models for both the scientists and the network
engineering organization will need some tweaking
– People trust tools that behave consistently well – make your
environment perform consistently well
• Roll the snowball
– Add science projects to your Science DMZ
– If new technologies such as SDN provide value, talk about it
– As projects succeed, other projects will want to replicate success
• How do I make sure my stuff consistently works well?
15 – 3/26/2016, © 2013 Internet2/ESnet
[email protected]
perfSONAR Is Key
• All these diagrams have little perfSONAR boxes everywhere
– The reason for this is that consistent behavior requires correctness
– Correctness requires the ability to find and fix problems
• You can’t fix what you can’t find
• You can’t find what you can’t see
• perfSONAR lets you see
• Especially important when deploying new technologies like SDN
– If there is a problem with the SDN infrastructure, need to fix it
– If the problem is not with SDN, need to clear SDN
• New technology is often assumed to be the source of problems
• The only way to correctly attribute is to find the problem
16 – 3/26/2016, © 2013 Internet2/ESnet
[email protected]
perfSONAR Deployment Locations
• Critical to deploy such that you can test with useful semantics
• perfSONAR hosts allow parts of the path to be tested separately
– Devices between perfSONAR hosts have no extra visibility
– Rely on counters or other means
• Effective test methodology derived from protocol behavior
– TCP suffers much more from packet loss as latency increases
– TCP is more likely to cause loss as latency increases
– Testing should leverage this in two ways
• Design tests so that they are likely to fail if there is a problem
• Mimic the behavior of production traffic as much as possible
– Note: don’t design your tests to succeed – this is not helpful
17 – 3/26/2016, © 2013 Internet2/ESnet
[email protected]
Outline
•
•
•
•
Science DMZ Overview
Science DMZ Examples
Network Performance Expectations
Campus Security
18 – 3/26/2016, © 2013 Internet2/ESnet
[email protected]
Reality Check: Expectations
• The following shows how long it (should*) take to transfer 1
Terabyte of data across various speed networks**:
• 10 Mbps network :
– 300 hrs (12.5 days)
• 100 Mbps network :
– 30 hrs
• 1 Gbps network :
– 3 hrs
• 10 Gbps network :
– 20 minutes
*Can your network do this?
**Assumes running at 100% efficiency, no performance problems
19 – 3/26/2016, © 2013 Internet2/ESnet
[email protected]
State of the Campus
• Show of hands – is there a firewall on your campus?
– Do you know who ‘owns’ it? Maintains it? Is it being maintained?
– Have you ever asked for a ‘port’ to be opened? White list a host? Does
this involve an email to ‘a guy’ you happen to know?
– Has it prevented you from being ‘productive’?
• In General …
– Yes, they exist.
– Someone owns them, and probably knows how to add rules – but the
‘maintenance’ question is harder to answer.
• Like a router/switch, they need firmware updates too…
– Will it impact you – ‘it depends’. Yes, it will have an effect on your traffic
at all times, but will you notice?
• Small streams (HTTP, Mail, etc.) – you won’t notice slowdowns, but you will
notice blockages
• Larger streams (Data movement, Video, Audio) – you will notice slowdowns
20 – 3/26/2016, © 2013 Internet2/ESnet
[email protected]
State of Campus – Word of Caution…
• To be 100% clear – the firewall is a useful tool:
– A layer or protection that is based on allowed, and disallowed, behaviors
– One stop location to install instructions (vs. implementing in multiple
locations)
– Very necessary for things that need ‘assurance’ (e.g. student records,
medical data, protecting the HVAC system, IP Phones, and printers from
bad people, etc.)
• To be 100% clear again, the firewall
delivers functionality that can be
implemented in different ways:
– Filtering ranges can be implemented via
ACLs
– Port/Host blocking can be done on a host
by host basis
– IDS tools can implement near real-time
blocking of ongoing attacks that match
heuristics
21 – 3/26/2016, © 2013 Internet2/ESnet
[email protected]
State of the Campus - Clarifications
• I am not here to make you throw away the Firewall
– The firewall has a role; it’s time to define what that role is, and is not
– Policy may need to be altered (pull out the quill pens and parchment)
– Minds may need to be changed
• I am here to make you think critically about campus security as a
system. That requires:
– Knowledge of the risks and mitigation strategies
– Knowing what the components do, and do not do
– Humans to implement and manage certain features – this may be a
shock to some (lunch is never free)
22 – 3/26/2016, © 2013 Internet2/ESnet
[email protected]
State of the Campus – End Game
• The end goal is enabling true R&E use of the
network
– Most research use follows the ‘Elephant’
Pattern. You can’t stop the elephant and inspect
it’s hooves without causing a backup at the door
to the circus tent
– Regular campus patterns are often ‘mice’, small,
fast, harder to track on an individual basis (e.g.
we need big traps to catch the mice that are
dangerous)
– Security and performance can work well
together – it requires critical thought (read that
as time, people, and perhaps money)
– Easy economic observation – impacting your
researchers with slower networks makes them
less competitive, e.g. they are pulling in less
research dollars vs. their peers
23 – 3/26/2016, © 2013 Internet2/ESnet
[email protected]
When Security and Performance Clash
• What does a firewall do?
– Streams of packets enter into an ingress port – there is some buffering
– Packet headers are examined. Have I seen a packet like this before?
• Yes – If I like it, let it through, if I didn’t like it, goodbye.
• No - Who sent this packet? Are they allowed to send me packets? What port
did it come from, and what port does it want to go to?
– Packet makes it through processing and switching fabric to some egress
port. Sent on its way to the final destination.
• Where are the bottlenecks?
– Ingress buffering – can we tune this? Will it support a 10G flow, let alone
multiple 10G flows?
– Processing speed – being able to verify quickly is good. Verifying slowly
will make TCP sad
– Switching fabric/egress ports. Not a huge concern, but these can drop
packets too
– Is the firewall instrumented to know how well it is doing? Could I ask it?
24 – 3/26/2016, © 2013 Internet2/ESnet
[email protected]
“Personal” (Software) Firewall Flow Chart
25 – 3/26/2016, © 2013 Internet2/ESnet
[email protected]
Causes of Jitter
•
•
•
•
Processing Delay: Time to process a packet
Queuing Delay: Time spent in ingress/egress queues to device
Transmission Delay: Time needed to put the packet on the wire
Propagation Delay: Time needed to travel on the wire
26 – 3/26/2016, © 2013 Internet2/ESnet
[email protected]
When Security and Performance Clash
• Lets look at two examples, that highlight two primary network
architecture use cases:
– Totally protected campus, with a border firewall
• Central networking maintains the device, and protects all in/outbound
traffic
• Pro: end of the line customers don’t need to worry (as much) about
security
• Con: end of the line customers *must* be sent through the disruptive
device
– Unprotected campus,
protection is the job of network
customers
• Central networking gives you a
wire and wishes you best of luck
• Pro: nothing in the path to
disrupt traffic, unless you put it
there
• Con: Security becomes an
exercise that is implemented by
all end customers
27 – 3/26/2016, © 2013 Internet2/ESnet
[email protected]
Brown University Example
• Totally protected campus, with a border firewall
28 – 3/26/2016, © 2013 Internet2/ESnet
[email protected]
Brown University Example
• Behind the firewall:
29 – 3/26/2016, © 2013 Internet2/ESnet
[email protected]
Brown University Example
• In front of the firewall:
30 – 3/26/2016, © 2013 Internet2/ESnet
[email protected]
Brown University Example – TCP Dynamics
•
Want more proof – lets look at a measurement tool through the firewall.
– Measurement tools emulate a well behaved application
•
‘Outbound’, not filtered:
– nuttcp -T 10 -i 1 -p 10200 bwctl.newy.net.internet2.edu
–
92.3750 MB /
1.00 sec = 774.3069 Mbps
0 retrans
–
111.8750 MB /
1.00 sec = 938.2879 Mbps
0 retrans
–
111.8750 MB /
1.00 sec = 938.3019 Mbps
0 retrans
–
111.7500 MB /
1.00 sec = 938.1606 Mbps
0 retrans
–
111.8750 MB /
1.00 sec = 938.3198 Mbps
0 retrans
–
111.8750 MB /
1.00 sec = 938.2653 Mbps
0 retrans
–
111.8750 MB /
1.00 sec = 938.1931 Mbps
0 retrans
–
111.9375 MB /
1.00 sec = 938.4808 Mbps
0 retrans
–
111.6875 MB /
1.00 sec = 937.6941 Mbps
0 retrans
–
111.8750 MB /
1.00 sec = 938.3610 Mbps
0 retrans
–
1107.9867 MB / 10.13 sec =
retrans 8.38 msRTT
917.2914 Mbps 13 %TX 11 %RX 0
31 – 3/26/2016, © 2013 Internet2/ESnet
[email protected]
Brown University Example – TCP Dynamics
•
‘Inbound’, filtered:
– nuttcp -r -T 10 -i 1 -p 10200 bwctl.newy.net.internet2.edu
–
4.5625 MB /
1.00 sec =
38.1995 Mbps
13 retrans
–
4.8750 MB /
1.00 sec =
40.8956 Mbps
4 retrans
–
4.8750 MB /
1.00 sec =
40.8954 Mbps
6 retrans
–
6.4375 MB /
1.00 sec =
54.0024 Mbps
9 retrans
–
5.7500 MB /
1.00 sec =
48.2310 Mbps
8 retrans
–
5.8750 MB /
1.00 sec =
49.2880 Mbps
5 retrans
–
6.3125 MB /
1.00 sec =
52.9006 Mbps
3 retrans
–
5.3125 MB /
1.00 sec =
44.5653 Mbps
7 retrans
–
4.3125 MB /
1.00 sec =
36.2108 Mbps
7 retrans
–
5.1875 MB /
1.00 sec =
43.5186 Mbps
8 retrans
–
53.7519 MB / 10.07 sec =
retrans 8.29 msRTT
44.7577 Mbps 0 %TX 1 %RX 70
32 – 3/26/2016, © 2013 Internet2/ESnet
[email protected]
Brown University Example – TCP Plots
33 – 3/26/2016, © 2013 Internet2/ESnet
[email protected]
Brown University Example
• Series of problems and solutions implemented:
– 10G Firewall was not even coming close – configuration and issue with
tech support were to blame
– After this, internal switching infrastructure was revealed to be
dropping packets on large flows (lack of buffering)
– Mitigating step of using 1G network (not protected through firewall)
was found to be insufficient due to demand
• Epilogue:
– perfSONAR Monitoring (Department and Campus) goes a long way in
producing ‘proof’
– Network architectural changes to support heavy hitters will be needed
– Firewalls are complex, its easy to get it ‘wrong’ in terms of
configuration.
• And they need a human to watch them – its not set and forget
34 – 3/26/2016, © 2013 Internet2/ESnet
[email protected]
The Pennsylvania State University Example
• Unprotected campus, protection is the job of network customers
35 – 3/26/2016, © 2013 Internet2/ESnet
[email protected]
The Pennsylvania State University Example
• Initial Report from network users: performance poor both
directions
– Outbound and inbound (normal issue is inbound through protection
mechanisms)
• From previous diagram – CoE firewalll was tested
– Machine outside/inside of firewall. Test to point 10ms away (Internet2
Washington)
•
•
•
•
•
•
•
•
jzurawski@ssstatecollege:~> nuttcp -T 30 -i 1 -p 5679 -P 5678 64.57.16.22
5.8125 MB /
1.00 sec =
48.7565 Mbps
0 retrans
6.1875 MB /
1.00 sec =
51.8886 Mbps
0 retrans
…
6.1250 MB /
1.00 sec =
51.3957 Mbps
0 retrans
6.1250 MB /
1.00 sec =
51.3927 Mbps
0 retrans
184.3515 MB /
30.17 sec =
51.2573 Mbps 0 %TX 1 %RX 0 retrans 9.85 msRTT
36 – 3/26/2016, © 2013 Internet2/ESnet
[email protected]
The Pennsylvania State University Example
• Observation: net.ipv4.tcp_window_scaling did not seem to be working
– 64K of buffer is default. Over a 10ms path, this means we can hope to see
only 50Mbps of throughput:
– BDP (50 Mbit/sec, 10.0 ms) = 0.06 Mbyte
• Implication: something in the path was not respecting the specification in
RFC 1323, and was not allowing TCP window to grow
–
–
–
–
TCP window of 64 KByte and RTT of 1.0 ms <= 500.00 Mbit/sec.
TCP window of 64 KByte and RTT of 5.0 ms <= 100.00 Mbit/sec.
TCP window of 64 KByte and RTT of 10.0 ms <= 50.00 Mbit/sec.
TCP window of 64 KByte and RTT of 50.0 ms <= 10.00 Mbit/sec.
• Reading documentation for firewall:
– TCP flow sequence checking was enabled
– What would happen if this was turn off (both directions?
37 – 3/26/2016, © 2013 Internet2/ESnet
[email protected]
The Pennsylvania State University Example
•
•
•
•
•
•
•
•
•
•
jzurawski@ssstatecollege:~> nuttcp -T 30 -i 1 -p 5679 -P 5678 64.57.16.22
55.6875 MB /
1.00 sec = 467.0481 Mbps
0 retrans
74.3750 MB /
1.00 sec = 623.5704 Mbps
0 retrans
87.4375 MB /
1.00 sec = 733.4004 Mbps
0 retrans
…
91.7500 MB /
1.00 sec = 770.0544 Mbps
0 retrans
88.6875 MB /
1.00 sec = 743.5676 Mbps
28 retrans
69.0625 MB /
1.00 sec = 578.9509 Mbps
0 retrans
2300.8495 MB /
30.17 sec =
639.7338 Mbps 4 %TX 17 %RX 730 retrans 9.88 msRTT
38 – 3/26/2016, © 2013 Internet2/ESnet
[email protected]
The Pennsylvania State University Example
• Impacting real users:
39 – 3/26/2016, © 2013 Internet2/ESnet
[email protected]
The Pennsylvania State University Example
• Series of problems and solutions implemented:
– Firewall was not configured properly
– Lack of additional paths to implement a true research bypass
• Epilogue:
– perfSONAR Monitoring (Department and Campus) still goes a long way
in producing ‘proof’
• FYI – Penn State has around 50 perfSONAR boxes now for all of their
campuses. Tremendous value from a $1,000 machine and free software
– No “One Size Fits All” solution will cut it in a dynamic environment
40 – 3/26/2016, © 2013 Internet2/ESnet
[email protected]
Outline
•
•
•
•
Science DMZ Overview
Science DMZ Examples
Network Performance Expectations
Campus Security
41 – 3/26/2016, © 2013 Internet2/ESnet
[email protected]
Science DMZ (?)
• A staple of the meeting circuit for several years, Matt gave an
excellent overview
• What is it really?
– “Blueprint”, not a specific design
– Approach to network architecture that preserves the ability to
securely manage two different worlds
• Enterprise – BYOD, IP Phones,
Printers, HVAC, things you don’t
know enough about to trust, and
shouldn’t
• Research – Well defined access
patterns, Elephant flows,
(normally) individuals that can
manage their destiny with
regards to data protection
42 – 3/26/2016, © 2013 Internet2/ESnet
[email protected]
Science DMZ – Pro/Con on Generalities
• Pro:
• Con:
– Unspecified nature makes the
pattern fungible for anyone to
implement
– Unspecified nature implies you
need your own smart person to
think critically, and implement it
for a specific instantiation
– Hits the major requirements
for major science use cases
– Those that don’t do heavy
science (or don’t know they do)
may feel “its not for us”
– A concept that “anyone”
should be able to understand
on a high level
– A concept easy to treat as a
‘checkbox’ (hint: CC-NIE
schools – are you stating ‘we
have perfSONAR’ and moving
on?)
43 – 3/26/2016, © 2013 Internet2/ESnet
[email protected]
Where the Rubber Meets the Road
WAN
perfSONAR
Border Router
10GE
perfSONAR
10GE
Site / Campus
access to Science
DMZ resources
Enterprise Border
Router/Firewall
10GE
Site / Campus
LAN
perfSONAR
Science DMZ
Switch/Router
44 – 3/26/2016, © 2013 Internet2/ESnet
[email protected]
10G
10GE
Per-service
security policy
control points
Clean,
High-bandwidth
WAN path
High performance
Data Transfer Node
with high-speed storage
• Lets start with the generic diagram (again):
Where the Rubber Meets the Road
• There are 4 areas I am going to hit on, briefly (note the last one is
not ‘pictured’):
–
–
–
–
Network Path
Adoption of “New” Technology
Security
User Outreach
45 – 3/26/2016, © 2013 Internet2/ESnet
[email protected]
Network Path
• Engineers ‘get it’
– No one will dispute that protected and unprotected path will have
benefits (and certain dangers).
– $, 100G isn’t cheap (10G and 40G are). You don’t have to go 100G,
implementing the architecture with existing technology is a perfectly
good way forward
– You still need a security professional (if you don’t have one already) for
the secured and non-secured paths. Learn to love your IDS just as
much as your firewall and shapper …
• Tuning is important. Small buffers (as seen previously) make data
movement sad. This means servers, and network devices
• Ounce of prevention – you need monitoring, and you certainly need
training in how to use the performance tools to debug. You will be
debugging (bet me a $1 if you honestly think you won’t be…)
46 – 3/26/2016, © 2013 Internet2/ESnet
[email protected]
Adoption of “New” Technology
• SDN, perfSONAR, etc. etc.
– We will keep making acronyms, don’t worry
• What matters in all this? Being able to make your job easier
– perfSONAR = insurance policy against risky behavior.
• Will tell you if you have done things wrong, and warn you if something
breaks.
• Crucial for your campus, and costs only the price of a server, and getting
an engineer up to speed on how to use it
– SDN will be a game changer. Is it ready for production (?) – hard to
say. The ability to afford more control over the network to the end
user relies on applications (and end users) getting caught up. Hint.
• There will be more changes in the future, it’s the nature of the
game. R&E needs to be about certain risky moves away from the
norm
47 – 3/26/2016, © 2013 Internet2/ESnet
[email protected]
Security
• I can spend an entire deck on this, but to keep it short:
– Component based security is wrong. Needs to be a system.
• E.g. the firewall by itself has limited use, and can be easily broken by a
motivated attacker
– System:
• Cryptography to protect user access and data integrity
• IDS to monitor before (and after) events
• Host-based security is better for performance, but takes longer to implement.
Firewalls are bad on performance but easy to plot down in a network.
• Let your router help you – if you know communication patterns (and know
those that should be disallowed), why not use filters?
– Campus CI Plan. Make one, update it often. Shows funding bodies you
know what is going on and have plans to address risks, and foster growth
• Economic argument – if you are non-competitive for grants because you
cheaped out on security, are you better in the long run?
48 – 3/26/2016, © 2013 Internet2/ESnet
[email protected]
Security - Examples
• Data Provenance
– Some bureaucratic document states that all campus traffic must
be a) encrypted and b) passed through a firewall for packet
inspection. Why?
• a) What data is private, and what isn’t? Student records, sure. Maybe
even sensitive grant-related research. Encrypting all data is not
necessary if you stop to think about the data. At least make it a user
choice.
• b) Firewalls work when you can’t be sure of a traffic profile (e.g. they
stop everything and give it the business). If you know the traffic
profile, use that to your advantage. Data from X sites on ports Y, and
Z.
– Policy is:
• Written by those that often do not have practical experience
• Outdated almost immediately
– Review (create) CI Plan regularly.
49 – 3/26/2016, © 2013 Internet2/ESnet
[email protected]
Security - Examples
• User Management
– What is better: centrally managed user system for all
resources vs. independently managed on each machine?
– Central
• Pro: Easier administration when adding/deleting
• Con: Single point of failure
– Individual
• Pro/Con: Breach of once machine doesn’t necessarily imply
that accounts on others are compromised (N.B. I think we
are all guilty of recycling passwords though…)
– Answer depends on your campus, which is another reason
why the DMZ is a blueprint, not a packaged solution
50 – 3/26/2016, © 2013 Internet2/ESnet
[email protected]
Security - Examples
• Device Profiles
– All the devices are equal (untrusted)
• Have the number of phones/tablets eclipsed hard campus
resources for any of you yet?
• You should absolutely not trust these, or *many* of your
hard campus resources
– Some are more equal than others (trusted)
• Does the Physics group have a dedicated admin who ‘gets
it’? They know Linux, and have implemented host-based
security, plus split out heavy hitters from normal users?
• Give them a fast path (Penn State Model)
• If policy needs to be changed, start handing out certificates
to groups that complete a training. CYA…
51 – 3/26/2016, © 2013 Internet2/ESnet
[email protected]
User Outreach
• The unstated factor:
– Could you name your top 10 (5? 3?) network users? Do you know
where their traffic is going? Do you know why? Should you care?
– Simple solution – (net | s)flow monitoring (pick a brand, many are
good).
• Top 10 src/dst for some period of time, go and talk to the researchers.
• Ask them what they are doing, how they are doing it, and if its going ok.
– Campus CI days – was a sponsored thing, but why not have one ‘just
because’?
• Gets IT and research talking.
• Identifies areas of growth; areas of friction
– Requires an outgoing person – hire a research engineer.
• Someone who knows what a network is, and can translate statements like
“the beamline will be firing at 200Khz 2 times a week and generating 2PB
of data a year” into “they need 40Gbps and a clear path to 4 international
sites as well as the domestic routing table”
52 – 3/26/2016, © 2013 Internet2/ESnet
[email protected]
Science DMZ on Campus Conclusions
• A lot to consider
– Security factors, when done poorly, are hurting your users in a
noticeable and significant manner
– Easily found, if you have the right tools at your disposal … and you are
listening to them whine (yeah, that’s a hard one)
• Its not impossible…
– Approaches like the Science DMZ are here to help
– They are not turn key though
• …but it will require some thought and planning
– Know your campus, know your needs
– Implementation won’t take a weekend, plan for some burn in and
testing
– Will pay off in the end (we promise)
53 – 3/26/2016, © 2013 Internet2/ESnet
[email protected]
Things That Go Bump in the Net: Implementing
and Securing a Scientific Network
June 14th 2013 – FLR/SSERCA Meeting
Jason Zurawski – Internet2/ESnet
For more information, visit http://fasterdata.es.net