TransPAC2 Security

1
TransPAC2 Security
John Hicks TransPAC2 Indiana University jhicks_at_iu.
edu
22nd APAN Conference Singapore 20-July-2006
2
TransPAC2 Security and the REN-ISAC

• Is an integral part of U.S. higher educations
  strategy to improve network security through
  information collection, analysis, dissemination,
  early warning, and response
• is specifically designed to support the unique
  environment and needs of organizations connected
  to served higher education and research networks
  and
• supports efforts to protect the national cyber
  infrastructure by participating in the formal
  U.S. ISAC structure.
• http//www.ren-isac.net/

3
TransPAC2 Security Efforts

• Information products
• Daily Weather Report
• Daily Darknet Reports
• Alerts
• Notifications
• Monitoring views
• Incident response
• 24x7 Watch Desk
• Cybersecurity Contact Registry
• Tool development
• Security infrastructures work in specific
  communities, e.g. grids
• Participation in other higher education efforts

4

• Infrastructure security, traffic analysis,
  managed DoS protection via intelligent netflow
  analysis
• Network Anomaly Detection
• DDoS, worms, network and bandwidth abuse
• Integrated Mitigation
• seamless operation with a variety of DoS
  mitigation tools filtering, rate-limiting, BGP
  blackholing, off-ramping/sinkholing, etc.
• Analytics peering evaluation, BGP routing
• Reporting
• real-time and customized anomaly and traffic
  reports

5

• Customer-facing DoS Portal
• Gives customers a first-hand view of their
  traffic inside the service providers network
  customers set their own thresholds and alerts
• Fingerprint Sharing
• Share anomaly fingerprints with peers, customers,
  etc. for upstream DoS mitigation

6

• The Arbor systems Peakflow SP system is a
  traffic analysis engine the works on a collection
  of routers.
• By default, the collection of routers is
  aggregated into a one network.
• General queries (no filters) return summaries
  of the entire network.
• Query filters provide one means of narrowing
  return data.
• Other scoping mechanisms are available.

7
Peakflow SP queries

• The Peakflow system collects flow, BGP, and
  SNMP data and provides a facility to query and
  filter desired data for a particular time slice.
• Peakflow SP is designed around XML queries.
• There is currently a limit of two filters for
  each query.
• Desired data can be further scoped by different
  query types.
• Example filter on entity 1 (entity 1 could be
  an alert id) data, then on router interfaces
  (so-0/1.0.0. so-0/2.0.0, )

8
Peakflow SP query filter types
9
Peakflow SP router query types

• Router query types include the following

10
Peakflow SP Raw Flow queries

• Raw flow query types include the following

11
Peakflow SP BGP queries

• BGP queries include
• Diff - Reports a list of BGP change reports
• Raw - Reports a list of raw routes
• Summary - Reports the summary of BGP changes
  matching a filter

12
Peakflow SP

• The Peakflow SP system can return graphs and
  raw data for each type of query.
• Security reports can be automatically run at
  schedules times (like cron).
• Security reports can be email to individuals or
  groups (including graphs and data).

13
Peakflow SP portals

• Peakflow SP offers a customer facing portal
  that provides access to some of the SP data.
• Portal data views are scoped to a subset of the
  systems data.
• Portals are a good way to provide private
  access to costumer data.
• One problem with portals is that scoping data
  is very course.
• For example If a costumer sees an anomaly
  (large traffic from /24) in the data from a query
  and determines that it is coming from an
  interface not in the costumers scope. Further
  investigation is prohibited. If the system
  provides access to this interface then all
  interfaces are available.

14
Peakflow SP WSDL/SOAP

• To solve this problem, we are using the
  Peakflow wsdl to provide more refined scoping of
  data.
• The Peakflow SP wsdl provide the following
• getAlertGraph - For a given alert id, returns a
  graph of the total alert traffic per customer
  interface over the life of the alert.
• sqlQuery - Returns an SQL query in XML format.
• getTrafficData - Returns detailed sample data
  for items matching the query. Data is returned
  XML format.
• getTrafficGraph - Returns a graph of the data
  items matching the supplied query parameters.

15
Peakflow SP WSDL/SOAP

• getAlertSummaries - Returns summary information
  about the most recent count alerts, starting at
  offset alerts from the most recent alert. The
  optional filter can specify the name of a
  customer managed object.

16
Peakflow SP WSDL/SOAP

• getAlertInterfaces - Returns a detailed listing
  of all routers interfaces involved in the
  specified alert.

17
Peakflow SP WSDL/SOAP

• getAlertInterfaceDetails - Returns detailed
  information about router interfaces involved in
  the specified alert.
• getAlertInterfacesXML - Same as
  getAlertInterfaces but in XML format.
• getAlertRouterInterfacesXML - Same as
  getAlertRouterInterfaces but in XML format.
• getReport - Returns multiple graphs in one
  tar.gz file.
• getAlertStatisticsRaw - Returns raw statistics
  about requested alert.

18
Python SOAP client

• usage soap_client.py -c command lt-s script-h
  hostgt
• -z zone_secret
• -o key1value1 -o key2value2 ...
• -w key1file1 -w key2file2 ...
• example
• soap_client.py -h 'sp.arbor.net' -z zonesecret'
  \
• -c 'getAlertSummaries' -o count5 -o
  offset3
• soap_client.py -h 'sp.arbor.net' -z
  zonesecret' \
• -c 'getAlertGraph' -o alertId23456 -w
  graphalert_23456.png

19
Customer Peakflow Proxy

• Peakflow SP currently provides a single
  Zonesecret to access the system remotely via
  SOAP.
• Scoping of data is done on the proxy server.
• Web presentation is currently done with PHP but
  other technologies such as AJAX are being
  explored.
• DB backend also under investigation.
• Proxy server code will be made available once
  private zonesecret can be secured.
• Costume interfaces are easily rolled out for
  private data.

20
Client side
21
Client side
22
Client side
23
Client side
24
Questions or Comments
John Hicks Indiana University jhicks_at_iu.edu