I

N

D

I

A

N

A

U

N

I

V

E

R

S

I

T

Y

TransPAC2 Security

John HicksTransPAC2

Indiana Universityjhicks@iu.edu

22nd APAN Conference – Singapore 20-July-2006

I

N

D

I

A

N

A

U

N

I

V

E

R

S

I

T

Y

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/

I

N

D

I

A

N

A

U

N

I

V

E

R

S

I

T

Y

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

I

N

D

I

A

N

A

U

N

I

V

E

R

S

I

T

Y

• 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

I

N

D

I

A

N

A

U

N

I

V

E

R

S

I

T

Y

– 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

I

N

D

I

A

N

A

U

N

I

V

E

R

S

I

T

Y

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

I

N

D

I

A

N

A

U

N

I

V

E

R

S

I

T

Y

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, …)

I

N

D

I

A

N

A

U

N

I

V

E

R

S

I

T

Y

Peakflow SP query filter types

I

N

D

I

A

N

A

U

N

I

V

E

R

S

I

T

Y

Peakflow SP router query types

• Router query types include the following:

I

N

D

I

A

N

A

U

N

I

V

E

R

S

I

T

Y

Peakflow SP Raw Flow queries

• Raw flow query types include the following:

I

N

D

I

A

N

A

U

N

I

V

E

R

S

I

T

Y

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

I

N

D

I

A

N

A

U

N

I

V

E

R

S

I

T

Y

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

I

N

D

I

A

N

A

U

N

I

V

E

R

S

I

T

Y

• 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

I

N

D

I

A

N

A

U

N

I

V

E

R

S

I

T

Y

• 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

I

N

D

I

A

N

A

U

N

I

V

E

R

S

I

T

Y

• 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

I

N

D

I

A

N

A

U

N

I

V

E

R

S

I

T

Y

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

Peakflow SP WSDL/SOAP

I

N

D

I

A

N

A

U

N

I

V

E

R

S

I

T

Y

• 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

I

N

D

I

A

N

A

U

N

I

V

E

R

S

I

T

Y

• 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

Python SOAP client

I

N

D

I

A

N

A

U

N

I

V

E

R

S

I

T

Y

• 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”

I

N

D

I

A

N

A

U

N

I

V

E

R

S

I

T

Y

Client side

I

N

D

I

A

N

A

U

N

I

V

E

R

S

I

T

Y

Client side

I

N

D

I

A

N

A

U

N

I

V

E

R

S

I

T

Y

Client side

I

N

D

I

A

N

A

U

N

I

V

E

R

S

I

T

Y

Client side

I

N

D

I

A

N

A

U

N

I

V

E

R

S

I

T

Y

Questions or Comments

John HicksIndiana University

jhicks@iu.edu