Presentation on theme: "Sockets and Services CS-480b Dick Steflik. Evaluating Socket Based Services How complex is the service? How might the service be abused? What information."— Presentation transcript:
Evaluating Socket Based Services How complex is the service? How might the service be abused? What information does the service dispense? How much of a dialog does the service allow? How programmable or configurable is the service? What other services does the service rely on? What sort of authentication does the service use?
How complex is the service ? Complex services are easier to exploit than simple ones –the more complex it is the more possible points there are that a hacker can try to exploit DayTime is as simple as a service can get –A connect is recognized by the server and the server responds and closes the connection; no user input required. –About the only exploit would be DoS by flooding service with requests POP is more complex –possible password theft (remember they are not encrypted) theft of data loss of privacy –could try buffer overflows on any command possibly crash server –DoS attempt
How might the service be abused ? Hackers are very creative and will abuse a service in any variety of hard to imagine ways –hijacking taking over a valid users connection –redirecting rerouting a users connection to another host –DoS flooding the service with requests for service redirecting Chargen output to some unsuspecting computer could flood it with data that it didnt request
What information does the service dispense ? Some services provide deliver extensive user information –Finger was originally created to allow UNIX users to locate one another on a UNIX system; depending on configuration parameters none, minimal or extensive user information can be delivered –Whois is another service that dispenses user information Consider blocking these services altogether –they make it too easy to identify users or make it to easy for a hacker to validate the existence of a userid –at least block incoming requests,if incoming is required insist it be used via VPN
How much of a dialog does the service allow? The more complex the dialog presented by the service the harder it is to secure –HTTP is a simple stateless protocol and is easy to secure –FTP is complex and hard to secure stateful protocol uses two ports (20, 21) extensive command structure user ids and passwords are often the same as system user ids and passwords A complex dialog presents many possible points of attack
How programmable or configurable is the service? Many modern services have literally hundreds of configuration parameters –abundant room for misconfiguration errors –poor testing and pressure to meet product release dates is conducive to buggy code and/or development code to still be in the code SMNP, RIP and OSPF are used for remote configuration of network devices should never allow incoming requests for these protocols Some services (HTTP, LDAP…) allow remote administration via web interfaces (HTML, ActiveX or Java) –if possible allow only localhost access
What sort of authentication does the service use ? If authentication is done in the clear (POP3, telnet, Basic HTTP…) it is easily intercepted by anyone using a sniffer program –HTTPs base 64 encoding of passwords isnt really secure as it is easily decoded or worse yet recorded and replayed Authentication is best if credentials are encrypted –public key techniques –challenge/response protocols Password guessers –should watch for and log multiple password failures use reverse DNS to find domain