securing linux
E N D
Presentation Transcript
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! • higher level attacks focus on software • especially daemons • lower level attacks focus on hardware • IP and MAC addresses • two very powerful tools • telnet • netcat
topics • attacking passwords • DNS issues • routing issues • trusted hosts • attacking applications
topics (cont'd) • advanced packet sniffing • ping of death and teardrop • denial of service (DoS) • distributed denial of service (DDoS) • honey pots
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
attacking passwords • countermeasures: • understand the default settings • set passwords as appropriate • no dictionary words • understand weak / common passwords • google “500 worst passwords”
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
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
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
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
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
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
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
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
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
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
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
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
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
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>
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
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
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
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!
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
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!
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
attacking applications • countermeasures: • block port 2049 at gateway firewall • do NOT use NFS! • consider more modern / secure alternatives • such as Andrew File System (AFS)
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
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)
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
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
attacking applications • countermeasures: • keep software up-to-date • pay attention to all configuration file options • uninstall unused software
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
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
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!
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
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
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
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
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
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)
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
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
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
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
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
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
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