240 likes | 253 Views
Learn about TransPAC2 Security's strategies for improving network security, including information collection, analysis, and response. Explore their tools and efforts to safeguard against cyber threats.
E N D
TransPAC2 Security John Hicks TransPAC2 Indiana University jhicks@iu.edu 22nd APAN Conference – Singapore 20-July-2006
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. • http://www.ren-isac.net/
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
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
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
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.
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, …)
Peakflow SP router query types Router query types include the following:
Peakflow SP Raw Flow queries Raw flow query types include the following:
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
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).
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.
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.
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.
Peakflow SP WSDL/SOAP getAlertInterfaces - Returns a detailed listing of all routers interfaces involved in the specified alert.
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.
Python SOAP client • usage: soap_client.py -c command <-s script|-h host> [-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=23456 -w graph:alert_23456.png
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.
Questions or Comments John Hicks Indiana University jhicks@iu.edu