Tuesday, 16 March 2010

Property law for IT people

Property (as defined in legal terms) as is associated with servers, routers and information systems in general is known in the law as consisting of "chattels". Servers are chattels. The data are Intellectual Property.

There are a standard bundle of rights associated with property:
1 The right to control use of the property ,
2 The right to receive benefit from the property,
3 The right to assign, transfer or sell the property ,
4 and the right to exclude others from the property.

In the case of port scans we are looking at point 4, the right to exclude and point 1, the right to control. Rights as defined and used in this email are based on the Anglo-Saxon idea of exclusive right. This right is equivalent to the Civil law (Roman) idea of Dominus (see. Dominus enim dicit for those who like Latin). The dominus is more restrictive than common law property rights and Civil law (or codified law) rights of property are absolute rather than distributable as in the
English common law.

For this reason I shall confine this to the common law view of rights as much as possible. This view is one that is more commonly held in the "West" and Civil codified laws are more restrictive and more likely to enforce the rights of a property holder.

The rights we need to look at as was noted are the right of control and the right of exclusion.

The "right of control" is the right to determine how the property is used. "Uses" were originally the equitable or beneficial interests in the property. The right of control allows the system owner to determine how the system is to operate according to law. The system owner has the right to state that they do not allow ping (or any ICMP for example). To enforce this they could filter any ICMP traffic.

If in this example the system owner had determined that they would stop all ICMP traffic to/from the server, they could state this and than any access via ICMP would be a violation of the property rights. If the system owner had not taken steps to notify the public through some means (eg a terms notice on the primary web site) than the rights still exist but are not enforceable in law. This means that the act of trying to ping this server is illegal but there is no way to enforce this right.

To enforce the right the system owner has to do something to bring the right of control to the notice of the person who seeks to violate this right. An example here is a banner on a telnet login. The action is still illegal as stated, but there is not an action to enforce the right without the notification. The notification does not need to be ongoing. It just needs to occur. It does not even need to be particularly verbose or even grammatically correct. The notification does not even need to be sent using the same protocol. Sending an email off to the attacker would satisfy the requirement.

A simple manner of transmitting intent is to have ICMP responses allowed. By allowing this traffic and using ingress and egress filters, and sending ICMP type 3 replies. In particular type 3/13 replies could be sent (Communication Administratively Prohibited). Upon receiving this response, the person scanning has effectively received notification (eg like a banner). There is no legal requirement that they take notice of the packet, just that it is delivered.

Other ICMP types that would effect this include;
3/9 The destination network is administratively prohibited
3/10 The destination host is administratively prohibited.
3/11 The network is unreachable for Type Of Service.
3/12 The host is unreachable for Type Of Service.

Sending ICMP 3/9 is the most effective solution. (This is easy to configure on Cisco routers, other routers may or may not be able to achieve this). On receipt of the first packet, the person scanning is effectively notified. If they than "scan" or "test" any port on the network, they are effectively breaching the conditions as they have been notified to (similar to trespass on real property when you have asked the trespasser to leave and you have rights to the land).

If the person ports scans the site and ingress filters are configured to send ICMP 3/9 replies as soon as a packet is received to any port on any server other than the validly allowed ports, there is a breach. In this case, continued scanning becomes a breach of rights with an attached enforceable action. In this case you have the ability to litigate the person scanning the site civilly for a port scan and nothing more (i.e. no real damage).

Why do some people wait till you see a banner and log to that point? When you see the banner this becomes a course of action. If you keep scanning after seeing the banner, than you have an action in criminal terms and you do not need to have damage to be able to seek action.

The right of exclusion is the right to dictate what others can do. This means that the property owner has the right to exercise control and to dictate what level of access (if any) another has to the property. In respect to the Internet, access from your gateway to another server is completed under an effect of easement. There are both public and private easements. A public easement is one that grants the right to a large group of individuals or to the public in general. This in the terms of the Internet is analogous to the backbone routers.

A DOS or DDoS attack against DNS or the backbone routers is in effect the same as blocking access to someone who has an easement. It is a trespass upon the right of easement and creates a cause of action for civil suit. In most jurisdictions this is also not codified or in statute as a criminal offence. It is still illegal as a civil breach when not directly excluded.

Exclusion allows the property owner (in our case the system owner) to designate what actions are acceptable. They only need to state that an action is against the policy of the site for this to become an enforceable action, further, where the system is a state owned system (take US Federal government for example) all access is considered to be expressly controls unless access is expressly allowed.

What does this mean? A port scan, if the system owner does not welcome them is a violation of the property rights of the system owner. They breach the rights of exclusivity. The whether we see the system and its data as a "choses in possession" or a "choses in action" the act has to be one that is acceptable to the system owner. If we look to the Civil law, we have an analogous system with respect to movable property or movables.

Breach of an owner or possessors rights is a transgression in the nature of property law. There are actions for recovery or tort, but these require that there generally has been damage. None the less, a transgression of either the right to control or the right to exclude is still a violation of the fundamental rights of the owner of the property. A property law violation is not (generally) a criminal act without damage. This does not stop it from being illegal.

It is illegal in that it also can act to void a contract. If for example party A contracts party B to scan the systems of party C using a port scanner, party A could after receiving the report decide not to pay B for the services as the action is considered illegal and an illegal contract is not enforceable. There would be no punitive effect from this, but this does not change the action into a legal act.

Clear as mud? Well I hope that this has created a little more understanding of the law, rights and why they apply. To complicate this we could also look at equitable rights, but this would only lose more readers.

Damage the property or actually get access to the system and then we get into a who new area. This is where the criminal offences come to play.

Monday, 15 March 2010

Configuration of key network services (DNS, SMTP, etc.)

There are many key services on any network that people do not commonly think about until there is a problem. These services go for the most part unknown by many, but if they were to break or be compromised could have dire consequences for the organization. Simple services such as DNS provide the backbone to any network infrastructure. For the most part, the security of the Internet is tied to the security of services such as DNS. For instance, if an attacker can take over an e-commerce sites DNS it can install a man in the middle system to capture user names and passwords associated with a site as the clients use it.

For this reason, these services need to be treated with special care.

There are a number of simple rules that apply to configuring any key network system. These are:

1. Install the service on a dedicated host. This means running the service on a system that is built solely for this purpose. The only other applications on a host should be there to support the functioning and security of the system. Where possible, even remove windowing systems if they are not needed. BIND DNS software will run happily on Linux with nothing but itself and maybe an SSH service that is configured to be accessible from a secure administration host.

2. Run only those services that are absolutely needed. Rule number one leads to only installing those services that are absolutely needed. This is only those services necessary for the functioning of the key service. The host should be a bastion. It should be configured to be fit for purpose and nothing else (this does not mean turning off logs).

3. Ensure that the system is patched and up-to-date. Rule one makes this much simpler. The less services that are running on a host, the less that need to be patched and the less down time and cost that are associated with it. This means operating system patches, application patches and any other updates that could affect the security of the system.

4. Chroot where possible. In the UNIX chapter we introduce chroot (change root). This utility creates a virtual system root and adds an extra layer of defense to the system.

5. Removable vendor documentation and sample code. Many instances of IIS and Php-Apache web servers have been compromised because of vendor sample code. In this case, the application and the website could be secure, but with a backdoor built in. If you don’t use it remove it.

6. Run all services and applications using least privilege. Running a service as administrator or root is asking for trouble. Running a service with a guest level account will not stop it being compromised due to vulnerability, but will slow down the attacker. Slowing down the attacker gives the security administrator a chance to minimize the damage.

7. Modify service banners. Security by obscurity is not a good thing, but neither is making it easy for the attacker. Many automated systems and Internet worms based their attacks on an information and versioning. Many automated attack tools also function this way. This may not stop a determined attacker, but it will stop casual attacks.

8. Ensure logging and monitoring. Logging is critical. There is no compliance regime that allows logs to be disabled. Logging alone is better than nothing but without monitoring it becomes little more than forensic evidence after the event. Logs are affected when they are checked. In the Windows chapter we introduce a tool called DAD that can be used to correlate logs between multiple hosts.

9. Control remote administration. Control how the system is administered. Consider implementing a centralized system that administrators are required to look into first before connecting to the key systems and do not allow remote administration directly from the Internet. Use local firewalls and host-based IDS to control access. Always encrypted any administrative access and strongly consider alternate access control methods such as tokens or smartcards for authenticating users.

10. NEVER allow root or administrator access directly to the host other than from the console. On top of that restrict most console access. Whenever a user needs to access a key system with a valid reason they should do so under their own account. If they need to run something with administrator privileges they should run a utility such as SUDO (UNIX) or Run-as (Windows) to escalate their privileges.

11. Implement and monitor file integrity tools. Eventually something will go wrong. If an attacker does compromise a host that is running a correctly configured file integrity tool (such as AIDES or Tripwire) will firstly let you know what has changed and next allow the determination as to whether the box can be salvaged. Any host without an integrity tool that has any signs of compromise must be built from scratch. There are no exceptions to this rule. The call to rebuild or not rebuild a compromise host with file integrity tools should only be made by a suitably qualified individual.

12. Architect the system correctly. Look at where the system is placed in what controls help protect it. Consider network intrusion detection systems (NIDS) and network monitoring devices as well as firewalls. Look at how logging is protected. Syslog on UNIX for instance uses no authentication and is sent over clear text. An attacker could compromise logs without compromising a host unless these are protected somehow (e.g. IPSec VPN).

There are many key systems that will be available on any network. DNS, SMTP relays, log servers, NTP (Network Time Protocol) servers and authentication servers are just some of the many systems that need special levels of protection. These systems get compromised; the attacker can generally use them to expand their attack across the rest of the network.

Systems such as DNS cannot be excluded from any compliance exercise. For instance, Sarbanes Oxley (SEC financial system requirements in the US for listed and otherwise controlled entities) requirements cover the protection of systems involved in the reporting of financial statements. For this reason many individuals exclude DNS. The question to ask is how many users connect to a system using the host IP address? In particular, how many of the accounting and finance staff would even know the IP address of the server?

In this instance DNS is critical. If an eternal attacker could subvert DNS is likely that they could also take over any financial system in the organization. If DNS is compromised no reliance may be placed on the financial statements.

Know your key systems and protect them well. These are the organizations crown jewels.

Mail Relays

Open mail relays (SMTP gateways) with direct connections to the Internet are particularly vulnerable to attack. These systems are goldmines for Spammers and organized crime. What most organizations do not realize is that they are liable for spam and fraudulent statements that are forwarded using an insecure system for. Not only this, but many attackers use such systems to hide defamatory e-mails and to send abusive messages.

When configuring eight SMTP mail gateway consider the following:

1. Disable open relaying. Do not allow any domain and any address to send e-mail to from any location. This is not a difficult concept. The purpose of an organization’s e-mail server is not to provide free access to e-mail for the entire world. It is designed such that it can send and receive its own e-mail and it should be restricted for this purpose. Even free e-mail services such as Hotmail do not allow people to send and receive non-Hotmail related e-mails.

2. Disable commands such as VRFY and EXPN. VRFY (Verify) is designed to test the existence of an account. EXPN (expand) is used to expand e-mail groups to see who was a member of the group. For example, sales@company.com could have the entire sales department as a member. There is no need to allow spammers to test whether users exist or not. Allowing these commands on the mail gateway is asking for spam. There are worse problem is that could also occur.

3. Limit file transfer size. No matter what size files your users think they should be able to send there is always a limit. Apart from loss of information and critical information that can be sent via e-mail there are simple issues such as denial of service. If your e-mail server is running on a server with a 10 Gb disk it is unlikely that you would like to accept an 11Gb attachment. always place a limit on the maximum size of an e-mail.

4. Limit system access. Limit (by IP address) those addresses that can send mail to different addresses. If you only allow internal e-mail from inside your organization and do not allow Internet addresses to use your internal domain.

5. Scan for malware. Always check both incoming and outgoing content for malware. Most people understand the need to scan incoming e-mails. The issue is with e-mail that is going to other places. Just because an e-mail is leaving your organization does not mean you do not need to scan it. If a virus leaves your organization and infects another and you have not taken precautions, your organization will be liable for damages you have caused. It can be argued that they should have had their own antivirus solution, but the fact of the matter is that your organization is the root cause and you liable for the damages. Remember how damage much the “I love you” virus was estimated to have caused in 2000[1].

6. Implement content filtering. First there is the issue of what is both coming into and leaving your organization. E-mail is a common way for both staff and attackers to remove protected information. Worse, abusive or defamatory e-mails leave the organization liable to damages. The range of issues that can impact an organization through e-mail covered in the Legal Issues chapter.

7. Add a legal disclaimer to all e-mails. All e-mails, both incoming and outgoing should have a disclaimer. This is a simple thing to add to an e-mail that will save a lot of grief down the track. It may not stop something bad from happening but least it limits the liability of the organization to an extent.

8. Block mail from open relay blacklists and specific domains. There are blacklists containing the addresses of known spammers. In addition, if your system is constantly being attacked, block it. There is no necessity to accept e-mail from anywhere in the world. Look at where you expect to get e-mail from and what you need.

9. Use encryption where possible. Where possible encrypt the transmission of e-mail and the access to it. In particular, it is possible to use encrypted communications between internal divisions (such as Interstate or international e-mail servers) and it is potentially possible to encrypt e-mail between business partners.

10. Test the system regularly. Eicar files can be used to test that the virus signature is working. On top of this vulnerability testing tools such as Nessus can be used to ensure that no new vulnerabilities have appeared. These can also be automated so that they can report on new vulnerabilities as well. In some cases, sending an actual virus can be more effective than an Eicar file - But it can also be far far more dangerous.

Eicar files. An Eicar file is a test file that is designed to validate the functioning of an antivirus server. Of course, all antivirus engines put a lot of effort into testing Eicar files.


DNS is that unknown worker which goes considered until there is a problem. DNS resolves host names to IP addresses (and also conversely IP addresses to host names). Without DNS the Internet would stop. This is a big claim until you realize that people do not remember numbers. We can remember several thousand names but we cannot remember even 50 IP addresses easily.

Even within organizations DNS is key to the security of access as individuals connect to named servers and (usually) not to IP addresses. To secure a DNS server is essential to consider the following points:

1. Restrict zone transfers. DNS zone transfers are needed from the primary DNS to the secondary. Never allow anything else, not even secondary to secondary transfers.

2. Disable recursive checks and retrievals. There is no reason to allow recursive queries from ever host on the Internet. At best it is a waste of resources, at worst an attack path.

3. Log ALL zone transfer attempts. Any attempt to do a zone transfer should be treated as an incident. This is always going to be someone or some program looking for information about the configurations of systems. This should never be permitted.

4. Restrict queries. Not all queries are necessary. Information that is not necessary should be restricted on a need to know basis.

5. Restrict dynamic updates. Only authorized hosts should be allowed to change DNS entries.

6. Deploy split DNS. Split DNS involves logically and physically separating the external and internal address spaces.

o External IP addressing should include that information that is necessary for services on the Internet to function correctly.

o Internal IP addressing should be restricted to your organizations own systems.


A DNS Server is recursive when it assumes the duty of resolving the answer to a DNS query. DNS servers are generally recursive by default. Exposed recursive servers can be used by attackers (e.g. Cache poisoning attacks). At best they are lost system resources doing lookups for unrelated entities.

Bind version 8.x and above provide the capability to configure the server to be non-recursive with selected exceptions for explicit IP addresses. This allows the servers to answer recursive queries for the organizations own hosts while blocking recursive queries from unauthorized hosts on the Internet.

To configure DNS correctly:

· Recursive queries can be allowed for internal DNS

· Recursive queries should be blocked for external hosts

Where there are exceptions (for roaming hosts for instance) these can be configured separately.

Zone Transfers

Secondary DNS servers use the zone transfer function to update changes to the DNS zone databases. These changes are received from the primary (or SOA, Start of Authority) DNS servers.

Only allow zone transfers between the primary and secondary DNS servers. Secondary DNS severs should never be allowed to respond to a zone transfer request.

Do not block TCP 53 and think that you are ok. TCP is used for valid DNS queries. The blocking of TCP port 53 is breaking DNS and not fixing zone transfers.

Split DNS

Split DNS involves the logical separation of the external and internal name resolution functions.

· Information that is necessary for hosts on the Internet is maintained on the external DNS servers.

· Information about the internal hosts and IP space is maintained and resolved using the internal DNS servers.

· When a system is required to support reverse PTR lookups, generic information should be provided. PTR records do not matter they are just required to resolve to something. To have reverse PTRs work requires a name… ANY name. This is NOT the real internal name.

Split-Split DNS

A split-split DNS is the idea DNS architecture. In figure 19.4, the split-split DNS architecture is displayed. This involves a back to back private address DMZ segment with two firewalls (it is possible to do this with a single firewall and 3 interfaces as well). The DMZ network and internal private network each have:

• Two DNS Advertiser hosts on the DMZ

• Two DNS Resolver hosts on the DMZ

• Two internal DNS servers on the internal network


Figure 1 Split-Split DNS

There are at least two of each kind of server to provide for fault tolerance and load balancing. At least one of each type will be primary and the other a secondary DNS server (Windows Active Directory DNS servers do not use this system). Zone transfers are allowed only to occur between the primary and secondary servers. This is:

o External DNS. Acts as an advertiser and resolver system

o Internal DNS. Acts as to resolve queries for internal client hosts

o Each zone needs its own Primary and Secondary DNS. Zone transfers should only be allowed from primary servers to secondary servers (and not the other way)

Split-split DNS has multiple DNS servers located in the DMZ. Separate DNS servers provide name and domain advertising and resolution. A pair of DNS servers are positioned within the internal network as well. These are all run as duplicates to provide fault tolerance and load balancing.

A total of at least six DNS servers (three primary and three secondary servers) are required for a split-split DNS configuration. The three classes of DNS servers are:

· DNS Resolvers. DNS resolvers provide only DNS caching. These systems are configured to be DNS forwarders and allow access only from the internal network hosts.DNS resolvers do not maintain a DNS zone database and are not authoritative for any domains. This setup allows split-split DNS to aid in stopping DNS hijacking attacks.

· DNS Advertisers. DNS advertisers maintain the organizations domains that are “advertised” over the Internet (the organizations authoritative zones). DNS advertisers don’t allow recursive queries to be preformed.

· Internal DNS Servers. Internal DNS servers resolve queries that originate from the internal network hosts. Internal DNS servers function identically to internal DNS servers in a “split DNS” setup.

[1] The “I love You” virus (actually a worm) was estimated to have caused around US$ 10 billion worth of damages. See http://money.cnn.com/2000/05/05/technology/loveyou/ and http://library.thinkquest.org/04oct/00460/ILoveYou.html for more information.