INDIANAUNIVERSITYINDIANAUNIVERSITY TransPAC2 Security John Hicks TransPAC2 Indiana University 22nd APAN Conference – Singapore 20-July-2006

INDIANAUNIVERSITYINDIANAUNIVERSITY TransPAC2 Security and the REN-ISAC Is an integral part of U.S. higher education’s 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.

INDIANAUNIVERSITYINDIANAUNIVERSITY 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

INDIANAUNIVERSITYINDIANAUNIVERSITY 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

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

INDIANAUNIVERSITYINDIANAUNIVERSITY 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.

INDIANAUNIVERSITYINDIANAUNIVERSITY 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/ so- 0/2.0.0, …)

INDIANAUNIVERSITYINDIANAUNIVERSITY Peakflow SP query filter types

INDIANAUNIVERSITYINDIANAUNIVERSITY Peakflow SP router query types Router query types include the following:

INDIANAUNIVERSITYINDIANAUNIVERSITY Peakflow SP Raw Flow queries Raw flow query types include the following:

INDIANAUNIVERSITYINDIANAUNIVERSITY 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

INDIANAUNIVERSITYINDIANAUNIVERSITY 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 to individuals or groups (including graphs and data).

INDIANAUNIVERSITYINDIANAUNIVERSITY 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. Peakflow SP portals

INDIANAUNIVERSITYINDIANAUNIVERSITY 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. Peakflow SP WSDL/SOAP

INDIANAUNIVERSITYINDIANAUNIVERSITY 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. Peakflow SP WSDL/SOAP

INDIANAUNIVERSITYINDIANAUNIVERSITY getAlertInterfaces - Returns a detailed listing of all routers interfaces involved in the specified alert. Peakflow SP WSDL/SOAP

INDIANAUNIVERSITYINDIANAUNIVERSITY 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. Peakflow SP WSDL/SOAP

INDIANAUNIVERSITYINDIANAUNIVERSITY usage: soap_client.py -c command [-z zone_secret] [-o key1=value1 -o key2=value2...] [-w key1:file1 -w key2:file2...] example: soap_client.py -h 'sp.arbor.net' -z ’zonesecret' \ -c 'getAlertSummaries' -o count=5 -o offset=3 soap_client.py -h 'sp.arbor.net' -z ’zonesecret' \ -c 'getAlertGraph' -o alertId= w graph:alert_23456.png Python SOAP client

INDIANAUNIVERSITYINDIANAUNIVERSITY 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. Customer “Peakflow Proxy”

INDIANAUNIVERSITYINDIANAUNIVERSITY Client side

INDIANAUNIVERSITYINDIANAUNIVERSITY

INDIANAUNIVERSITYINDIANAUNIVERSITY

INDIANAUNIVERSITYINDIANAUNIVERSITY

INDIANAUNIVERSITYINDIANAUNIVERSITY Questions or Comments John Hicks Indiana University