1. Trang chủ
  2. » Công Nghệ Thông Tin

Cryptography and Network Security doc

8 171 0

Đang tải... (xem toàn văn)

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Định dạng
Số trang 8
Dung lượng 49,5 KB

Nội dung

Sockets and Services CS-480b Dick Steflik 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 user’s connection – redirecting • rerouting a user’s 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 didn’t 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 – HTTP’s base 64 encoding of passwords isn’t 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 . 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. 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. 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

Ngày đăng: 29/03/2014, 15:20