1 / 68

securing linux

attacks from the outside. securing linux. outside versus inside. attacks from the outside have all the cool toys have all the notoriety attacks from the inside less glamorous but more likely to be the source of an attack!. overview. attacks may focus on different layers!

milly
Download Presentation

securing linux

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. attacks from the outside securing linux

  2. outside versus inside • attacks from the outside • have all the cool toys • have all the notoriety • attacks from the inside • less glamorous • but more likely to be the source of an attack!

  3. overview • attacks may focus on different layers! • higher level attacks focus on software • especially daemons • lower level attacks focus on hardware • IP and MAC addresses • two very powerful tools • telnet • netcat

  4. topics • attacking passwords • DNS issues • routing issues • trusted hosts • attacking applications

  5. topics (cont'd) • advanced packet sniffing • ping of death and teardrop • denial of service (DoS) • distributed denial of service (DDoS) • honey pots

  6. attacking passwords • default passwords (fixing stupid) • in software, such as webmin • in hardware, such as routers • pre-installed passwords are not secure • the whole world has access to them! • Google “default passwords” • Service level passwords • service

  7. attacking passwords • countermeasures: • understand the default settings • set passwords as appropriate • no dictionary words • understand weak / common passwords • google “500 worst passwords”

  8. attacking passwords • password guessing • the infamous “guest” / “guest” account • original UNIX passwords used DES • maximum of 8 characters • if alphanumeric characters, then 62 ^ 8 • brute force cracking is possible • brutus (windows) • brutus.pl (linux) • common sources for passwords: • Star Wars, Star Trek, Lord of the Rings, ... • dictionary searches are possible – no common words

  9. attacking passwords • countermeasures: • use MD5 or blowfish rather than DES • passwords should exceed 16 characters • disable finger and rwho services • which freely give away user id • thus reducing work for the cracker • set time delay following invalid login • to the largest tolerable value

  10. attacking passwords • packet sniffing • normally, a network interface card retrieves only packets destined for its MAC address • however, a network interface card can be placed in promiscuous mode which retrieves all packets • packet sniffers look at all passing packets to glean information • examples: • tcpdump • ethereal • hunt

  11. attacking passwords • packet sniffing can be reduced somewhat by using switches rather than hubs • hub: packet distributed along all branches • switches: packet distributed along single branch

  12. attacking passwords • plain text passwords are obvious security risk • telnet, rlogin, rsh, rcp ftp • http, pop3, imap • openSSH provides secure connections • slogin, ssh, scp, sftp, https • information encrypted

  13. attacking passwords • openSSL – secure socket layer • stunnel wrapper for an insecure transaction • insecure service normally listens on port number X • stunnel is configured to listen on port number Y • a secure connection implemented on port number Y • information redirected to insecure service on port number X To secure a connection on a SMTP server, stunnel maps insecure port 25 to 465. Traffic passes via SSL to port 465 to the stunnel application which transparently forwards it to port 25

  14. DNS issues • both attacks based upon UDP protocol • first response is assumed to be correct response! • two forms of attack: • DNS spoofing • DNS cache poisoning

  15. DNS issues • DNS spoofing • eavesdropper (packet sniffer) attempts to respond faster than DNS server • provides incorrect IP address in response to query • countermeasures: • utilize switches rather than hubs • to reduce packet sniffing abilities • DNSSEC is being developed • to enhance overall DNS security

  16. DNS issues • DNS cache poisoning • caching speeds up DNS process by reducing the number of queries • a renegade server can provide additional incorrect information in response to a query • countermeasures: • upgrade BIND utility • keep software up to date • split DNS service • internal (trusted) server versus • external (untrusted) server

  17. routing issues • attacks seek to take advantage of features within routing to enhance communication • four forms of attack: • IP forwarding • source routing • dynamic routing tables • ICMP redirection

  18. routing issues • IP forwarding • gateway machines are essential to connect networks, but not every dual-homed host needs to function as a gateway • example: • public web server communicates with private database • countermeasures: • disable IP forwarding where appropriate • echo 0 > /proc/sys/net/ipv4/ip_forward

  19. routing issues • source routing • it is possible to specify a path through a large network from source to destination • netcat -g <IP1> -g <IP2> ... <destination> • packets appear to come from last source • countermeasures: • disable source routing • on Linux • echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route • on routers

  20. routing issues • dynamic routing tables • routing tables can be static (unchanging) • routing tables can be dynamic (changing) • dynamic tables useful for larger networks • Linux daemons: routed or gated • however, information from routers • can be spoofed (unreliable source) • can be spurious (unreliable data) • countermeasures: • disable dynamic routing • do not activate routed or gated daemon • manually configure static routing table

  21. routing issues • ICMP redirection • if multiple gateways exist in a large network, then routers must communicate best routes and redirect traffic • once again, information from routers • can be spoofed • can be spurious • countermeasures: • disable ICMP redirection • echo 0 > /proc/sys/net/ipv4/conf/all/accept_redirects • manually configure gateways • route add -net <net_addr> gw <gw_addr>

  22. trusted hosts • if plain text passwords are a bad idea, then requiring no password is even worse! • tcp-wrappers (inetd and xinetd) • /etc/hosts.allow permissible users • /etc/hosts.deny unacceptable users • based on IP addresses which can be spoofed • ifconfig eth0:0 inet <IP_spoof_address> • netcat -S <IP_spoof_address> -D <target> • decisions based solely on the source IP address should be considered questionable

  23. trusted hosts • other offenders: • rlogin, rsh, rcp • /etc/hosts.equiv ~/.rhosts • slogin, ssh, scp, sftp • /etc/hosts.equiv ~/.shosts • nfs network file system protocol • /etc/exports • plus tcp-wrappers • nis network information service protocol • /etc/defaultdomainname • plus tcp-wrappers

  24. trusted hosts • countermeasures: • never use the above features!!! • except on the most trusted private networks • understand that any IP address can be spoofed • drop all incoming packets at the gateway firewall that have private IP addresses

  25. attacking applications • default or poor configuration • too many system administrators use the default configuration for software which comes with the Linux distribution • either universally known • or universally available on the internet • too many system administrators do not know how to properly configure the software they use • poor choices • incorrect options • in either case, crackers will exploit these weaknesses!

  26. attacking applications • RPC: remote procedure calls • support mechanism for two popular utilities • NFS and NIS • does not require dedicated ports • portmapper daemon (port 111 TCP and UDP) • maintains table of utilized ports for active services • portmapper table is available to public • rpcinfo -p <server> • nmap -sS -sR <server> • recent Linux distributions have incorporated portmapper within tcp-wrappers • /etc/hosts.allow and /etc/hosts.deny

  27. attacking applications • UNIX RPC • called Open Network Connect (ONC) • Windows RPC • called Distributed Computing Environment (DCE) • countermeasures: • block port 111 at gateway firewall • do NOT use RPC!

  28. attacking applications • NFS: network file system • created in 1989 by Sun Microsystems • utilizes port 2049 TCP and UDP • server configuration file • /etc/exports • inappropriate use of wild cards • bad, world accessible file systems • worse, world writable file systems • information readily available • showmount -e <server> • contents of file /etc/exports • showmount -a <server> • displays currently mounted file systems

  29. attacking applications • countermeasures: • block port 2049 at gateway firewall • do NOT use NFS! • consider more modern / secure alternatives • such as Andrew File System (AFS)

  30. attacking applications • NIS: network information system • distributes important files across the network • /etc/hosts, /etc/networks, /etc/passwd, /etc/groups • information readily available • ypwhich • ypcat <file> • passwords (although still encrypted) are clearly visible

  31. attacking applications • countermeasures: • block port 111 at gateway firewall • do NOT use NIS! • consider more modern / secure alternatives • such as Lightweight Directory Access Protocol (LDAP)

  32. attacking applications • countermeasures: • turn off all unnecessary services • keep software up-to-date • SuSE Yast On-line Update (YOU) • Red Hat Up2Date • pay attention to log files for signs of attack

  33. attacking applications • network clients • both server and client must be correctly configured • both server and client must communicate correctly • examples: • e-mail buffer overflow in From: entry • web malicious JAVA script, poor cgi scripts • GnuPG format string bug in early version

  34. attacking applications • countermeasures: • keep software up-to-date • pay attention to all configuration file options • uninstall unused software

  35. attacking applications • X11 issues • X11 is built on server – client model • unlike Windows the client and the server need not be the same computer! • more flexibility => more security issues! • typical server – client model is reversed • server = keyboard, mouse, monitor • client = application on remote host • typical attacks: • keystroke capture • screenshots

  36. attacking applications • countermeasures: • limit graphical login (xdm, kdm, gdm) to localhost • block port 177 on the host • disable X11 services to the network • block ports 6000:6064 on the host • startx -- --nolisten tcp • restrict access to X server using the xhost command • require authentication using Xauth utility

  37. attacking applications • openSSH issues • openSSH is a highly recommended secure application • supports: • remote login • file transfer • remote shells • it is highly configurable • even including options which reduce its inherent security!

  38. attacking applications • pay special attention to the following files: • /etc/ssh/ssh_config system-wide configuration • ~/.ssh/config person configuration • include the following entries • host * • ForwardX11 no • ForwardAgent no

  39. advanced packet sniffing • although switches are preferable to hubs, switches are vulnerable • ARP spoofing enables software, like hunt, to circumvent this feature • packet floods to a switch may cause the switch to revert to the performance of a hub

  40. advanced packet sniffing • session hijacking • rather than passively watch packets go by, a cracker can assume the identity of either host in a communication socket • usually done after a user has obtained elevated privileges (to super user) • a cracker can even return control to the original user as if only a minor system glitch had occurred

  41. advanced packet sniffing • software: • hunt • dsniff (suite of tools) • dsniff • dnsspoof • arpspoof • sshmitm man in the middle • webmitm man in the middle • ettercap • netwox / netwag

  42. man in the middle • attack against secure communications • exploits weakness in human nature • does not exploit weakness in the secure protocol • normal (secure) communication • A contacts B • B sends a certificate verifying itself to A • A begins communicating with B

  43. man in the middle • man in the middle attack • C contacts B • B sends a certificate verifying itself to C • C begins communicating with B • C spoofs or poisons DNS for A • diverting packets intended for B to C • A contacts B (really C) • C sends a certificate verifying itself to A • A ignores the pop-up box • A begins communicating with B (really C)

  44. man in the middle • man in the middle attack (cont'd) • C now controls the communication • C has options: • can relay • can replay (with modifications that benefit C) • countermeasures: • pay attention to certificate pop-ups! • read • verify • disconnect if uncertain

  45. intrusion detection software • monitor network traffic for signs of suspicious activity • more sophisticated than ntop in its analysis • appears to be a developing area of study • software • snort • firestorm • prelude

  46. ping of death and teardrop • the following two attacks are based on the fundamental structure of packets • ping of death • ICMP packet size should not exceed 65,536 bytes • a larger packet caused a buffer overflow condition • teardrop • large packets are divided and must be reassembled • multiple packets that do not reassemble caused a kernel panic

  47. ping of death and teardrop • countermeasures: • newer Linux kernels are not susceptible • keep the Linux kernel up to date • newer routers automatically filter such packets

  48. denial of service • an explicit attempt by attackers to prevent legitimate users from accessing a service • flavors • ICMP ping flood • TCP SYN flood • UDP flood • ICMP smurf flood • local resource exhaustion

  49. denial of service • ICMP ping flood • simple ping command, but deliver packets as fast as possible • ping -f -s 2048 <target> • countermeasures: • filter ICMP echo requests

  50. denial of service • TCP SYN flood • a rapid sequence of SYN request with no matching ACK packet • tries to overflow the TCP half-open connections queue • countermeasures: • during a SYN flood • increase the size of the half-open connections queue • /proc/sys/net/ipv4/tcp_max_syn_backlog • decrease the value(s) in the following files • /proc/sys/net/ipv4/timeout_synack • /proc/sys/net/ipv4/timeout_synrecv

More Related