FSU

Security

As Evi Nemeth puts it in USLAH:

Unix was not designed with security in mind, and for that reason no UNIX system can be made truly secure.

While I think that statement is becoming less obviously true with the compartmentalization now available via virtualization and semi-virtualized solutions like Docker and LXC, and with the increased security from using mandatory access control systems such as SELinux and TOMOYO, it is still valid.

Even the most security-conscious of all of the mainstream Unixes, OpenBSD, has had its flaws.

The basic flaws are in Unix are

As the ULSAH puts it:

Security = 1 / (1.072 * Convenience)

General rules of security

US Congress probes accidental top secret file sharing

Protecting fed workers from themselves



By Austin Modine
July 30, 2009

US Congress wants to know if new federal laws are needed to protect government employees from accidental file-sharing.

A House of Representatives oversight committee gathered on Wednesday to discuss whether government workers getting their hands on peer-to-peer software poses a risk to privacy and national security.

At issue are numerous cases of federal government employees and contractors who install P2P software on computers without realizing the sensitive documents they expose for sharing. According to the committee chairman, this is a problem with the software rather than user.

...

Towns laid out several past cases of apparent accidental file-sharing that lead to major security breaches on LimeWire. In one, the social security numbers and family information for every master sergeant in the US Army was made available. Another security breach involving the Secret Service resulted in the leak of a file containing a safe house location for the First Family. ...

From the The Register, July 30, 2009 at
http://www.theregister.co.uk/2009/07/30/house_committee_oversight_government_reform_p2p_security_hearing/

As Japanese Bring Work Home, Virus Hitches a Ride

By Bruce Wallace, Times Staff Writer

March 21, TOKYO

So far it has spilled military secrets and the private phone numbers of TV stars, airport security access codes and elementary school children's grades.

And the dirty work of this computer virus may not be done.

With almost daily reports of more private information being pumped from personal computers and splashed over the Internet, there is a growing unease that Japan is under insidious attack from within.

The culprit is a digital worm that infects computers using the file-sharing Winny software, a Japanese computer program that, like the infamous Napster, was designed to allow people to easily swap music and movie files.

From the Los Angeles Times, March 21st, 2006 at
http://www.latimes.com/news/nationworld/world/la-fg-computer21mar21,0,5159274.story

Japanese power plant secrets leaked by virus

Mystery malware and file sharing linked to third breach



By John Leyden
Published Wednesday 17th May 2006 16:06 GMT

Sensitive information about Japanese power plants has leaked online from a virus-infected computer for the second time in less than four months. Data regarding security arrangements at a thermoelectric power plant run by the Chubu Electric Power in Owase, Mie Prefecture in central Japan spilled online this week as a result of an unnamed virus infection, the Japan Times reports.

The name and addresses of security workers, along with other sensitive data including the location of key facilities and operation procedures, found its way onto file-sharing networks. A 40 year-old sub-contractor at the plant who installed the Share file sharing programs on his PC is suspected of provoking the security flap.

The power plant suffered a similar incident in January over data that found its way onto the Winny file sharing network, the most popular P2P network in Japan, which boasts an estimated 250,000 users. That incident provoked a management edict designed to prohibit the use of file sharing programs, so the occurrence of a similar problem only four months later is doubly embarrassing for Chubu Electric Power.

Chubu Electric is not the only power firm with problems in this area of net security, however. In June 2005, nuclear power plant secrets had been leaked from a PC belonging to an worker at Mitsubishi Electric Plant Engineering, anti-virus firm Sophos notes. That breach, just like the January security flap at Chubu Electric, was also linked to virus infection and the Winny file sharing program.

From The Register, May 17th, 2006 at
http://www.theregister.co.uk/2006/05/17/japan_power_plant_virus_leak/

Upper House confirms falling victim to cyber-attacks

Upper House confirms falling victim to cyber-attacks

The Upper House has confirmed being the latest victim of cyber-attacks on its servers and added that passwords of all lawmakers and secretaries may have been leaked to an outside hacker, officials said on Nov. 21.

Of the personal computers hooked to the network, the Upper House examined five of the 29 personal computers of lawmakers that had been forcibly connected to an overseas website.

As a result, it confirmed that all five computers had been used to gain unauthorized access to two Upper House servers between early August and mid-October.

One of the servers contained more than 700 passwords of all Upper House members and secretaries as well as those used by network managers. The other server is used to monitor operations of the network, according to the Upper House.

Obtaining passwords of network managers makes it possible for outsiders to gain access to and freely operate servers and personal computers hooked to the network.

The Upper House explained that the five computers for which unauthorized access was confirmed are suspected to have been infected with an unknown computer virus.

It commissioned a computer security company to conduct a detailed investigation of these computers and took the two servers off the network on Nov. 21 to conduct analysis.

In the Lower House, which has also been under cyber-attack, one personal computer was infected with a virus attached to an e-mail message in late July.

Investigations confirmed that the computer was used as "a steppingstone" to attack servers and steal a total of 2,676 passwords, including those used by all Lower House members and secretaries. At one time, it was also possible for the hacker to read the e-mail messages of all lawmakers.

Asahi, November 22, 2011

Darkhotel

Rules?

How is security compromised?

The weakest link is often the human element. Social engineering takes advantage of the fact that people generally are not distrustful, such as demonstrated by Nigerian 419 schemes, and by spear-phishing. Education is the only answer, and even then, education is only as good as the most recent attack — the latest scheme may catch even a user wary of previous methods. Even when their passwords were compromised, over half of the politicians in the upper house of Japan's parliament failed to create new ones.

Software problems are a second major category for security compromises. Patching is the main defense as this category.

``Open doors'' are the third way. While some software (and even hardware) may have backdoors built-in, it is often the case that people also leave the front door wide open. This is particularly true with items such as wireless routers, which are frequently configured ``to just work.'' As a system administrator responsible for other people's data, preserving both user access and confidentiality for that data, you need to be aware of keeping doors closed.

Specific areas: /etc/passwd and /etc/shadow

The most important concern is ensuring that users use appropriate passwords. You can (1) suggest that they use good passwords (2) try to enforce that they use good passwords and (3) try to check that they are using good passwords (``John the Ripper'' and ``L0phtCrack'' continue to be kept up-to-date, unlike older programs such as ``Crack.'' Also, GPU password crackers are now coming on strong, such as HASHCAT (clearly still current); also see Teraflop Troubles: The Power of Graphics Processing Units May Threaten the World's Password Security System.

Allowing group accounts is almost always more trouble than trying to keep /etc/group up-to-date.

Password aging: it is generally recommended that passwords be changed on a regular basis, although there has been back-and-forth discussion on that issue. Also, there is a contingent that are against any multi-use of a single password, with schemes such as OPIE that try to fix this problem.

Recent example of weak passwords and bad configuration

Here's an example of the combination of weak passwords and bad configuration being exploited to create a bot-net:

Botnet of OpenWRT/DD-WRT devices

``The people who bring you the DroneBL DNS Blacklist services, while investigating an ongoing DDoS incident, have discovered a botnet composed of exploited DSL modems and routers. OpenWRT/DD-WRT devices all appear to be vulnerable. What makes this worm impressive is the sophisticated nature of the bot, and the potential damage it can do not only to an unknowing end user, but to small businesses using non-commercial Internet connections, and to the unknowing public taking advantage of free Wi-Fi? services. The botnet is believed to have infected 100,000 hosts.''

From Slashdot, March 23, 2009 at
http://it.slashdot.org/article.pl?sid=09/03/23/2257252

Unix SETUID programs

File permissions

In times previous, one notorious problem was that of processes that had to look into kernel memory to find information. This was particularly true of programs such as top and ps (today, as mentioned previously, we get around this problem by walking the /proc directory.) Devices that referred to kernel memory, such /dev/kmem often had inadequate and unsafe permissions, or programs such as top had too much privilege for their intended function.

Make sure that no files in /etc are publicly writable. There is no good reason for any file in that subdirectory to be writable to the public. No files in directories such as /usr/bin or /usr/lib needs to be world writable.

Check your device files and make sure that important devices such as disk drives have appropriate permissions.

How do you do file permission checks in Unix?

This is one area where the find program shines for one-off checks. While its syntax is recondite, it can help you discover all manner of interesting things.

find /etc -type f -perm +022 -ls     # check /etc for any files that are 
                                     # group or world writable

find /etc -type d -perm +022 -ls     # check /etc for any directories that are
                                     # group or world writable

find /etc -type f -perm +6000 -ls    # check /etc for any files that are setuid or
                                     # setgid 

find /etc -mtime -14 -ls             # check to see what files in /etc/ have 
                                     # been modified recently

Remote Logging

Remote logging is common in larger installations.

Even with standard syslog, this is very easy to set up using the ``@'' syntax. For instance, the syslog.conf man page gives these example lines (slightly modified for clarity):

# Kernel messages are first, stored in the kernel
# file, critical messages and higher ones also go
# to another host and to the console
#
kern.*                       /var/log/kernel
kern.crit                    @finlandia
kern.crit                    /dev/console
kern.info;kern.!err          /var/log/kernel-info

ULSAH further suggests physically printing security information on an old line printer to prevent hackers from erasing their tracks. While that is good advice, it is not so easy to find an inexpensive true ``line printer'' these days. For most environments, a new dot matrix printer would likely suffice (but note that these are becoming more scarce also.) Continuous sheet printer paper is still available, but is now more expensive than stock lettersize or A4 paper.

Secure terminals

ULSAH mentions secure terminals. However, physical implementations are now archaic; even finding a serial connector on many machines is becoming less common, though not yet rare.

[If you do find such a setup with serial ports, generally the serial ports are connected to a ``terminal server'' or to a true switch (or even cascade of switches) in order to provide more convenient access to many servers.]

Use ssh keys

Passwords were bad ideas from the time that they originated, and they are not necessary these days.

Instead, you should use ssh keys. This is very easy to do; in fact, you can do as simply as

[langley@host1 Slides]$ ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/langley/.ssh/id_dsa): 
Enter passphrase (empty for no passphrase): [ some passphrase ]

Enter same passphrase again: 

Your identification has been saved in /home/langley/.ssh/id_dsa.
Your public key has been saved in /home/langley/.ssh/id_dsa.pub.
The key fingerprint is:
bb:5b:f6:c4:ed:1b:32:74:90:12:30:ab:60:fd:4b:66 langley@host1
[langley@host1 Slides]$ scp ~/.ssh/id_dsa.pub host2:.ssh/authorized_keys2
The authenticity of host 'host1 (128.186.120.121)' can't be established.
RSA key fingerprint is d1:99:0b:9c:b1:ce:87:7d:b7:8e:9a:b5:f1:aa:bc:b9.
Are you sure you want to continue connecting (yes/no)? yes

Warning: Permanently added 'host2,128.186.120.121' (RSA) to the list of known hosts.
langley@host2's password: [ use your password for host2 this time, not your new passphrase ]
id_dsa.pub                                    100%  615     7.1MB/s   00:00    
[langley@host1 Slides]$ ssh host2 
Enter passphrase for key '/home/langley/.ssh/id_dsa': [ some passphrase ]

Also, move your sshd to some other port than 22. Strongly consider also using a port knocker to hide your sshd.

NFS

NFS was not designed for security, and you must limit its deployment within strong firewalls. As ULSAH suggests, you should use access lists with fully qualified domain names (or ip numbers.) Squashing ids such as root is a very good idea when you export. When mount, setting ``nosuid'' is also a good idea.

An even better idea is to move users to sshfs; not only does that reduce the amount of configuration that you have to do (simply enable sshd), it makes it very convenient for users to maintain their own mounts.

email

If you really want to do ``best practices'' with mail security, running postfix or qmail, which were designed with security in mind is probably ``best practice.''

Proactive approaches: Scanning with nmap

One of the most useful programs for network security is a program called nmap. It can scan machines to see what services might be available. It can search large areas of a network for live machines. As its man page says:

DESCRIPTION
       Nmap is designed to allow system administrators and curious individuals
       to scan large networks to determine which hosts are up  and  what  ser-
       vices  they  are  offering.   nmap  supports a large number of scanning
       techniques such as: UDP, TCP connect(), TCP SYN (half open), ftp  proxy
       (bounce attack), Reverse-ident, ICMP (ping sweep), FIN, ACK sweep, Xmas
       Tree, SYN sweep, IP Protocol, and Null scan.  See the Scan  Types  sec-
       tion  for more details.  nmap also offers a number of advanced features
       such as remote OS detection via TCP/IP  fingerprinting,  stealth  scan-
       ning, dynamic delay and retransmission calculations, parallel scanning,
       detection of down hosts via parallel pings, decoy scanning,  port  fil-
       tering  detection,  direct (non-portmapper) RPC scanning, fragmentation
       scanning, and flexible target and port specification.

       Significant effort has been put into decent nmap performance  for  non-
       root  users.   Unfortunately,  many critical kernel interfaces (such as
       raw sockets) require root privileges.  nmap should be run as root when-
       ever possible (not setuid root, of course).

       The  result  of  running nmap is usually a list of interesting ports on
       the machine(s) being scanned (if any).  Nmap always  gives  the  port’s
       "well  known"  service name (if any), number, state, and protocol.  The
       state is either ’open’, ´filtered´, or ´unfiltered´.  Open  means  that
       the  target  machine  will accept() connections on that port.  Filtered
       means that a firewall, filter, or other network  obstacle  is  covering
       the port and preventing nmap from determining whether the port is open.
       Unfiltered means that the port is known by nmap to  be  closed  and  no
       firewall/filter  seems to be interfering with nmap’s attempts to deter-
       mine this.  Unfiltered ports are the common case  and  are  only  shown
       when most of the scanned ports are in the filtered state.

       Depending  on  options used, nmap may also report the following charac-
       teristics of the remote host: OS in use, TCP sequencability,  usernames
       running  the  programs  which  have  bound  to each port, the DNS name,
       whether the host is a smurf address, and a few others.

nmap in its most basic mode is usually quite fast:

# nmap diablo

Starting nmap V. 3.00 ( www.insecure.org/nmap/ )
Interesting ports on diablo.cs.fsu.edu (128.186.120.2):
(The 1595 ports scanned but not shown below are in state: closed)
Port       State       Service
22/tcp     open        ssh                     
111/tcp    open        sunrpc                  
139/tcp    open        netbios-ssn             
445/tcp    open        microsoft-ds            
515/tcp    open        printer                 
4000/tcp   open        remoteanything          

Nmap run completed -- 1 IP address (1 host up) scanned in 7 seconds

Here's what mail.cs.fsu.edu looks like:

# nmap mail.cs.fsu.edu

Starting nmap V. 3.00 ( www.insecure.org/nmap/ )
Interesting ports on mail.cs.fsu.edu (128.186.120.4):
(The 1590 ports scanned but not shown below are in state: closed)
Port       State       Service
22/tcp     open        ssh                     
25/tcp     open        smtp                    
80/tcp     open        http                    
111/tcp    open        sunrpc                  
143/tcp    open        imap2                   
652/tcp    open        unknown                 
847/tcp    open        unknown                 
858/tcp    open        unknown                 
993/tcp    open        imaps                   
995/tcp    open        pop3s                   
2049/tcp   open        nfs                     

Nmap run completed -- 1 IP address (1 host up) scanned in 4 seconds

Proactive approaches

There is an open source fork project of Nessus at http://www.openvas.org.

It is a full featured vulnerability scanner that is very popular for penetration testing. The server architecture is a bit dated, though, and would benefit from a makeover.

Proactive approaches: Exploits and Metasploit

Metasploit (http://www.metasploit.com/) has been around for many years. It's a framework for exploit management; it lets the community publish exploits in a uniform format for penetration testing. In the summer of 2011, it was used in the security exercise with several positive results.

tcpwrappers

The program tcpd (often called tcpwrappers) has an interesting history vis-a-vis firewalls. While logically firewalls would seem to be a more fundamental idea, tcpd actually showed up before good firewalls for Unix machines. The program tcpd lets you have reasonably fine-grained control over various ports on your machines, unlike, say, a firewall which basically lets you open or close a port, or the program stunnel which lets you (securely) redirect information coming into a port.

tripwire and aide

tripwire is still active as open source, though the company http://www.tripwire.com would of course like to sell you their full change management system. AIDE is another possibility.

Some cryptographic tools

Firewalls

In today's normal environment, you should try to run firewalls on all of your servers.

As ULSAH puts it, computer server firewalls are, like the firewall in your car, are not a primary means of defense and should not lull a system administrator into a false sense of security. You should have also firewalls that protect your whole site, and in large sites, it is likely that firewalls should be established between production, q/a, and development. You need to continue using other tools that we have discussed, such as nessus and tripwire to look for vulnerabilities, both from the outside of your network (aka ``outside penetration testing'') and from inside your network's firewalls.

As we have discussed before, configuring iptables is not hard; an example set of rules would look something like:

-A INPUT -j RH-Firewall-1-INPUT
-A FORWARD -j RH-Firewall-1-INPUT
-A RH-Firewall-1-INPUT -i lo -j ACCEPT
-A RH-Firewall-1-INPUT -p icmp --icmp-type any -j ACCEPT
-A RH-Firewall-1-INPUT -p 50 -j ACCEPT
-A RH-Firewall-1-INPUT -p 51 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp --destination-port 25 -j ACCEPT 
-A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited

Automating proactivity: Intelligent firewall management

Meeting at the juncture of firewalls and IDS are the idea of "intelligent" firewall management.

Here, instead of simply blocking connectivity via a firewall, we allow connectivity until it is abused. Once abuse is detected, a specific rule crafted for the undesirable activity is added, closing the undesired traffic.

Fail2ban

While there are a number of products that do this at both the network level and the system level, one of my current favorites is "fail2ban". Like the also popular "DenyHost" program, its IDS side is based on scanning logs. Unlike DenyHost, though, it is much more flexible and is designed to handle numerous services.

The idea is that the system administrator has a number of defined "filters" that detect undesired behavior, and a set of actions to apply when problems are detected.

Fail2ban configuration: dovecot.local

Here is a filter that I created to detect when Dovecot 1.07 is having a problem with a brute-force attack:


[Definition]

failregex = pop3-login: Aborted login: .*rip=::ffff:, lip=::ffff:.*
            imap-login: Aborted login: .*rip=::ffff:, lip=::ffff:.*

ignoreregex = 

Fail2ban configuration: jail.local

In order to use the filter, you have to include it in your "jail.local" file:

#
#  Local stuff 
#
[dovecot-iptables]

enabled = true
filter = dovecot
action = iptables-multiport[name=dovecot, port="pop3s,imaps", protocol=tcp]
         sendmail[name=dovecot, dest=root]
logpath = /var/log/dovecot.log
maxretry = 20
findtime = 600
bantime = 1200

Fail2Ban: behind the scenes

So what is really going on? How does fail2ban do its work?

It actively manipulates iptables. When it is first started, it creates a new ipchain:

# iptables -L -n
Chain INPUT (policy ACCEPT)
target            prot opt source               destination
fail2ban-dovecot  tcp  --  0.0.0.0/0            0.0.0.0/0           multiport dports 995,993
ACCEPT            all  --  0.0.0.0/0            0.0.0.0/0
REJECT            all  --  0.0.0.0/0            127.0.0.0/8         reject-with icmp-port-unreachable
ACCEPT            all  --  0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
ACCEPT            tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:993
ACCEPT            tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:995
REJECT            all  --  0.0.0.0/0            0.0.0.0/0           reject-with icmp-port-unreachable

Of course, when the ipchain is first created, it has no members:

target     prot opt source               destination
RETURN     all  --  0.0.0.0/0            0.0.0.0/0

However, whenever lines matching the "failregex" is detected in /var/log/dovecot.log, entries are added to that ipchain, dropping all packets from that source:

Chain fail2ban-dovecot (1 references)
target     prot opt source               destination
DROP       all  --  67.192.117.129       0.0.0.0/0
DROP       all  --  67.192.117.139       0.0.0.0/0
RETURN     all  --  0.0.0.0/0            0.0.0.0/0

Security summary

You can find more about current security issues via

Summary of Security, cont'd

Human factors to consider

Summary of Security, cont'd

Security and obscurity:

Best practices for rolling out new security patches:

Summary of Security, cont'd

Preparation: fingerprint your kernel, binaries, and libraries.

Keep the results on media that cannot be changed, such as burned to a cdrom.

Intrusion detection: