Generic Server Indexing

21 

Loading....

Loading....

Loading....

Loading....

Loading....

Full text

(1)

Generic Server Indexing

Based on Common Attributes of Server Traffic

Aun Yichiet, USM

Prof. Dr. Sureswaran Ramadass, IUMW Dr. Selvakumar Manickam, USM

(2)

Conventional Server Definition

u  Limited types and easily recognized

u  Configured and defined by network admin

DHCP DNS

SMTP (Email Server) FTP (Data Server) HTTP (Web Server)

(3)

Servers Type Diversifications

DHCP DNS Web Server FTP SMTP Database Playback Smart Hub

Media Server Streaming Server

(4)

Server Identification

u  Network Admin Knowledge (Current)

u  Human resources intensive when number of nodes expand

u  Definition ambiguity, diversity?

u  ‘Blind spot’ – configuration-less/user configured server

u  Discovery protocols (Current)

u  UPnP, UDDI, JINI, SLPv2 – FRAGMENTATION problem

u  Fully Pervasive (Proposed)

u  Automatic server identification

u  Passive, Unsupervised, universal (for TCP/IP), true real time

(5)
(6)

Input/Output

Unclassified Nodes Dedicated Server

(7)

Input/Output

DHCP DNS SMTP FTP Unclassified Nodes Dedicated Server Generic Server

(8)

Input/Output

DHCP DNS SMTP FTP Unclassified Nodes Dedicated Server Generic Server

Server ID {IP, MAC,PORT} .PCAP File

(9)

Server Discovery & Indexing

ID Server Name

Server Type IP MAC Port Confidence

Level 1 Airplay Media, Streaming 192.168.1.88 AE:BC:AA:CC:DD:AD 16800 80%

2 Dota 2 Game Server 202.133.14.81 - 5600 100%

3 HP Print Print Server 192.168.1.10 AE:CC:BB:CC:DD:AA 137 100% 4 HP Print 2 Print Server 192.168.1.10 AE:CC:BB:CC:DD:AC 138 100% 5 Apache Web Server 192.168.1.10 AE:CC:BB:CC:DD:AA 8080 60%

(10)

Server-Client Profile Resolution

Consensus Based TCP Command Match

SYN-FIN Flags Check Server Specific Command

Well Known Port

Consensus Based TCP Command Match

SYN-FIN Flags Check Server Specific Command

Well Known Port

Node A Node B

Flow 2323

(11)

Consensus Based Server Discovery

§  Based on correlation of server-client traffic flow

direction

§  Server listening, client initiate, server response

§  {IP a, Port x} to {IP b, Port y}, 50% 50% chance

for both to be server

§  {IP c, Port x} to {IP b, Port y}, higher chance for

(12)

TCP SYN/FIN Initialize-Response

TCP

§  Based on TCP/UDP header flags

§  Client send SYN, Server replies SYN+ACK

§  Client send FIN (full close)

UDP

§  Monitor initiator of flow for a period of time

§  If B consistently start connection to A, B is client

A is server

§  Need preprocessing to discard incomplete flow/

(13)

Server Command Matching

u  TCP Port Status – the states of port at a given monitored point

Command Type LISTEN SERVER CLOSED SERVER ESTABLISHED CLIENT SYN_RECEIVED SERVER TIME_WAIT CLIENT

(14)

Service Specific Command

u  FTP: PASV, CWD

u  HTTP: GET

u  SIP: HANDOFF, FORWARD

(15)

DISCOVERY PERFORMANCE vs.

Sample

Size

0 5 10 15 20 25 30 Improvement Magnitude Protocols/Method (i)

Number of Unique Server Found (N) Improvement

Magnitude (M)

100 Packets 500 Packets 1000 Packets 2500 Packets 4000 Packets

Admin Defined 2 (2) 3 (3) 11 (3) 53 (4) 76 (4) 6.75

Common Servers 3 (3) 3 (3) 17 (5) 73 (5) 138 (6) 4.5

Fixed Port Based 8 (8|5) 52 (11|5) 88 (17|5) 103 (19|7) 212 (23|8) 3.375

PSDL 0 (0) 0 (0) 0 (0) 0 (0) 0 (0) 27 UPnP 1 (1) 3 (3) 8 (3) 33 (7) 98 (9) 3 UDDI 0 (0) 1 (1) 1 (1) 4 (2) 13 (2) 13.5 Jini 0 (0) 0 (0) 0 (0) 0 (0) 0 (0) 27 INS 0 (0) 0 (0) 1 (1) 3 (2) 9 (2) 13.5 SLPv2 1 (1) 12 (1) 33 (2) 52 (2) 77 (2) 13.5 Proposed Method 88 (32|9) 411 (178|11) 879 (223|13) 2100 (387|16) 4783 (631|27) 1

(16)

Protocols/Method (i)

Number of Server Found

Cumulative Improvement Magnitude Average Cumulative Improvement Magnitude 12-8am 8-12pm 12-2pm 2-5pm 5-12am Admin Defined 3 (3) 4 (3) 4 (6.5) 4 (6.75) 5 (3.4) 22.65 4.53 Common Servers 1 (9) 4 (3) 5 (5.2) 5 (5.4) 2 (8.5) 31.1 6.22

Fixed Port Based 3 (3) 8 (1.5) 8 (3.25) 7 (3.86) 5 (3.4) 15.01 3.002

PSDL 0 (9) 0 (12) 0 (26) 0 (27) 0 (17) 91 18.2 UPnP 1 (9) 4 (3) 3 (8.67) 5 (5.4) 3 (5.67) 31.74 6.348 UDDI 1 (9) 1 (12) 2 (13) 2 (13.5) 1 (17) 64.5 12.9 Jini 0 (9) 0 (12) 0 (26) 0 (27) 0 (17) 91 18.2 INS 0 (9) 0 (12) 1 (26) 2 (13.5) 1 (17) 77.5 15.5 SLPv2 0 (9) 2 (6) 2 (13) 2 (13.5) 2 (8.5) 50 10 Proposed Method 9 (1) 12 (1) 26 (1) 27 (1) 17 (1) 1 1 [x(y)]

x=unique number of server

y=relative improvement per block

(17)

PERFORMANCE vs

TEMPORAL INFO

(18)

PERFORMANCE vs

Temporal INFO

(HOME LAN)

Protocols/Method (i)

Number of Server Found

Cumulative Improvement Magnitude Average Cumulative Improvement Magnitude 12-8am 8-12pm 12-2pm 2-5pm 5-12am Admin Defined 2 (6) 0 (3) 2 (2.5) 1 (7) 2 (6) 24.5 4.9 Common Servers 2 (6) 3 (1) 3 (1.67) 2 (3.5) 3 (4) 16.17 3.234

Fixed Port Based 3 (4) 2 (1.5) 5 (1) 4 (1.75) 4 (3) 11.25 2.25

PSDL 0 (12) 0 (3) 0 (5) 0 (7) 0 (12) 39 7.8 UPnP 7 (1.71) 1 (3) 3 (1.67) 6 (1.17) 7 (1.71) 9.26 1.852 UDDI 0 (12) 0 (3) 0 (5) 0 (7) 0 (12) 39 7.8 Jini 0 (12) 0 (3) 0 (5) 0 (7) 0 (12) 39 7.8 INS 0 (12) 0 (3) 0 (5) 0 (7) 0 (12) 39 7.8 SLPv2 0 (12) 0 (3) 0 (5) 0 (7) 0 (12) 39 7.8 Proposed Method 12 (1) 3 (1) 5 (1) 7 (1) 12 (1) 39 7.8

(19)

PERFORMANCE vs

TEMPORAL INFO

(20)
(21)

Towards Server Identification in IOT Age

u  New types of devices, new type of services, new server category and classes

u  Conventional ways : admin, disc protocols reliability?

u  New way to automatically detect servers that are diversified

u  We proposed a UNIVERSAL, PASSIVE, UNSUPERVISED method to detect & index

server type of many diversity

u  BEST CASE against closest competing method (LAN): up to 300% (3x)

Figure

Updating...

References

Updating...