securing linux

securing linux

attacks from the outside

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


– 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


• countermeasures:– block port 2049 at gateway firewall

– do NOT use NFS!

– consider more modern / secure alternatives

» such as Andrew File System (AFS)


– 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


• countermeasures:– block port 111 at gateway firewall

– do NOT use NIS!

– consider more modern / secure alternatives

» such as Lightweight Directory Access Protocol (LDAP)


– 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


• 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


– 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


– 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


• 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!


– 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


• 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


• 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

denial of service

• UDP flood– targets two systems

• targetA echo port port 7

• targetB chargen port port 19

– send UDP packet to targetA• source IP address as targetB

• source port as chargen port (character generator)

• destination IP address as targetA

• destination port as echo port

– especially cool if targetA and targetB are the same computer!

denial of service

• countermeasures:– disable chargen service– disable echo service– disable inetd / xinetd

denial of service• ICMP smurf flood

– ICMP echo request is sent to a broadcast address

• with spoofed source IP address

– generates multiple echo replies• potentially one from each host in the network

– example:• nemesis-icmp -I 8 -S <target> -D <broadcast>

– countermeasures:• disable broadcast requests

– echo 1 > /proc/sys/net/ipv4/icmp_ignore_broadcasts

– echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all

denial of service

• local resource exhaustion– although not an attack over the network, it is a

form of denial of service• fill up the storage area on a disk partition

• fill up a sharable system resource queue

– countermeasures:• use Linux quotas

• use the Linux ulimit command

• use the Linux /etc/security/limits.conf file

distributed denial of service

• a denial of service from a single source is bad enough

• imagine the impact if hundred (or thousands) of computers coordinated an attack– unfortunately university systems are often

accomplices in these attacks• more open environment

• more relaxed security


• reflector attack– simplest of the DdoS attacks– send packets to numerous systems using a

spoofed source IP address

distributed denial of service• Trin00 Aug 99 against Univ of Minn

• exploits against RPC services – a cracker compromises a large number of

hosts– a small number of hosts are designated

handler nodes to help coordinate the attack– a large number of hosts are designated agent

nodes to carry out the actual attack– all communication is done via UDP

• each packet contains a password– to prevent other crackers from taking control!

– each agent launches a simple UDP flood

distributed denial of service• tribe 2000

– builds upon the trin00 concepts– communication is done via ICMP, UDP, or TCP– can spoof IP addresses– can change its process name to hide itself from

detection– can launch a variety of attacks

• ICMP ping flood

• TCP SYN flood

• UDP flood

• ICMP smurf flood


• countermeasures:– incorporate all the countermeasures for a

simple denial of service

• note:– you can not prevent a denial of service– you can only minimize its impact– you can help ensure that your computer(s) do

not participate in a distributed denial of service

honeypots

• a recent addition to the field of security has been the concept of a honeypot

• in essence, a honeypot is a decoy host designed to lure a cracker away from more valuable hosts and servers

• some honeypots have been said to lure approximately 85% of the SPAM intended for a network away from the actual mail server

honeypots

• flavors of honeypots:– a honeypot

• appearance of a simple server running crackable software with poor firewall

• intended to lure cracker toward it

– a complete virtual network• appearance of a huge network of identical secure

machines

• intended to frustrate the cracker with the amount of work necessary to find a worthwhile target

honeypots

• flavors of honeypots (cont'd)– a sticky pot

• appearance of a simple server running crackable software with poor firewall

• with the added feature of designed to steadily impede the cracker's host

honeypots• software:

– honeyd– labrea– thp– arpd– fakeap

• WARNING: Sticky pots, such as labrea, may violate Illinois state law! It is against state law to impede or slow electronic communication even if the affected party is in violation of other laws.

concluding comments

• fundamental principles:– always keep software up to date– never run unnecessary services– Less is more -- if you don’t know what it does

turn it off / uninstall unused software

• i would like to add two more:– implement egress filtering at the gateway

firewall– never retaliate against a potential cracker

egress filtering

• egress filtering drops any outgoing packet whose source address is NOT from the local area network– everybody knows to filter incoming traffic!– filtering outgoing traffic would effectively stop a

large percentage of IP spoofing– packets that do not meet security policies are

not allowed to leave - they are denied "egress“– Egress filtering helps ensure that unauthorized

or malicious traffic never leaves the internal network

retaliation• retaliation is a poor choice for several

reasons:– the offending host may itself be a compromised

computer• now the poor guy is getting it from both sides

– just like in sports, it is the second punch that the officials see

• retaliation leaves you open to legal liabilities

– if you do the basic, then you only annoy the cracker

• retaliate, and you have made an enemy for life!

firewalls • additional comments regarding a gateway firewall

– fundamental rule for firewall building• that which is not expressly permitted should be denied• default policy for INPUT, OUTPUT, FORWARD should be

DROP– preferable to DROP packets than REJECT them

• REJECT is too friendly!– allows source host to quickly move on (rather than

time out)– conveys that the target host is up and running

• exception: ident port 113 should REJECT– some services perform ident lookups

firewalls revisited

• additional comments (cont'd)– a fourth outcome for firewall rules is -j LOG

• create an entry in the system logs

• continues analyzing subsequent packet rules!

– user-defined tables• in addition to INPUT, OUTPUT, and FORWARD

• each table is search sequentially– order of rules is important

• can facilitate search speed– rather than search long tables (sequential search)

– jump directly to appropriate small table (binary search)

securing linux

Documents

Transcript of securing linux