Presentation is loading. Please wait.

Presentation is loading. Please wait.

Honeypots as a Tool to Improve Incident Response Readiness at USP

Similar presentations


Presentation on theme: "Honeypots as a Tool to Improve Incident Response Readiness at USP"— Presentation transcript:

1 Honeypots as a Tool to Improve Incident Response Readiness at USP
Alberto Camilli Isabel Chagas Centro de Computação Eletrônica Universidade de São Paulo Educause Security Professionals Conference 2007 Denver 12 April 2007 Copyright CCE, Alberto Camilli, M. Isabel T. Chagas, 2007. This work is the intellectual property of the author. Permission is granted for this material to be shared for non-commercial, educational purposes, provided that this copyright statement appears on the reproduced materials and notice is given that the copying is by permission of the author. To disseminate otherwise or to republish requires written permission from the author.

2 Agenda University of São Paulo, numbers and IT organization
USP and the national Honeynet project USP honeypot-based Early Notification procedure and results Q&A

3 Presentation Objectives
Show how honeypots take part in the incident notification process, how they are configured and managed at USP. Main incident statistics for USP. Show what changes in the management of honeypots at USP lead to a change in the campus profile of incidents, with reduction in quantity and in the solution times.

4 University of São Paulo Research Extensive
State University (São Paulo) 185 in ISI rank: indexed papers citations 2.270 PhD, MSc Undergraduate students 4.884 faculty staff graduate students 8 main campuses, 60% based in São Paulo (city) 85 “federation-like” Units (Teaching, Services and Extension) Annual budget near US$ 700 M Universities devoted to research in Brazil are mostly offered by public institutions, either sponsored by the federal goverment or state government. There are also private institutions but normally they dont do research. The University of Sao Paulo is a state University, it is the one of the oldest and most traditional university respect diverse criterias, either geographic or respect to research, As we can seem from the numbers. There are 8 campuses in 5 different cities, mostly located in SP city.

5 Centro de Computação Eletrônica da USP
Main USP Computer Center NOC and CSIRT 24x7 operation 400m2 data center HPC main facilities for the University (e.g. computer 363o. in Top500 list)

6 USP Network Connections
Internal GEANT ( EUROPE / SPAIN ) External MG RJ Internet Commodity USA and Brazil SC POP Clara ( Global Crossing ) RS Internet 2 USA POP RNP ( USP ) ANSP SP Internet USP Enclave Kyatera Test Bed Registro BR METRO IX ( Non Commercial ) GIGA Test Bed TV In green we see the actual USP network backbone connectivity schema, in dark blue our connectivity to the federal network. We can also see our connection to Internet 2 and Geant. USP Ribeirão Preto USPnet 600Mbps I/O Internet commodity traffic 1,000 Buildings; 50,000 network points (80.000) accounts 850,000 /day (20% valid) USPnet Telefonica Metro SP Medical Schools USP Bauru USP Pirassununga USP Piracicaba USP ( Cidade Universitária ) USP São Carlos Hospitals

7 USP IT organization 143.107.xxx.xxx /16 200.136.xxx.xxx /20
Dean Adm. USP business rules Internal Units Administration CIO IT services and infrastructure campus 1 Business IT CSIRT USP Internal-External Campus Notifications IT in USP now broadly organized in two branches, one for the Administration of the day-by-day life of the University, like alumni registration and life-cycle, purchases, payment of salaries, and other network was only for academic purposes. The CIO’s role is to promote the development of infrastructure and teaching support initiatives having less influence on the IT related to business. Historically, for security concerns, two separate networks are available, with different IP range numbers, specially because administrative operations were of the client-server type, being the client computer a dumb terminal. The IP numeration were subnetted and distributed among the Units being simple to localize which Units are promoting a security incident by looking at its IP number. Now there is a tendency of these two IT structures become unified because with the advent of Web, the security is now at the application level and because unification of academic and administrative ID is in course. Notifications to/from the external world are done only by CSIRT USP. Incidents are then notified to the local Unites by the local CISIRTs which report back to CSIRT USP. In many cases CSIRT USP notifies directly Units in other campuses specially when an rapid incident solution is required. Initially we put honeypots only in the academic network which is a full class B. Recently we also put honeypots security in the the administrative network but they showed no attack coming from internal nework which is probably an inheritance of the old days’ security still being implemented. ID_#inc Local CSIRT1 Campus Computer Centers CSIRTs Notifications External campus n Local CSIRT2 Internal Campus Notifications ID_#inc ID_#inc

8 USP and the Brazilian Honeypot Alliance
Ribeirão Preto USP Piracicaba USP São Carlos USP Cidade Universitária Coordination by CERT.br:

9 The Project Brazilian Honeypots Alliance Distributed Honeypots Project
Coordination: CERT.br and CenPRA Research Center Use of low interation honeypots Based on voluntary work of research partners 37 research partner instituitions Industry, telcos, academic (USP and others), government and military networks Each partner provides Hardware and network Honeypot(s) maintenance

10 USP Motivation To increase USP’s capacity of:
Incidents identification and knowledge Incident detection Event correlation with other Entities Trend analysis Which Units are more vulnerable? Very Useful for Incident Response Sensors distributed in several campuses

11 USP Honeypots Location

12 Brazilian Honeypot Alliance Architecture
Netblock range from /28 to /24

13 Data Usage Incident response (CERT.br): Partners:
Identify well known malicious/abuse activities Worms, bots, scans, spams and malwares in general Notify the Brazilian networks´contacts Including recovery tips Partners: Observe trends and scans for new vulnerabilities Detect promptly: Outbreaks of new worms/bots Compromised servers Network configuration errors What about USP usage?

14 Honeypots project: how good it was (july06) after 3 years?
Gigabit backbone July 06 Honeypot (CERT.br) External Internal 90% 10% But ... how better can it become?

15 A closer look at our honeypot data...
1. Threats from the outside Different External IPs Port 80 Protect applications! Protect backbone routers!

16 A closer look at our honeypot data ...
2. Where and how the internal network is being attacked same subnet type of attack, e.g.: 135(tcp), 445(tcp) Protect Windows desktop! Protect subnet!

17 Worm Propagation Times
300 min = 5 hs Typical log for a honeypot at USP Worm propagation Model [1] ~ 10 hs then ... early notification? [1] Zou C., Gao L., Gong W. Monitoring and Early Warning for Internet Worms. CCS’03

18 Timeline logic in Early Notification
Tp1 Tne Tni Tca Propagation Notification Cert.br Notification CSIRT-USP Correction Action Time Contamination (int) Improper Action (ext) CERT.br CSIRT Handling CSIRT Handling Local CSIRT End of Incident Tn = max (Tne,Tni) Tp2 Tca Time O propósito do HP é indentificar prematuramente a contaminação, minimizando o Tc+Tn O propósito do CSIRT USP é minimimzar Tn Notification CERT.br OR CSIRT-USP Tp2 = Tp1 – some measured average Tca ??

19 Early Notification (EN) procedure
Hypothesis Unnoticed attacks should now begin to be identified. CSIRT-USP is able to notify attacks in advance. Units will be able to react accordingly to block these attacks. What we did? Notifiy the victims as soon as an internal attack is being observed No further considerations about the nature of the attack. Why? We want better incident scores and honeypot logs are at our disposal. How and when? A daily script generates a summary of the attacks. Each attacked Unit receives the summary notification from CSIRT-USP, as a new security incident ticket.

20 Internal notifications message format
CSIRT USP messages (daily summary): Subject: [Honeypot] Máquina(s) suspeita(s) ( ) Content: zzz.yyy : 139(247) nnn.mmm : 135(202) 137(573) 139(3041) 1433(183) 445(1302) 80(568) Cert.br messages (on IP basis): Subject: zzz.yyy: host(s) infectado(s) com Agobot/Phatbot Apr 27 13:30: zzz.yyy.3683 > xxx.xxx.xxx : S [tcp sum ok] (src OS: Windows XP SP1, Windows 2000 SP4) : (0) win <mss 1460,nop,nop,sackOK> (DF) (ttl 123, id 20447, len 48) number of attempts

21 Internal notifications results after 6 months of EN adoption
Antecipated 6hs by CSIRT-USP Same data, Different analysis criteria,Different Interpretations

22 Overview of EN results CSIRT USP/Cert.BR internal notifications
2002-july 2006: internal notifications only from Cert.br Notifications Increase External Internal Before EN 90% 10% After EN 50%

23 Classification of Incidents at USP
Definition Notification Expression or Symptoms Characteristics Possible Causes or Aggravants Internal CSIRT from USP alerting local Units worm/trojan in USP’s local nw CSIRT USP Cert.br Port Scans Brute Force Correlated events Self propagating Difficult to correct Difficult to isolate Exploring address space Non protected machines Unpatched machines (mostly Windows) Infected machines Open Services External External entities complaining with USP about a problem in their nw External entities External CSIRTs P2P Defacement Spam Open Proxies Open/Relays Phishing/Scam Isolated Events Not self propagating Easy id of causes Easy correction Inadequate user behaviour Bad configuration Long term contaminated machines

24 Top 10 Units solution time (before and after EN)
Tca (days) Incident Solution Time (avg) ΔT% Internal Incident Solution Time (avg) ΔTi% External Incident Solution Time (avg) ΔTe% 01-06 07-12 (EN) ID_173 10 9,4 -6% 6,5 10,8 66% 10,3 7,2 -30% ID_146 16,8 11,4 -32% 13,4 11,3 -16% 16,9 11,6 -31% ID_ 112 20,4 15,5 -24% 11,2 15,2 36% 22,2 12,6 -43% ID_ 86 12,4 15,9 +28% 7,0 8,2 17% 12,5 14,7 +18% ID_70 18,5 16,1 -13% 4,6 16,2 152% 20,3 19,4 -4% ID_55 7,6 -14% 5,8 -44% 6,8 +6% ID_ 39 8,1 -49% 17,9 7,9 -56% -38% ID_39 17,2 7,8 -55% 15,3 8,21 -46% 17,6 -59% ID_38 14,4 4,9 -65% 10,0 5,7 14,6 1,8 -88% ID_36 8,9 6,9 -22% 9,7 3,2 -67% 8,8 8,7 -1% 2006 Period Unit ID 1, ,00 POLI 2, ,00 CIRP 3, ,00 FEA 4, ,00 EESC 5, ,00 IB 6, ,00 FFLCH 7, ,00 ECA 8, ,00 FMRP 9, ,00 IO 10, ,00 CISC 11, ,00 IF 12, ,00 IGC 13, ,00 IFSC 14, ,00 IAG 15, ,00 IME

25 Top 10 Units incidents (before and after EN)
(2006) All Incidents ΔI % Internal Incidents ΔIi % External Incidents ΔIe% 01-06 07-12 (EN) ID_173 48 115 140% 3 81 2600% 45 34 -24% ID_146 69 77 12 % 5 50 2500% 64 27 -58% ID_112 36 114 % 66 1220% 31 11 -65% ID_ 86 23 63 174 % 1 25 2400% 22 38 73% ID_70 15 55 267 % 40 3900% ID_55 13 42 223% 4 29 625% 9 44% ID_ 39 28 155% 2100% 10 6 -40% ID_39 20 19 -5% 12 1100% 7 -63% ID_38 21 17 -19% 2 500% -74% ID_36 12% 8 700% 16 -31% 2006 Period Unit ID Corr(all,ext)=0,73 Corr(int,ext)=0,22 Corr(int1,ext1)=0,58 Corr(ΔTe%, ΔIe%)=0,85 POLI CIRP FEA *EESC IB *FFLCH ECA FMRP IO CISC IF IGC IFSC IAG IME now, a closer look to the profiles of incidents ...

26 Incident Profile ID_146 Before EN (69): After EN (77): F(t)=1-eλt
16% 12% 16% 49% After EN (77): Tca ~ 20+ day F(t)=1-eλt 25% 65% Tca ~12 day

27 Incident profile ID_112 Before EN (36): January-July 2006
After EN (77): July-December 2006 6% 14% 8% 39% 28% 86% 19% External (Spam, Open-Proxy, Other) “vanished”

28 EN limitations CSIRT USP Notification rate Local team internal
Overloaded Capacity (λ´) Spare Capacity (λ) external internal F(t)=1-eλt internal internal external external internal internal Incident solution rate Feedback to CSIRT Local Responses are limited by local Capacities Capacity  (skills, technology, staff/bw, staff/computers, ...) Local Capacities are related to the Local Incident Profiles (symptom)

29 Other (very) interesting profiles ...
Similar Units profile (BW utilization, Staff, Technology, ....) External Internal Obs. ID_56 54 2 Linux ID_44 41 3 FW ID_3 ID_20 14 6 IFSC, IAG, FSP, IQ Linux and good firewall management Minimum contamination by worms Little interaction to CSIRT-USP, no influence from notification process. none from CSIRT USP !

30 Incident Response Readiness at USP
Early notification is essentially a CSIRT procedure that relys on: Honeypots, for the localization and identification of the problem Available local internal capacities, for problem solving Long term Incident reduction and better responses can be achieved with: Education Specializing local CSIRT managers Training of local teams, to improve correction actions General User Education (especially on Windows): diversified public: students, professors, administration Preventive actions, to keep volume of internal notifications under manageble limits Anti-virus distribution Bandwith control Network access control Institutional network scanning Other Specific tools on-going Automática x Manual Classificação dos incidentes Tarefa não trivial Importância da experiência Novo incidentes ou reincidência (qdo no mesmo IP) Resposta das Unidades Externos respondidos antes Mais fácil identificar a causa HP indicam problemas que requerem habilidades dos administradores das redes – falta de treinamento específico under study

31 Summary Action taken by CSIRT-USP Possible Benefits Achieved results
Notification by CSIRT USP (jul/06) Train CSIRT staff ORCA-like monitoration with selectable features Deployment of more honeypots (jan/07) Antecipate treatment of local incident Improve awareness and local treatment Identify local profiles and capacities Attack identification and analysys Improve CSIRT relationships Broader coverage of incidents notified (not obvious) Reduction in incident lifetime (not obvious) Reduction of external incidents (not obvious) Visual “Real-time” incident monitoring (feb/07)

32 Conclusions End-user’s freedom is normally obtained with some degree of computers contamination. Honeypot is an effective way to detect early stages of contamination and to support the development of actions against later stages of the worm’s cycles. Honeypot monitoration is centralized and demands minumum infrastructure support Honeypots permit suggest local actions according to Unit’s profiles Gobal worm mitigation doesn’t necessarily mean local worm mitigation. Honeypot-based Early Notifications by CSIRT-USP changed the profile of security incidents at USP Incidents are closed in shorter times External incidents has been reduced

33 Special Thanks CISRT USP TEAM Marta Bazzo Cilento
Hamilton Jun Higashizono André Gerhard Rogério Herrera Mendonça Luis Ferreira Bruno Darigo Fernando Fugita Solange Vieira Olavo Rodrigues

34 References Brazilian Honeypots Alliance – Distributed Honeypots Project CCE CERT.br Honeyd Several papers about the project USP Other Zou C., Gao L., Gong W.;Monitoring and Early Warning for Internet Worms. CCS’03 Dagon D., Zou C., Lee W.; Modeling BotNet Propagation Using Time Zones. NDSS’06 [1]

35 Q&A Thank you!


Download ppt "Honeypots as a Tool to Improve Incident Response Readiness at USP"

Similar presentations


Ads by Google