SSH Compromise Detection using NetFlow/IPFIX Rick Hofstede, Luuk - - PowerPoint PPT Presentation

▶
ssh compromise detection using netflow ipfix
SMART_READER_LITE
LIVE PREVIEW

SSH Compromise Detection using NetFlow/IPFIX Rick Hofstede, Luuk - - PowerPoint PPT Presentation

Jul 09, 2023 328 likes •920 views

SSH Compromise Detection using NetFlow/IPFIX Rick Hofstede, Luuk Hendriks 51 percent of respondents admitted that their organizations have already been impacted by an SSH key-related compromise in the last 24 months. Ponemon 2014 SSH

slide-1
SLIDE 1

SSH Compromise Detection using NetFlow/IPFIX

Rick Hofstede, Luuk Hendriks

slide-2
SLIDE 2

–Ponemon 2014 SSH Security Vulnerability Report

“51 percent of respondents admitted that their

  • rganizations have already been impacted by an

SSH key-related compromise in the last 24 months.”

2

slide-3
SLIDE 3

SSH Compromise Detection using NetFlow/IPFIX

Rick Hofstede, Luuk Hendriks

slide-4
SLIDE 4

SSH attacks

4

10000 20000 30000 40000 50000 60000 70000 500 1000 1500 2000 2500 3000 IP Time (s) FROM ATTACKER TO ATTACKER

(a)

slide-5
SLIDE 5

SSH attacks

4

10000 20000 30000 40000 50000 60000 70000 500 1000 1500 2000 2500 3000 IP Time (s) FROM ATTACKER TO ATTACKER

(a)

Start Brute-force Compromise Scan End

slide-6
SLIDE 6

SSH attacks

  • SSH intrusion detection on end hosts is hardly

scalable

  • Network-based approaches exist, but only inform

security operators about the presence of attacks

5

slide-7
SLIDE 7

We perform compromise detection.

slide-8
SLIDE 8

We perform compromise detection. All flow-based.

slide-9
SLIDE 9

SSH attacks

7

10000 20000 30000 40000 50000 60000 70000 500 1000 1500 2000 2500 3000 IP Time (s) FROM ATTACKER TO ATTACKER

(a)

slide-10
SLIDE 10

SSH attacks

8

2 4 6 8 10 12 14 16 500 1000 1500 2000 2500 3000 ppf Time (s)

(b)

slide-11
SLIDE 11

A bit of history…

9

slide-12
SLIDE 12

A bit of history…

  • SSHCure 1.0 (June ’12):
  • Purely deviation-based compromise detection
  • SSHCure 2.0 (May ’13):
  • Notifications, database maintenance,

performance profiling, …

9

slide-13
SLIDE 13

A bit of history…

  • SSHCure 1.0 (June ’12):
  • Purely deviation-based compromise detection
  • SSHCure 2.0 (May ’13):
  • Notifications, database maintenance,

performance profiling, …

9

2 4 6 8 10 12 14 16 500 1000 1500 2000 2500 3000 ppf Time (s)

(b)

slide-14
SLIDE 14

A bit of history…

  • SSHCure 1.0 (June ’12):
  • Purely deviation-based compromise detection
  • SSHCure 2.0 (May ’13):
  • Notifications, database maintenance,

performance profiling, …

9

slide-15
SLIDE 15

Recent/upcoming releases

10

slide-16
SLIDE 16

Recent/upcoming releases

  • SSHCure 2.4 (July ’14):
  • New compromise detection algorithm (CCR

paper release), based on ‘action upon compromise’

  • SSHCure 3.0 (January ’14):
  • New frontend, ingress vs. egress attacks

10

slide-17
SLIDE 17

Recent/upcoming releases

  • SSHCure 2.4 (July ’14):
  • New compromise detection algorithm (CCR

paper release), based on ‘action upon compromise’

  • SSHCure 3.0 (January ’14):
  • New frontend, ingress vs. egress attacks

10

Time Flow data chunk Target 1 Target n

(a) Maintain connection, continue dictionary (1)

Time Flow data chunk Target 1 Target n

(d) Maintain connection, abort dictionary (1)

SSH Compromise Detection using NetFlow/IPFIX. In: ACM SIGCOMM Computer Communication Review, October 2014

slide-18
SLIDE 18

Recent/upcoming releases

  • SSHCure 2.4 (July ’14):
  • New compromise detection algorithm (CCR

paper release), based on ‘action upon compromise’

  • SSHCure 3.0 (January ’14):
  • New frontend, ingress vs. egress attacks

10

Time Flow data chunk Target 1 Target n

(a) Maintain connection, continue dictionary (1)

Time Flow data chunk Target 1 Target n

(d) Maintain connection, abort dictionary (1)

Time Flow data chunk Target 1 Target n

(c) Instant logout, continue dictionary

Time Flow data chunk Target 1 Target n

(f) Instant logout, abort dictionary

SSH Compromise Detection using NetFlow/IPFIX. In: ACM SIGCOMM Computer Communication Review, October 2014

slide-19
SLIDE 19

Recent/upcoming releases

  • SSHCure 2.4 (July ’14):
  • New compromise detection algorithm (CCR

paper release), based on ‘action upon compromise’

  • SSHCure 3.0 (January ’14):
  • New frontend, ingress vs. egress attacks

10

Time Flow data chunk Target 1 Target n

(a) Maintain connection, continue dictionary (1)

Time Flow data chunk Target 1 Target n

(b) Maintain connection, continue dictionary (2)

Time Flow data chunk Target 1 Target n

(c) Instant logout, continue dictionary

Time Flow data chunk Target 1 Target n

(d) Maintain connection, abort dictionary (1)

Time Flow data chunk Target 1 Target n

(e) Maintain connection, abort dictionary (2)

Time Flow data chunk Target 1 Target n

(f) Instant logout, abort dictionary

SSH Compromise Detection using NetFlow/IPFIX. In: ACM SIGCOMM Computer Communication Review, October 2014

slide-20
SLIDE 20

Recent/upcoming releases

  • SSHCure 2.4 (July ’14):
  • New compromise detection algorithm (CCR

paper release), based on ‘action upon compromise’

  • SSHCure 3.0 (January ’14):
  • New frontend, ingress vs. egress attacks

10

slide-21
SLIDE 21

11

slide-22
SLIDE 22

SSHCure


Validation approach

  • Ground truth: sshd logs from 93 honeypots, servers

and workstations, divided over two datasets:

  • Dataset 1 — easy targets
  • Dataset 2 — more difficult targets



 


12

Honeypots Servers Workstations Attacks Dataset 1 13 636 Dataset 2 76 4 10353

slide-23
SLIDE 23

SSHCure


Validation results

  • Evaluation metrics:
  • TP / FP — correct / false identification of incident
  • TN / FN — correct / false identification of non-incident
  • Detection accuracy close to 100%

13

TPR TNR FPR FNR Acc Dataset 1 0,692 0,921 0,079 0,308 0,839 Dataset 2 — 0,997 0,003 — 0,997

slide-24
SLIDE 24

SSHCure


Deployment

  • SSHCure is open-source and actively developed
  • Download counter SourceForge (Dec. ’14): 3k
  • Recently moved to GitHub (summer ’14)
  • Tested in several nation-wide backbone networks
  • Many successful deployments already:

14

  • Web hosting

companies

  • Campus networks
  • National Research and Education

Networks (NRENs)

  • Governmental CSIRTs/CERTs
slide-25
SLIDE 25

Lessons learned

15

slide-26
SLIDE 26

Lessons learned

16

slide-27
SLIDE 27

Lessons learned

  • Ease-of-use is key

16

slide-28
SLIDE 28

Lessons learned

  • Ease-of-use is key
  • Many potential SSHCure users (e.g., CSIRTs) are less-

skilled than we are

16

slide-29
SLIDE 29

Lessons learned

  • Ease-of-use is key
  • Many potential SSHCure users (e.g., CSIRTs) are less-

skilled than we are

  • Installation scripts are important

16

slide-30
SLIDE 30

Lessons learned

  • Ease-of-use is key
  • Many potential SSHCure users (e.g., CSIRTs) are less-

skilled than we are

  • Installation scripts are important
  • Use of NfSen:

16

slide-31
SLIDE 31

Lessons learned

  • Ease-of-use is key
  • Many potential SSHCure users (e.g., CSIRTs) are less-

skilled than we are

  • Installation scripts are important
  • Use of NfSen:
  • Widely used in (European) NREN community

16

slide-32
SLIDE 32

Lessons learned

  • Ease-of-use is key
  • Many potential SSHCure users (e.g., CSIRTs) are less-

skilled than we are

  • Installation scripts are important
  • Use of NfSen:
  • Widely used in (European) NREN community
  • Experience with SURFmap [1]

16

[1] http://surfmap.sf.net/

slide-33
SLIDE 33

Lessons learned

17

slide-34
SLIDE 34

Lessons learned

  • Ingress vs. egress attacks

17

slide-35
SLIDE 35

Lessons learned

  • Ingress vs. egress attacks
  • Initial focus mainly on ingress attacks

17

slide-36
SLIDE 36

Lessons learned

  • Ingress vs. egress attacks
  • Initial focus mainly on ingress attacks
  • CSIRTs are becoming more responsible towards

the Internet: Keep it clean!

17

slide-37
SLIDE 37

Lessons learned

18

slide-38
SLIDE 38

Lessons learned

  • Integration into workflow is important

18

slide-39
SLIDE 39

Lessons learned

  • Integration into workflow is important
  • Yet another tool is hard to integrate into CSIRT

workflow

18

slide-40
SLIDE 40

Lessons learned

  • Integration into workflow is important
  • Yet another tool is hard to integrate into CSIRT

workflow

  • Integration with existing systems is necessary:

IODEF, X-ARF, QuarantaineNet, …

18

slide-41
SLIDE 41

Lessons learned

19

slide-42
SLIDE 42

Lessons learned

  • Advertizing is important

19

slide-43
SLIDE 43

Lessons learned

  • Advertizing is important
  • People don’t spot your cool project by

themselves

19

slide-44
SLIDE 44

Lessons learned

  • Advertizing is important
  • People don’t spot your cool project by

themselves

  • Visit meetings & conferences (FloCon,


TERENA TNC, RIPE, etc.)

19

slide-45
SLIDE 45

Lessons learned

  • Advertizing is important
  • People don’t spot your cool project by

themselves

  • Visit meetings & conferences (FloCon,

TERENA TNC, RIPE, etc.)

  • GitHub vs. SourceForge

19

slide-46
SLIDE 46

Lessons learned

20

slide-47
SLIDE 47

Lessons learned

  • 1:1 sampling is hardly used by non-academia

20

slide-48
SLIDE 48

Lessons learned

  • 1:1 sampling is hardly used by non-academia
  • Problem for our algorithms

20

slide-49
SLIDE 49

Lessons learned

  • 1:1 sampling is hardly used by non-academia
  • Problem for our algorithms
  • Admins are ‘afraid’ of increasing sampling rates

20

slide-50
SLIDE 50

Lessons learned

21

slide-51
SLIDE 51

Lessons learned

  • Input data quality is hard to predict

21

slide-52
SLIDE 52

Lessons learned

  • Input data quality is hard to predict
  • Algorithms should be as resilient to various data

sources as possible

21

slide-53
SLIDE 53

Lessons learned

  • Input data quality is hard to predict
  • Algorithms should be as resilient to various data

sources as possible

  • Examples:

21

slide-54
SLIDE 54

Lessons learned

  • Input data quality is hard to predict
  • Algorithms should be as resilient to various data

sources as possible

  • Examples:
  • Availability of TCP flags

21

slide-55
SLIDE 55

Lessons learned

  • Input data quality is hard to predict
  • Algorithms should be as resilient to various data

sources as possible

  • Examples:
  • Availability of TCP flags
  • Assumptions on flow cache entry expiration

21

slide-56
SLIDE 56

Thanks!

22

slide-57
SLIDE 57

Questions?

23

https://nl.linkedin.com/in/rhofstede/

www

http://rickhofstede.nl

@

r.j.hofstede@utwente.nl, rick.hofstede@redsocks.nl http://nl.linkedin.com/in/luukhendriks

www

https://luukhendriks.eu

@

luuk.hendriks@utwente.nl

https://github.com/sshcure/sshcure