Protecting against the unknown


           A guide to improving network security to protect the
            Internet against future forms of security hazards



                    Mixter <mixter@newyorkoffice.com>,
 
                              January 2000






  Contents


  0           About
  0.1         Copyright
  0.2         Disclaimer
  0.3         Acknowledgements

  1           Introduction
  1.1         Preface
  1.2         Document scope and structure
  1.3         Problem description
  1.3.1       Security threats summary
  1.3.2       Problem definition
  1.4         Basic concepts

  A short-term approach

  2           Conceptual security measures
  2.1         Taking the systematic approach
  2.2         Designing a security model
  2.3         Problems in a corporate environment
  2.4         Preparing against an incident
  2.5         Incident response
  2.5.1       Reacting to an ongoing incident
  2.5.2       Post mortem: Incident recovery

  3           Technical security measures
  3.1         Strong resource protection
  3.1.1       Defending your system integrity
  3.1.1.1     Setting up a secure environment
  3.1.1.2     Establishing access controls
  3.1.1.3     Application security
  3.1.1.4     Auditing - reactive and proactive measures
  3.1.2       Defending your data confidentiality
  3.1.3       Defending your network availability
  3.1.3.1     Guidelines to defensive routing
  3.1.3.2     Tracing: capabilities and problems
  3.2         Problem specific protection
  3.2.1       Protecting against viruses
  3.2.2       Using Intrusion detection systems
  3.2.3       Backdoors and trojan horses
  3.3         Conclusions about present security technology

  A long-term approach

  4           Proposed future security architecture improvements
  4.1         Improving incident response capabilities
  4.1.1       A new approach to incident consulting
  4.1.2       Incident response and law enforcement
  4.1.3       Establishing an incident response infrastructure
  4.2         Operating systems
  4.2.1       Privilege separation and kernel-based security
  4.2.2       Kernel-based authentication
  4.2.3       Privilege and permission separation
  4.2.3.1     Sand boxes versus protective cages
  4.2.3.2     Differentiated access permissions
  4.2.4       Auditing requirements
  4.3         Auditing software
  4.3.1       Evolving intrusion detection
  4.3.2       Evolving proactive auditing technology
  4.4         Networking architecture
  4.4.1       Routing security
  4.4.1.1     Improving availability
  4.4.1.2     Improving access controls and authenticity
  4.4.2       Protocol security
  4.4.3       Public Key Infrastructure
  4.5         Improving software design
  4.5.1       Technology standards
  4.5.2       Network application security
  4.5.3       Software development security design methodology


  5           Final words

  6           Footnotes: technical background, definitions and explanations















  0         About this paper


  0.1       Copyright

  This document was written by Mixter <mixter@newyorkoffice.com>. Technical
  solutions, ideas and concepts in this document have mostly been developed by
  the author unless referenced or acknowledged otherwise. This paper by Mixter,
  named 'Protecting against the unknown', is a candidate entry for the Packet
  Storm Security Competition 'Storm Chaser 2000'.
  The author hereby represents his eligibility to participate in the
  Competition and to satisfy all requirements specified in the Competition
  Rules issued by Packet Storm. The author presents that he independently
  created the document and waives his intellectual property rights in the
  Competition entry. Furthermore, the author has acknowledged, signed and
  agreed to all terms of the Packet Storm Affidavit of Eligibility and
  Liability and Publicity Release, which has been attached to the submission.


  0.2       Disclaimer

  This document and the information contained herein is provided on an 'as is'
  basis and the author disclaims all warranties, express or implied, including
  but not limited to any warranty that the use of the information herein will
  not infringe any rights or any implied warranties of merchantability or
  fitness for a particular purpose.
  Please note that the author's native language is not English. My apologies
  in advance in case you should find any formal mistakes in this document.


  0.3       Acknowledgements

  This paper was improved by many insights I have been able to gain from
  a large number of people engaged in the security community. Although the
  paper was completely written by myself, knowledge and experience I gained
  from these sources were needed to make it possible for me to compose this
  document. Some of these sources that I would like to specifically acknowledge
  are: Bugtraq Security Mailing List / SecurityFocus, BufferOverflow /
  Hackernews, many of the detailed articles from authors of Phrack Magazine,
  OpenSEC contributors, site maintainers of security archives and security
  related sites, authors of open source security software (no advertisement
  here, you know who you are) as well as the authors of publications and texts
  referenced in the footnotes section.





  1         Introduction


  1.1       Preface

  Since the Internet has begun evolving from an academic and military resource
  to a public world-wide computer network utilized by numerous commercial and
  non-commercial organizations and individuals, and on which modern society is
  becoming increasingly more dependent, there have been many security [1]
  issues, some of them exposing weaknesses in the security model of the Internet
  itself. While the importance of computing will advance in our society, one of
  the first and biggest problems concerning the evolution of computing is the
  improvement of applied Internet security technology. With increasing speed
  and complexity of technology and software development, the number of security
  issues as well as their severity and impact on the Internet community is
  tending to grow drastically, and so are the security incidents caused by the
  growing number of intruders that are actively exploiting weaknesses in current
  security models and by intrusion software [2] becoming more sophisticated.
  While defense against specific intrusion software is futile, because private
  attacking software and techniques can be developed that either can hardly be
  identified or possess no methodological weaknesses which could be used to
  stop them, the security problem has to be conquered using coherent, logically
  applied, systematic security improvement and protection efforts.
  This paper attempts to define the problem and answer the question:
    What pure or applied technical measures can be taken to
    protect the Internet against future forms of attack?
  In order to develop a defense strategy against future threats, one has to
  take into account that the proposed solution needs to include effective
  countermeasures against an unknown threat potential. An approach to this
  solution needs to be formed upon a differentiated set of measures against
  current weaknesses and threats, and against upcoming security issues,
  extrapolated by analyzing existent weaknesses and core problems in the
  security infrastructure of the Internet. It has to be regarded that current
  threats like distributed attack tools [3] do not represent security 
  vulnerabilities themselves, but multiply and visualize the potential of
  existent problems present in the current security architecture model.


  1.2       Document scope and structure

  The security improvement measures described in this document are designed
  to provide guidance to everyone who needs to improve the security of his
  network or machine that is publicly accessible over the Internet, including
  ISP and corporate technicians, executive managers, government and military
  executives, network administrators, security consultants and all other
  individuals requiring or wanting to improve their computer security.
  Covered topics include problem and threat definition, potential security
  issues and active countermeasures, concrete technical requirements and
  methods, as well as conceptual and procedural security measures.
  To provide a coherent security solution to upcoming and partially yet
  unidentified security problems means to design a new security architecture,
  instead of trying to solve issues by designing reactive solutions to known
  problems. Therefore, this document includes both technical and conceptual
  aspects that need to be regarded for the design of a coherent security
  architecture.
  Since the upcoming threats are serious and imminent, a fast and concrete
  solution, which should be practical for everyone is needed. Therefore, the
  first part of this paper deals with short-term measures that can immediately
  be taken, using the current infrastructure and technological standards.
  But it must also be regarded that information technology in general is
  still in its infancy, and that a better approach to upcoming, yet
  unidentifiable problems and threats has to be realized with long-term
  measures aimed at programmers, vendors, corporations, and further instances
  responsible for the design of a future information security architecture.
  Therefore, the second part of this paper is about such long-term measures
  that should be taken to implement future security features and models.
  To enhance comprehensiveness of the technical issues, technical definitions
  and background explanations have been added in form of footnotes at the end
  of the paper. The reader is advised to consult these to help understanding
  the definitions and technical subjects mentioned in this paper.


  1.3       Problem description

  1.3.1     Security threats summary

  Before focusing on the problem definition, I would like to summarize the
  current actual threats to security and the causes of active security breaches,
  possibly correcting or at least questioning some popular viewpoints.
  Analyzing opinions shared by authorities and the media, one comes to the
  conclusion that malicious software (viruses/worms, trojans, intrusion
  software) and intruders which actively spread or use this software are the
  cause of all security incidents and therefore represent the major threat to
  the Internet.
  This is in my opinion a simplistic view of the problem. Imagine the Internet
  would consist of 90% vanilla WinNT 4.0 machines (a scary thought..), but no
  public exploits existed against them, and no known security weaknesses or
  incidents were reported to any authorities. According to the above viewpoint,
  there would be no 'threats', even though a single person with appropriate
  knowledge would be able to compromise or shut down the majority of the worlds
  computers by exploiting just one of the given unidentified weaknesses.
  I hope you understood my point that the threat to security should not be
  seen in the currently existing malicious software and individuals that take
  advantage of mostly known weaknesses to wreak havoc. The threat should be
  considered as the damage and incident potential caused by resources [4]
  lacking overall security architecture and applied protection. This potential
  is also multiplied by the value and possibilities a resource provides to a
  potential intruder, once its security is compromised. A compromised web
  server for example provides access to all web documents and potentially to
  gaining higher privileges on the system. A compromised mail or ftp server
  usually provides root access (read: in most cases nearly complete access to
  all of the systems capabilities, hardware, network interfaces, hard disk
  content, etc.). Observing future trends in the development of the Internet,
  we could extend our examples to a compromised gigabit ethernet / wdm routing
  device, giving the advantage of taking up a small countries bandwidth, or a
  compromised digital wiretapping device used by law enforcement, giving
  access to privately transmitted information from millions of persons.
  To conclude, the value and power of resources are a multiplying factor to
  the potential of an existing threat, which means that different kinds of
  resources need different protection, and that delegating resources to a
  task or service should be done with utmost prudence and care.
  However, the origin of security threats can only be seen in the lack of
  security given for any resource. Such threats include the potential lack
  of security, in form of uneducated administration personnel, insufficient
  scrutiny while applying security guidelines and vulnerability to known
  methods of security compromises [5].
  Not existing malicious software, or individuals with malicious intent
  represent the threats against information systems, but the vulnerability
  and threat potential that exists in the resources that are to be protected.
  This shows that responsibility for eliminating security threats lies in the
  hands of those who are responsible for designing and implementing security.


  1.3.2     Problem definition

  Taking a look at the current state of security on the Internet, and at the
  kind of incidents that we have experienced so far, it shows that all serious
  intrusions, those which involve remote compromise of confidential information,
  system access and privileges, have all been made possible due to insecure
  design and implementation of applications or operating system functions and
  the protocols they use. These problems are present in the input handling,
  access control, configuration and sometimes the amount of privileges a
  program requires in order to fulfill its task. While these weaknesses may
  seem relatively predictable, the cause of intrusions that are and will be
  frequently occurring has to be seen in a bigger scope.
  Consider that actually a high percentage of available servers are secure,
  and some of them, especially open-source products have been well-audited
  for several years. There are at least two main reasons that the relatively
  few programs whose current versions are vulnerable at the same can still be
  used by intruders to gain access to a huge number of systems:
   - Weak configuration and inexperienced users. Today's systems and software
  that look easy to install and configure are often actually the hardest to
  establish a secure configuration on, and insufficiently error tolerant
  (while intolerance to errors means in this context silently creating a major
  security hole while operating just fine), and either lacks documentation or
  comes with documentation so complex that the average user does not read
  it or take the sufficient time to get familiar with the software's functions.
  This problematic trend causes users and administrators to lack basic
  experience and understanding of their system programs, including the services
  running by default on many operating system distributions. Since those systems
  and their services can be run prior to acquiring information about them,
  people fail to recognize whether they need particular services or not. Since
  people can run all these services without spending time with the configuration
  and documentation, they fail to recognize even simple and well known
  known vulnerabilities and do not inform themselves about updates or patches.
   - Mono-cultural network structures. Another phenomenon that multiplies the
  chances for intruders and the risks is the fact that a few number of operating
  system distributions out that come with a static set of applications are
  widely spread and used, and as a side effect also spread the same known and
  the yet undiscovered vulnerabilities to a large audience; as a result, one
  known vulnerability in the today's relatively homogeneous computing
  environment can become a threat to a large number of similar systems
  with similar configurations.
  Beyond the issues regarding weak operating systems and applications, a
  further factor that contributes to the problem is the approach of the
  currently accepted solutions for conceptual software development and security
  improvement. Today's security measures, applications and protocols are often
  being standardized with only merchantability, performance and such aspects
  in mind, and therefore, no coherent systematic design approach is made that
  includes necessary minimum security standards. With current approaches to
  technology standardization, other issues like security education of end-users,
  and extendibility are also being disregarded, which makes it more difficult
  for software developers to maintain programs complying to those standards,
  and consequently more difficult to design secure software.
  Additionally, ineffective and incoherent concepts to achieving protection
  against attacks can imply a false sense of security and also represent new
  opportunities to attackers that are able to find weaknesses in those concepts.
  For example, security through obscurity empowers those who are able to crack
  and reverse engineer software. Relying on law enforcement gives an opportunity
  to those who can withdraw from law enforcement. Extensive intrusion pattern
  logging, and origin tracing can be a disadvantage to inexperienced intruders
  but an advantage to the intruders that use private exploits and have enough
  compromised machines at their disposal to obscure their origin.
  Only implementation of all basic and systematic protection measures can
  effectively withstand all current and upcoming threats.


  1.4       Basic concepts

  Before coming to applied security measures, I want to briefly describe
  some of the basic concepts that can be used to assess a solution and which
  can be applied to design a systematic approach.
  To start off, it is advisable to find the lowest layer of information
  processing to which security measures can be applied to. Excluding physical
  security and hardware design, the lowest layer of security has to be
  established at the operating system level; for the existence of access
  control [6] to any resource and system capability, it is required that this
  control can be securely enforced by the operating system on which it is
  implemented. The next layer is the secure transmission and storage of data
  in general - locally and remotely. Note that access control has to be in
  place for this layer to effectively work [7]. An effective additional
  measure to harden this security layer can be cryptography, because of its
  universal applicability. Further security layers are problem specific, in
  this case network specific. The third layer of network security is the
  stability and security of any points of access [8] to a network, single
  machine or higher privileges.
  Only by ensuring presence of such a consecutive row of security layers to
  protect against a problem, it is possible to construct a scalable solution,
  whose protection can then be improved at its weakest layer, if necessary.
  Another paradigm for establishing a long-term security solution is easy
  implementation feasibility, realized by avoiding unnecessary complexity and
  minimizing the efforts needed to individually adapt the solution. To achieve
  this, steps have to be taken to design standards which are more comprehensible
  and easier to implement, especially regarding recommended use of programming
  style and functions, and the design of security API, system security
  capabilities, protocols features and other security interfaces.





  2         Conceptual security measures


  2.1       Taking the systematic approach

  People are well advised to put their efforts into achieving one goal:
  optimizing network security to mitigate the vulnerability potential over a
  maximum period of time. The second rule to follow is to use common sense
  and apply logical concepts. An untrusted system, i.e. a system that could
  already potentially have been compromised cannot totally be 'secured'. Refrain
  from connecting a vanilla (out-of-the-box, as some people say) system to any
  network, before applying basic security guidelines. An intruder could
  theoretically be getting into it while you are in the process of securing it,
  rendering all your efforts worthless. And if we are talking about a high
  profile system or a popular attack target, this applies even more. Either a
  system has been secured from the beginning or it can never be considered to be
  fully trusted. Things that should be established from the beginning on also
  include some form of backup/recovery system, at least for unique data, and
  some kind of checksums or change logs, preferably cryptographic, which
  will later be valuable resources to compare the systems current state
  with its original state reliably.
  In order to eliminate vulnerabilities efficiently, try compiling a
  vulnerability checklist, ordered by priority. Security threats considered
  as critical to a systems survival have to be eliminated at all costs. Do not
  take easily preventable risks either (e.g. by not updating software versions
  or configuration to latest standards). A good administrator should try to
  imagine worst case situations. If someone could be interested in gaining as
  much access to your network as possible, don't be scared to imagine what could
  happen if someone would successfully run a sniffer. Measures like using
  switched ethernet are easy to apply and should be mandatory (although be
  warned that this might only raises the difficulty level; using ARP cache
  poisoning, sniffing is still feasible), and critical devices such as
  switches, routers, gateways and other packet forwarding devices, as well as
  log hosts and other hosts that serve the function to preserve your network / 
  data integrity should not be accessed remotely at all; ideally they have no
  open ports at all and must be accessed via console. A few weeks earlier I
  would've suggested running ssh as only service, but since a working exploit
  against a current version of ssh is out... well, by assuming the worst case
  in all situations applicable to your network, you cannot be wrong.


  2.2       Designing a security model

  Just like a single host that has to be protected prior to using it in a
  network environment, internal structural design of your network(s) has
  to be completed before exposing them to the Internet.
  Taking a look at the latest threats, and upcoming possibilities of intruders,
  I would strongly advise a decentralized task security model. This means to
  avoid single, big resources that share many points of access. On one hand,
  hosts that run a concentrated amount of services can be easier compromised
  because an intruder can select from a variety of services which to exploit,
  and on the other hand, by having a single, big machine compromised or
  penetrated with Denial Of Service [9] attacks over a long time, you would
  lose a lot of services at a time, which possibly many users or critical
  network processes depend on.
  Consider using a higher bandwidth on your local network than you have overall
  bandwidth to your uplink(s), so you still would have the possibility of
  internal process and user communication when your network gets hit by DoS
  from the outside.
  Try to retain the systematic aspect of design. Reliable audit trails are good,
  preventive measures against intrusions are much better. Do not rely on an
  extra mechanism if you know that your networks security would be lost without
  it. Once you have established basic security, extra packet filtering and
  intrusion detection rules can act as additional security layers if deemed
  necessary. Another subject worth mentioning is a mistake which I have
  observed is being frequently made. Yes, a DMZ is supposed to be exposed to the
  Internet more than the other sensitive parts of your network are. But that
  does not mean there is any reason in exposing hosts on the DMZ, preferably
  mail servers, bastion hosts, and gateways running a bulky mass of services,
  to preventable risks! This is something just too many people do, without
  considering that the DMZ hosts are very vital parts of your overall network
  security. I would bet that more than a half of all incidents have happened on
  those hosts, which have been poorly secured or not secured at all, while their
  protection is as important as protection of any other network components.


  2.3       Problems in a corporate environment

  A popular, generally accepted security solution for corporations is to
  establish a security policy, and then assign a team that is specially
  responsible for protecting the corporate resources and enforcing that
  policy. The problem is that a few people in control of security measures
  cannot guarantee this protection, while the rest of the employees possibly
  lack sufficient understanding of their software to care enough about security.
  The same way in which it is possible to demonstrate lack of security, but
  not its guaranteed existence, a security policy can be enforced with all
  technical measures, but cannot fully guarantee that employees lacking
  awareness find a way to circumvent it (or that the policy is not sufficient
  and people never find out about it). A better approach to corporate security
  is to define a minimum of security and of technical education for everyone,
  and educate everyone in an adaptive manner, suiting the individually present
  state of knowledge. Instead of possessing either expensive or insufficient
  security, corporate security needs to be designed to be comprehensible for
  everyone, and education that goes beyond basic mandatory guidelines should be
  acquired individually by self-education; that way, corporate security can be
  achieved by everyone without dedicating it huge amounts of money or time.
  Taking this approach, however, makes it necessary to observe how well it is
  individually adapted, rewarding knowledgeable employees with respect, and
  helping those who face problems gaining the sufficient knowledge, possibly by
  assigning them to teams with more knowledgeable individuals.


  2.4       Preparing against an incident

  To be prepared against incidents like intrusions, intrusion attempts, and DoS
  coming from outside your local network, it is important to be able to
  correctly interpret the meaning of probes [10] and other unusual traffic to
  your network, and of course to have sufficient audit trails present that can
  be evaluated. Some essential precautions that should be taken are to enable
  network egress and ingress filtering [11], and setting up secure, impenetrable
  logging facilities, in form of a more or less isolated loghost [12].
  By being able to recognize the kind of threat, you prevent unnecessary panic
  when you are facing futile intrusion attempts, and on the other side can
  take appropriate measures quickly, when your systems are really at risk.
  Preparation should generally start at network design, in form of separating
  important tasks of the network by delegating them to different machines with
  the aim to minimize the damage that can be caused by an incident.
  While in my humble opinion there are not many similarities between computer
  crime and conventional crime, one thing they have in common is that they can
  hardly be stopped by harder prosecution and better tracking. If an intruder
  wants to gain access to your network, and there is any possibility, he will.
  Like conventional crime, the better approach to mitigating the possibility
  that incidents occur is to make an intrusion into your network appear less
  inviting by hiding as much information about your network as possible.
  Approaches to this include using meaningless hostnames for different
  internal hosts that serve different purposes, denying external DNS zone
  transfer, configuring your servers to show bogus version information, or even
  slightly modifying your kernel to defeat remote OS identification [13]. While
  this tactic does not represent a factual security improvement, you will stop
  presenting a possible intruder information about where to find your internal
  DNS server, SQL databases, and other weak points on a golden plate. Note
  that the best method in making your host an uninviting target is of course
  to apply all possible security measures at your disposal. A final important
  preparation is to have some way of recovery, in form of incremental backups,
  site mirroring, or anything else you deem appropriate, and to possess
  necessary information to reestablish integrity of your critical data, in
  form of cryptographic checksums and/or system images of a trusted state of
  your systems, which have to be stored in a way that it is not possible for
  an intruder to remotely manipulate them.


  2.5       Incident response

  2.5.1     Reacting to an incident

  If your router experiences large amounts of spoofed traffic, it is recommended
  to ask your uplink or backbone provider for assistance. In all other cases
  that represent a real threat to your network, you are well advised to directly
  contact the responsible technical or administrative authority of the attackers
  origin(s). While the current international chain of network information
  centers is undergoing structural changes, there are still reliable ways
  to find the proper authority to contact. A WHOIS hostname query to
  whois.internic.net will, in most cases, reveal the proper NIC to contact. [14]
  If this is not the case, you should try contacting whois.ripe.net for
  European IP addresses, whois.apnic.net for Asia, and whois.arin.net, which
  will always deliver you information about the owners of assigned IP blocks.
  If the contact persons you found do not reply to email and phone in a short
  period of time, look up their uplink provider by querying whois.arin.net,
  doing traceroutes, or by gathering information about the hosts that provide
  top-level DNS services to them, generally shown in the WHOIS query. Another
  possibility is to make use of the Network Abuse Clearinghouse, by sending
  email to <offending-domain.dom>@abuse.net, which will efficiently try to
  contact the responsible administration, especially if you are experiencing
  unauthorized use of your mail servers.
  If you are experiencing ongoing intrusions which are massively putting
  machines on your network at risk (e.g. you are experiencing repeated buffer
  overflow attempts that indicate the attacker only needs to find the correct
  offset, you are not certain if low-privilege access has already been gained,
  your webserver is being intensively probed and you are not convinced that it
  is totally secure, or a front-door brute force password cracking attack is
  going on), emergency actions should be filtering the attackers subnet at the
  border routers, and if the attacker is persistent, temporarily null-routing
  or even shutting down attack victims and other weak hosts on the network.

  2.5.2     Post mortem: Incident recovery

  Once your security has been partially or completely compromised, you have
  two proposed solutions to recovery, with the goal of restoring the system
  back to a trusted state. The first, and most reliable solution is to do a full
  backup from the last trusted system state [15], or, if backup data is not
  present, to completely delete and reinstall the system, only retaining
  databases, documents and other non-executable data from the compromised
  system. The second approach means to examine your system to find the
  path an intruder has taken in compromising, backdooring and using your system.
  You should have some kind of checksum data present in this case, to find
  changed binaries. Checksums and checking utilities have to be kept on a
  device that cannot be manipulated, such as a removable disk. If you assume
  the worst case, your system kernel or libraries could be changed in order
  to hide checksum errors. You can, however, keep checksums on each machine,
  if you encrypt or digitally sign them with a key that is not stored in any
  form on the machine, e.g. with PGP or any other strong encryption tool. [16]
  Performing initial integrity verification of the checksums from a trusted,
  non-compromised system (or by booting from removable media), is mandatory.
  After that you are able to isolate and examine changed files. Popular
  backdoors that you should scan for in the first place to reveal starting
  points of a compromise include system configuration such as inetd.conf,
  SysV init scripts, access control lists, password files, shell profile files,
  rhosts files, crontabs, server and other critical system binaries, as well
  as hidden filenames (find / -type f -name "*[ ]*" -o -name "*.*.*") and
  files in unusual places (find /dev -type f). Further methods that can help
  you analyze what steps and intruder has taken are all instances of logging
  facilities, which should be closely analyzed from the first possible event
  of intrusion. After restoring a system back to a trusted state, the
  vulnerability that has been used to gain access has to be identified and fixed
  at all costs, together with all obviously existing weak points in the security
  design that have lead to the vulnerability not being discovered and patched
  before. Keep in mind that a vulnerability can be everything from an
  exploitable server to insecure access permissions or weak passwords.





  3         Technical security measures


  3.1       Strong resource protection

  In retrospect, attacks against information systems, be it embedded technology,
  telephone networks or computer networks have been commenced for a long time on
  a tame, mostly experimental and educational basis. Of course, malicious intent
  has always been present, but because of computing still being in a relatively
  early phase, the challenge to break security has not yet been high enough to
  make military-level intrusion skills for an intruder necessary to be able to
  compromise enough resources to satisfy his or her needs. With the necessity
  of protection becoming popular, and countermeasures against intrusions
  advancing, we are about to experience equal advancements in intrusion
  technology as an adequate answer of the intruders who want to be able to
  compromise resources, be it for gaining knowledge, financial profit, 
  or because of social, military or terrorist ambitions.
  To keep up with this trend, the strongest protective measures currently
  available should be applied by everyone to defend their resources, because
  on the Internet, all resources are theoretically being targeted equally. The
  following section will make an attempt to establish a universal guide to
  defining and applying existent security measures to your network environment,
  by identifying defense methods for separate points of access and bringing
  them together as a scalable technical solution. To retain the independent
  applicability of this solution, I will evade recommending operating system
  specific solutions or products; additionally, a paper describing such a
  specific solution would require constant improvement and updates when
  specific vulnerabilities would be discovered or functionality of specific
  software would be improved.

  3.1.1     Defending your system integrity

  Possessing system integrity means having functional access control, a trusted
  and secure environment and control over any modifications made to the data
  belonging to you. Points of access that can be used for attacks against
  system integrity include all processes involving evaluation of data -
  sessions, informational and executable content - performed by the kernel,
  servers, applications and scripts.

  3.1.1.1   Setting up a secure environment

  In the beginning, the operating system has to be in the most secure condition
  that is possible. If your system allows it, recompile your kernel, applying
  all patches relevant to security and stability, and disable capabilities that
  you will not need. Enabling firewalling, resource limits and using restrictive
  network features (regarding spoof- and flood protection as well as routing
  and packet forwarding) are especially recommended.
  If you have a personal choice of what operating system, distribution and
  release version to prefer, there are some important recommendations you should
  consider. Naturally, use of systems that have proven to contain very little
  vulnerabilities over a long time and are open-source should be preferred [17].
  Systems offering a minimum of pre-configured settings and programs, which have
  to be customized manually often offer a maximum of stability and security to
  the knowledgeable user (see problem definition, 1.3.2), for example systems
  belonging to the BSD family, but also other Unix systems or Linux, if
  installed with a minimum of pre-configuration and pre-installed applications.
  Another important security criteria when selecting an operating system (or
  any other software, for that matter) is not to use very recently published
  software for production, because most present vulnerabilities of a
  distribution or other software product are still being found after
  its release. Therefore, it is recommended using older operating system
  versions with all released vendor patches and updates for production. [18]
  Before going any further, it is important to consider that protecting a
  multi-user system is much harder than a single user system. If you are
  establishing protection on a dedicated mail/web/ftp/etc. server, disabling
  nearly all accounts, including anonymous mail and ftp access, and setting up
  restrictive access control (see 3.1.1.2) makes the task easier.
  On multi-user systems, your tasks must include proper local resource and
  access restriction (using quota, securelevels, permission checking scripts,
  systems security- and limit configuration files), and mitigating the chances
  for a local security compromise by disabling suid permissions where not
  explicitly necessary and updating remaining critical suid applications.
  To establish a secure environment, one more thing to do is to ensure that
  no modification to the files that you expect to be trusted, by using simple
  Perl or other scripts (I like Tcl a lot) that ensure file integrity. This
  should include checking of size, access and modification time, detecting
  recently created files in paths reserved for privileged accounts, and
  cryptographic checksum comparison. This is basically the job of host-based
  intrusion detection, whose purpose is to detect irregularities that can be
  signs of security compromises. To really ensure data integrity, cryptographic
  checksum comparison has to be commenced from a completely trusted environment,
  such as a write protected removable media from which is booted and which
  contains all files necessary to validate checksum information. To be able
  to actually trace back and recover from occurred unattended modifications,
  there is no other way than having data recovery mechanisms present (be
  it in form of high-level RAID, full backups, or regular site mirroring).
  
  3.1.1.2   Establishing access controls

  Before thinking about any kind of (password-) authentication, basic measures
  should be established that narrow down the amount and range of clients that
  can connect to your hosts or specific services. Access to services that are
  being used only internally, e.g. POP, portmap, or SNMP, should be blocked
  at your border router - specific configuration depends on how you are using
  your network, however, for most small web sites there is not much that speaks
  against only permitting incoming http traffic. Secondly, restrictive local
  access control should be established. If you can, permit only sessions from
  explicitly trusted hosts. For services run via inetd/tcpd and portmap, the
  access permissions are set in hosts.allow (while denying all default traffic
  in hosts.deny, if using restrictive controls), for other services there are
  separate access configuration files that need to be modified. The advantage
  of blocking lies also in the fact, that denied connections can be logged and
  help indicate possible security violation attempts. If really fail-safe
  audit trails are desired, nothing beats running tcplogd, udplogd and icmplogd
  running together with a syslog daemon that forwards all traffic to a loghost.
  A dominating rule for access control of any kind should be to enforce the
  predetermined security requirements by the system, not relying on users to
  uphold system security.
  The same rule applies to all kinds of password-based authentication. While
  buffer overflow and other exploits have been gained popularity to overcome
  system protection, during times where less vulnerabilities are being exposed,
  attacks against the weak password authentication scheme should never be
  underestimated. [19] Therefore it is mandatory for the authentication system
  to enforce the use of strong passwords by everyone, especially root, and
  password aging - to prevent compromise due to sniffing or successful attacks
  against individual users. [20]

  3.1.1.3   Application security

  The core of the currently present security problems certainly revolves around
  deficits in the countless and complex server and client applications, which
  often possess security relevant bugs. While there is no definite solution and
  no final proof for the security of an application, evolving incident response
  capabilities and full-disclosure security are helping to discover information
  about serious issues earlier, a situation of which you should take advantage
  by frequenting security- and your vendors sites to periodically gain
  knowledge about latest serious vulnerabilities, install patches, and if your
  system has been exposed for a long time by containing a serious bug,
  performing integrity verification and intrusion checking measures.
  Regarding the technical aspect, understanding a program means being able
  to detect security issues, and browsing its source code for known security
  leaks [21] is recommended, if the application is in beta development stage,
  or a security critical application used on many of your networks machines.
  World Wide Web related traffic is a specifically fragile topic, because it is
  often used for gaining access to system whose overall protection is relatively
  strong. By being able to chose exploits from a huge collection of existing
  vulnerabilities in HTTP servers, Server Side Includes, and CGI scripts an
  intruder has many possible starting points for compromising security. It is
  important to consider every CGI script and similar facilities belonging to the
  web server as a single server application, because they are executables that
  are evaluating remote content on the web servers machine. Be very careful
  while configuring the HTTP servers runtime permissions and minimize the amount
  of CGI scripts, for example by using Java or similar content to enhance a web
  sites appearance at the clients end, just like you should minimize the number
  of other servers that you run off your site.
  Upcoming reactive solutions to provide application security are represented
  by applications that try to harden the operating systems protection against
  common security vulnerabilities, by restricting processes' access to resources
  (like special files, memory page segments and kernel capabilities) and issuing
  alerts when access to such resources is attempted. Examples include StackGuard
  and Unix kernel patches to protect stack segments and internal registers, and
  stack shield, a compiler wrapper that produces binaries with self protection
  against boundary overflow attacks by wrapping the compilation at assembly
  level. Obviously, these are only temporary solutions against a specific
  (but widespread) problem category, but show that the problem has to be solved
  by improving security measures at operating system level. Nevertheless, it
  is strongly recommend to make use of these solutions for now and make use of
  intensive auditing to compensate the existent weaknesses.

  3.1.1.4   Auditing - reactive and proactive measures

  To provide coherent security, the process of auditing has to be applied
  frequently, to improve not only the security of applications, but of all
  substantial and abstract parts information systems consist of.
  Reactive auditing means a constant verification that preventive and protective
  measures are sufficient by improving configuration and design of systems,
  software and network design. An important part of this task is to routinely
  identify and evaluate occurring events on a system, to be able to discover
  vulnerabilities as they are exploited or created. Therefore, auditing should
  start at kernel level, in form of detailed verification and ability to
  record all of the systems actions, independent from logs generated by
  applications themselves, because they can never fully be trusted, as shown.
  Platform specific experimental approaches exist in form of the system events
  logger ssyslogd, or the kernel-level execution logging lkm exec.c, but current
  kernel based event logging are not yet standardized, or implemented into 
  operating systems, so that secure kernel-level auditing is problematic. It is
  generally advisable to make use of auditing and intrusion detection tools that
  work on a remote, networked basis, to enhance reliability and availability of
  audit trails in critical events. If you want resource protection at the
  strongest level possible, a currently possible solution you should consider is
  auditing using remote real-time auditing agents (IDS, data verification-
  or event monitoring applications capable of transmitting traffic to a central
  evaluating machine) and half- or fully automated real-time traffic and
  signature processing to be able to react to all events threatening system
  integrity immediately. If such agents are used, and it is technically possible
  to disable remote management facilities, it should be done, to provide a safe
  one-way reporting channel without opening a possible point of access. [22]
  Besides all these sophisticated measures, you should never forget to implement
  the proactive aspect of auditing, which means to systematically scan your
  system remotely (and locally if necessary) for exploitable vulnerabilities.
  Proactive auditing is so advisable because it means to examine your systems
  from the 'black-hat' viewpoint of an intruder, meaning with the goal in mind
  to be able to gain unauthorized access to it. You might always have forgotten
  some updates or configuration changes, leaving a critical hole open, and
  therefore combined reactive and proactive auditing is necessary to mitigate
  the possibilities for an intrusion. See also [23].

  3.1.2     Defending your data confidentiality

  Ensuring confidentiality of your data means to effectively protect
  sensitive and private information of any kind, stored on and transmitted
  over systems that are connected to the Internet, from being accessed by
  any external party. Pre-requirement is to possess an environment with intact
  integrity of data and functional access control mechanisms, to prevent leaking
  out of confidential information from a supposedly trusted storage source.
  For accomplishing this task, cryptographic measures are essential. Wherever
  possible on a network, services using plaintext authentication and sessions
  should be completely disabled and replaced with equal services supporting
  encryption, like ssh for telnet and r-commands, sftp for ftp, SSL instead of
  base64 encoded plaintext basic authentication for web servers, and kerberos
  authentication instead of plaintext authentication for services like POP,
  IMAP, and nntp. While plaintext services seem to be a bigger threat to
  privacy than to effective system security, they aren't. A huge number of
  intrusions commenced by knowledgeable intruders are performed by gaining
  access to a huge number of machines all around the world, installing stealthy
  packet sniffing programs with the purpose to gain as many login / password
  information as possible, hoping to gain access to high-profile systems which
  are then invaded and compromised by attacking local system security.
  Additionally, a compromise of authorization methods can be used to gain access
  to trusted resources. Basic authorization is realized at protocol level, and
  therefore protection against attacks that involve spoofing has to be present.
  While vanilla IP spoofing is itself no confidentiality issue and cannot be
  prevented, security of TCP sessions should be improved by assuring that all
  trusted systems use unpredictable TCP sequence numbers, to prevent tcp
  hijacking. Another vulnerability lies in the ARP (ethernet address resolution
  protocol). Dynamic ARP cache entries can be manipulated using forged ARP
  traffic; use of static ARP cache entries, especially on routers and switches
  is recommended, to prevent malicious packet redirection to arbitrary hosts.
  Once the security on a system is compromised, session hijacking and sniffing
  from a client process' memory is quite feasible, for example by using process
  tracing. While the use of programs like SSH is strongly recommended, another
  important factor is keeping contact to system administration of other remote
  trusted systems, making sure that their system security is not the weakest
  link in your chain of resource protection.
  Further methods of providing confidential transmission of data include using
  IPSEC tunneling and IPv6 protocol capabilities, and similar protocol based
  solutions, as well as Virtual Private Networking, all of which are generally
  advantageous to use, but cannot be fully recommended yet to be used by
  everyone because of today's lacking standardizations, public key infrastructure
  and wide-range implementation in operating systems and applications.
  To assure local data confidentiality, which can, in addition to assuring
  privacy and anonymity, play an important role to prevent user-level attacks
  against data and privileges of other user or administrator accounts, I
  would advise reading [24].

  3.1.3     Defending your network availability

  Assuring availability on your network means to protect your communicational
  in form of a guaranteed minimum bandwidth and impenetrable functionality of
  processes which use remote data transmission. To define requirements for
  a defense is a delicate task, because for an attacker, the potential of Denial
  Of Service [9] attacks often depends on gaining access to any host(s), which
  do not have to be associated with your network at all [25]. In the beginning,
  possibilities for attacks which an attacker could perform with minimal efforts
  have to be eliminated. As mentioned in 3.1.1.1, your systems should be
  prepared against application- and kernel-level (including IP protocol stack)
  attacks, by having applied specific vulnerability and flood protection
  patches, for example in form of a robust syn cookie implementation [26].
  To prepare against Denial Of Service, distributing tasks over different
  hosts is an invaluable method of minimizing impact of (wanted or unwanted)
  traffic irregularities and problems, because the number of unavailable
  services during such periods are minimal, and an attacker would have to
  concentrate on many targets. If administrating a larger network, separating
  network segments via routing, packet filtering capable device can make
  sense, to generate zones of different availability, which will help you to
  set different priorities on a network, along with using more than one uplink
  channel at different spots of your network, raising the chance of being able
  to have emergency or spare bandwidth to the rest of the world in case of
  ongoing massive flooding attacks.
  The next important thing to do is to secure your routing infrastructure, by
  preventing intrusions made by spoofed or unauthorized routing protocols coming
  from an attacker. It is generally advisable to only accept ICMP, TCP and
  UDP traffic to prevent arp, rip and other fragile protocols to penetrate
  your internal hosts and routers. This also applies to closing down
  tcp/udp ports used for routing at your network border, if using for example
  routed (udp) or routers running border gateway protocol (tcp). If you rely
  on a firewall/gateway solution for blocking outside access, it is advisable
  not to allow outgoing ICMP/11 (time exceeded) messages, which can be used to
  map your protected network, even if most tcp/udp ports are being blocked [27].

  3.1.3.1   Guidelines to defensive routing

  From a strong security perspective, routing should have the ability to prevent
  traffic that could be malicious or unwanted from entering or leaving a network
  and perform this task with a minimum of extra routing features and access
  rules, which could degrade the routing performance during high bandwidth
  traffic, possibly caused by attacks, and represent potential weaknesses, as
  increased complexity always does in a network environment.
  Routing and packet forwarding/switching should never be allowed on firewalling
  and gatewaying machines that process packets themselves, because it could be
  exploited to bypass gateway and firewall rules, penetrating internal hosts.
  One of the most important things (which everyone should know about anyway) is
  to disable outgoing directed broadcast traffic that can give an attacker the
  opportunity to use your networks broadcast replies to generate icmp and udp
  broadcasts storms directed against another victim (smurf / fraggle attacks).
  Using SNMP capabilities of routers can be advantageous to detect and respond
  to irregularities or possible intrusions, but should be done with care, as
  securely configuring this facility is absolutely critical [28]. If you are
  inexperienced with SNMP and don't already have a concrete concept of using it
  to gather statistical network information, you are well advised to disable it.
  Further extra routing capabilities (like Cisco's CDP, debug mode, link state
  routing) should not be activated, especially not on border routers, unless
  particularly necessary, with the exception of tcp intercept features [29].
  If bandwidth and availability is critical for your network, or if your uplink
  charges you depending on the amount of traffic sent, it is advisable to
  establish especially restrictive access rules at network borders by blocking
  most in- and outgoing ICMP datagram types if unnecessary for your internal
  network tasks (especially unreachables, which can help to multiply effects of
  DoS attacks and udp probes), and to deny access to privileged ports on which
  internal services are run or which are not needed to be accessed by external
  hosts at all [30]. Additionally, you should evaluate your router logs and
  examine status information on your routers periodically, to detect networking
  problems, and eventually change to restrictive or emergency access lists you
  have previously compiled, for the case that network critical events occur.

  3.1.3.2   Tracing: capabilities and problems

  Origin tracing is a measure essential to network protection and incident
  response. In the context of packet switching based networks, it means to
  reliably determine the origin of incoming packets, including packets with
  forged IP source addresses. Determining the origin of incoming forged
  packets is necessary to contact the proper administrative authorities
  for the network(s) or host(s) from which an attack - mostly packet flooding
  DoS attacks - is coming in order to stop the attacks by either fixing security
  leaks on systems which the attacker is using or by getting attacking systems
  taken off the network.
  One method of generating audit trails on your routers, that help in improving
  tracing capabilities, is to establish ACL rules that permit, but log traffic
  that matches patterns which are commonly found in DoS attack traffic [31].
  However, by instructing your routers to generate extensive logs, possibly
  using extensive ACL rules, you are risking to cripple your routing performance
  and actually decrease your capacities.
  To sites for which it is critical to be able to establish tracing
  capabilities, be it for network observation or incident response ability,
  I would recommend to do the following: at your network border, set up routers
  that do plain IP based routing with a minimum of enabled access rules and
  features. The border routers should then, additionally to routing traffic,
  forward all traffic to a separate router, which null-routes all incoming
  packets and is only used for forensic purposes. This 'forensic' router then
  has all facilities and features enabled that help evaluating the traffic and
  creating valuable audit trails. This router can be slowed down, because it
  is not dedicated to routing, but only to evaluating and auditing traffic.
  Note that this is of course only a solution recommended for big companies
  and backbone providers who can afford running such an infrastructure.
  Additionally, your routers should make use of NTP (network time protocol),
  because tracing relies on a time-based correlation of log events, and slight
  time differences can already complicate log evaluation (for example, if you
  have to evaluate a huge amount of packets, each with a different forged
  source IP address, that have been transmitted in a short amount of time).
  The above measures are meant to help tracing packets using hop-by-hop
  tracing, which means to trace packet streams by evaluating the routing
  entries of each router between source and destination host. A packet with a
  forged IP address is followed back by determining from which port it entered,
  and then continuing the trace on the router associated with that port, until
  reaching the origin. This is hard to do because it requires all involved
  uplinks to coordinate in performing the trace over their backbone, and it has
  to be performed quickly, because the routing entries are automatically cleared
  shortly after a finished or failed host-to-host connection.
  See Figure 1 [32] for a scenario of tracing back a distributed attack.
  Another way of associating incoming packets having forged source IP addresses
  is to identify them by MAC (media access control layer, usually ethernet)
  addresses, which are generally not spoofed. Using IP debugging features on a
  router, one can determine the MAC addresses of incoming packets, and save
  them for reference and later backtracing or compile access control lists on
  all border routers that deny and log packets with the concerning MAC
  addresses, if technically supported.


  3.2       Problem specific protection

  Despite all efforts to improve overall security by properly protecting and
  maintaining a site's resources, risks to become a victim of new or unresolved
  vulnerabilities or general weaknesses present in the network architecture
  may be mitigated, but not eliminated. Yet undiscovered and non-public
  vulnerabilities might exist in popular server software, that are not being
  detected despite of performed source code auditing. A fundamental security
  flaw could be present in your core operating system or protocol stack,
  temporarily rendering all security efforts useless. You might become a
  target of attacks which exploit fundamental weaknesses of the current
  Internet architecture, including DNS and PKI hierarchic structures [33],
  protocol weaknesses, and resources of other, insecure systems turned against
  you [34]. Therefore, it is required to adopt strategies to prevent and
  recognize ongoing events endangering system security and emergency methods
  to stop such events.

  3.2.1     Protecting against viruses

  Since the aim of this paper is to help protecting your network against new
  kinds of attacks, what is my point of coming up with viruses? Actually, virus
  related problems and problems caused by system insecurity and intrusions have
  some points in common, especially regarding their evolution and effective
  countermeasures against them. A virus is a pattern that self-replicates and
  tends to be spread to other systems from infected ones, be it by exploiting
  weaknesses of the system, or weaknesses of the systems communication
  infrastructure (i.e. using human interaction or popular distribution channels
  in a network to spread). So, viruses take advantage of the infected systems
  to penetrate further systems from there, meaning that they actually belong
  in the category of distributed attack tools (though they are not human-
  controlled and thus target random victims).
  The interesting thing about virus and worm code is that there are few
  limitations regarding its possible appearance. It can exist in virtually
  infinite new forms, and use an infinite amount of new methods to propagate
  and operate, making detection a hard task [35]. The current anti-virus
  solution is to maintain pattern databases of today's known viruses and scan
  for their occurrence. However, pattern scanning is obviously a futile method
  against viruses, since an infinite number of new viruses with new patterns
  can be created. This is also the reason of virus outbreaks despite widely used
  and updated Anti-Virus software, as caused by the Melissa worm, CIH,
  BubbleBoy, etc. After the outbreak of such threats, they can be recognized,
  but this is an insufficient security strategy which people should not rely on.
  If I wanted to spread a virus, I wouldn't have to write an entirely new one.
  Implementing unknown or modified self-encrypting algorithms into a virus and
  deploying the encrypted version would suffice, as not a single scanner can
  actually detect or reverse engineer encrypted viruses.
  (Fine, they can scan for the self-decryption code once they've seen it and
   updated databases, but that won't help a scanner discovering it initially).
  A somewhat better solution is heuristic program analysis, which detects
  what kind of functions and resources a program is designed to use, determining
  virus-like character. Again, those scanners don't detect encrypted viruses.
  As I mentioned in section 1.3.2, solutions like present anti-virus scanners
  give people a false sense of security. Once they run updated scanners, they
  often assume to be 100% safe, and happily access untrusted binary executable
  content. Instead, the solution needs to be based upon restrictive guidelines.
  Applications (and all content that will be evaluated and executed by
  interpreters or as machine code) need to be either coming from a trusted
  source, compiled locally from source code that can openly and freely be
  reviewed before compiling and running it, code running with a drastically
  reduced set of permissions and system access, or else they must not be
  executed at all costs. Since this is especially hard to realize with current
  desktop operating systems and software models, new software standards and
  operating system requirements have to be formulated to effectively cover
  security deficits in present software technology, as proposed in section 4.2.

  3.2.2     Using Intrusion detection systems

  Host- and network based intrusion detection can be described as a set of
  methods for discovering attack signatures in network traffic and system data.
  The above introduction to viruses and problems that are encountered in the
  development of countermeasures helps to show the parallels that exist with
  the IDS approach of auditing countermeasures against intrusions. Much like
  virus technology, intrusion methods are actively being developed as long as
  new software is written, which can never be totally free of security
  relevant vulnerabilities. This is one way an IDS can be bypassed by an
  intruder, by exploiting an unidentified vulnerability for which intrusion
  attempts are not known and therefore not being monitored. But intruders also
  have a large disposal of methods available to commence well-known attacks in
  new forms that are not being detected by IDS. This is a very similar problem
  to the anti-virus detection problems with encryption and other machine
  language level tricks to perform identical virus tasks with new patterns,
  fooling pattern detecting scanners. When anti-virus software became popular,
  this game (or war, if you prefer) of evasion and detection started between
  virus programmers and anti-virus companies. Now that IDS are increasingly
  gaining popularity, it seems that similar evasion techniques are being
  actively developed to bypass them as well. It is obvious that there are
  fundamental weaknesses in today's approaches to intrusion detection.
  See [36] for some brief explanations on existing IDS evasion tactics.
  Something else to consider is, that people who configure, run and periodically
  maintain recent IDS are probably sufficiently enough aware of security to
  be sure to use updated and secure software (well, at least they should!)
  and will not be affected by most of the known vulnerability exploit attempts
  an IDS registers and reports. If being on the Internet, it is unavoidable
  to be scanned for vulnerabilities now or then, and therefore, false positives
  will accumulate, which alarm an administrator but pose no real threat. The
  problem here is, that if someone repeatedly hits your front door without the
  possibility of him getting inside, chances are that you will get weary of it,
  and, in case of a real break-in, be less alerted than you should. Sites that
  are most vulnerable to known security vulnerabilities often have insufficient
  time, knowledge, money or other resources available to be able to recognize
  and find these vulnerabilities. Unfortunately, such sites will probably not
  have IDS software installed, or even know about its existence.
  This shows that a coherent preventive solution may include usage of intrusion
  detection, but not as a single and ultimate auditing measure.
  Once suspicious audit trails are generated, by intrusion detection or other
  facilities, correct assessment of the event and appropriate actions will play
  the key role. To help in assessing such events, many independent facilities
  that each provide protection and audit information separately are of
  advantage. If you use IDS, I strongly recommend flexible, configurable
  software, because you can then perform a system auditing and disable
  configuration entries that cause false positive alarms [37]. In a perfect
  system, an administrator would have the ability to monitor all system events
  down to function calls and all user activity rigorously, but could chose to
  log only certain events at system and application level that can have a
  critical impact on security. Weak points of today's security technology
  include the lacking of continuous, permanent and fail-safe protection of a
  system at low level whose security and performance cannot be penetrated
  itself, and the enforcing of a restricted system environment that grants even
  the most privileged processes no complete control over the systems resources.
  These are obviously deficits which require new technological and systematic
  long term approaches and cannot be fully resolved using currently available
  standards and production software.

  3.2.3     Backdoors and trojan horses

  There will always be possible scenarios in which your system can be fully
  compromised, be it by a new, unidentified vulnerability, or by a vulnerability
  that has been overlooked or exploited before security measures and updates
  were applied. Therefore, awareness of existing methods of intrusion software
  - which can be designed to help an intruder keep full access to a system,
  including self-hiding, audit trail suppression, manipulation of any data that
  can assist in discovering compromises and assuring anonymity to the intruder -
  has to be created, before effective and (hopefully) reliable countermeasures
  against a compromise can be taken. By asking yourself what an intruder
  could possibly do after a full root compromise, one realizes that regarding
  the security impact, there is not much difference to physical access, at least
  if today's broadly used operating system software is used. Don't think that
  trying to discover known types of backdoors helps you to reliably recover
  from an incident (see 2.4), but it is necessary to actually find out that your
  system has in fact been compromised.
  Scheduling scripts using cron(8) or at(1) which scan for access and change
  time stamps can sometimes help to find traces of unauthorized access [38].
  A backdoor is any executable code that is used to grant an intruder access
  to a system without having to go through authentication, and possibly evades
  creation of audit trails. It can exist in form of executable programs, kernel
  code, or subtle configuration changes that help to bypass authentication.
  Popular ways of launching backdoors are running them on system start via
  altered SysV init scripts, preference files, or the inetd.conf file, which
  decides what programs to start on connection requests to a service port.
  Trojans are programs that serve a legit purpose, while performing unauthorized
  tasks such as letting an intruder gain access on special conditions which the
  intruder can generate. These kinds of trojans are mostly hidden in recompiled
  network daemons, and can sometimes be found by searching for phrases in the
  binary that seem to be passwords or encrypted strings (this will only work
  if a backdoor password is stored in a character string buffer, else the
  executable would need to be debugged, traced or reverse engineered). System
  access backdoors which are not created using trojaned executables or
  configuration normally run as own processes which offer some kind of remote
  access to an attacker (excluding privileges elevating backdoors on multi-
  user systems, which are mostly hidden in suid/sgid binaries). Therefore, a
  way of detecting a compromise can be analysis of the netstat(8) output, or
  using lsof(8) to determine which program utilizes certain ports and other
  resources. Traffic to destination ports that are not associated with known
  services running on the target machine, which can be found by using the
  above mentioned tools, or analyzing SNMP and router logs statistics can
  be a sign of intrusions. However, if a host is compromised, an intruder
  could have taken care to manipulate analyzing programs and audit trails so
  that his traffic is not visible from the host. It is also possible that
  intruders set up 'booby trap' programs, trojans of system utilities that
  are frequently used by administrators (ps, du, ls, who, etc.) which primarily
  hide output that would be compromising for the intruder, but can also be
  manipulated to do unwanted things when being called with administrator
  privileges (alarm the intruder, change files, open a backdoor, etc.).
  As a general preventive measure for detecting trojans, it is recommended to
  watch network traffic and system events from the beginning on, determining
  statistically averages of normal network usage. After such an average profile
  of network events is generated, one could perform penetrations in form of
  Denial Of Service and exploit attempts and watch for significant changes
  in the networks traffic flow. When real intrusions or intrusion attempts
  occur that are not specially being monitored for, a prepared administrator
  will have better chances of recognizing them by comparing statistical
  irregularities. This method might be gaining importance as stealthier
  methods to commence intrusions and to establish backdoor access become
  popular [39]. Using the present security level features of operating
  systems can also be recommended, to prevent interfering with specially
  protected files, devices or performing other privileged tasks as root
  that should not be possible to do without physical access. Secure levels
  can restrict the privileges of the root account so that it is not possible
  to do everything possible for the kernel with highest user privileges.
  However, mind that by rebooting to a different environment, this is still
  possible, because administrators having console access must be able to
  use these privileges (for example, to add or remove files and reconfigure
  the system). If you rely on security levels, it is mandatory to prevent
  your system from loading the operating system after being rebooted without
  user interaction at the console. You are strongly encouraged to set BIOS
  and other boot-time loader passwords; else, after a compromise, an intruder
  could remotely reboot the system into a insecure level, or with a
  kernel compiled by himself, instructing it to go back online after rebooting
  and granting the intruder remote, complete system access.


  3.3       Conclusions about present security technology

  As it seems, the security features of present software and networking
  structures are sufficient for achieving a secure environment, if some
  effort is put into the process of systematically securing, protecting
  and auditing systems. However, the present security features cannot
  guarantee that a system is safe from intrusions and other security relevant
  attacks with complete reliability. Not to mention the problems that many
  people have with security because they are lacking detailed technical
  knowledge, sufficient time or financial resources for establishing a
  sufficient network protection. There are obviously moderate deficits in
  the current information security architecture, which need to be resolved
  by finding and applying long-term solutions to the current software and
  network infrastructure to act against fundamental weaknesses which can
  currently be avoided but not completely eliminated.





  4         Proposed future security architecture improvements

  As both security technology and system intrusion methods are advancing,
  the situation is beginning to resemble a competitive race between different
  parties trying to improve white-hat technology and black-hat technology.
  Since the advancements in attack technology are happening unpredictably and
  many of the new intrusion methods are evolved without public disclosure,
  further security impacts and threats can not reliably be predicted. Therefore,
  the only approach for the future is to make coordinated efforts at improving
  the white-hat aspect of information technology, which can be done publicly
  with systematic, controlled approaches, in the best and most effective
  possible ways. The following proposals are aimed at programmers, free
  developers and companies, and also attempt to assist everyone who is
  unsatisfied with his present security architecture to point out possibilities
  of migrating to improved security standards. The main approach I will be
  taking is to identify basic weaknesses in the security model of the
  Internet and today's networks, and propose approaches to specifically work
  against these existent certain weaknesses.


  4.1       Improving incident response capabilities

  One of today's biggest organizational problems on the Internet is the
  uncontrolled flow of information. Because of the decentralized, non-
  authoritative nature of the Internet, information is being distributed
  over a variety of different channels, including security organizations,
  but also news groups, and media sites, which often do not provide reliable
  and complete information, causing unnecessary panic and paranoia on one hand,
  and insufficient awareness on the other. There exists a deficit in present
  incident response structures through which security relevant information
  is being gathered, evaluated and distributed.

  4.1.1     A new approach to incident consulting

  As technology increasingly tends to outstrip policy, user education and
  transparent information exchange are gaining importance. Incident Response
  Teams should no longer operate within restrictive guidelines. One of the most
  important tasks of incident response should be prevention. This should be
  realized by practical education and promotion of open security models.
  Security consulting should generate awareness that the 'security through
  obscurity' principle is not working against problems, but making things
  worse in the long term. Preventive measures should also include distribution
  of intrusion methods and tools, as well as long term weaknesses to the
  public. Generating awareness and educating people towards following the path
  of a hacker ensures that they themselves can realize appropriate security
  measures and recognize incidents and threats. It should also be mentioned that
  such a strategy could drastically reduce the expensiveness of information
  security in the future. [40] Incident response should aim to offer as many
  as possible different approaches and options to users regarding the solution
  to a problem. When offered many unique solutions, users can combine the
  different approaches and build scalable solutions. By being able to choose
  and weigh aspects of different options, they will also be motivated to
  get deeper into the details of the technology they use and might find new
  security solutions they can apply themselves. Another important service which
  incident response and emergency consulting should offer is informal and
  anonymous consulting. A big present problem is that especially companies are
  afraid of image and popularity loss when they have experienced compromises and
  should be releasing public information about it. If the task of showing such
  organizations that admitting to having security problems is the first step
  to improving their security is too hard, they should at least be assured
  that they can get anonymous consultation and emergency services, to help
  them in performing some 'first aid' security measures and to evaluate and
  distribute possibly valuable information about such incidents, which
  would have otherwise not been gained.

  4.1.2     Incident response and law enforcement

  Originally, incident response capabilities have been established by military
  or government agencies and big companies. One of their primary tasks was to
  collect notifications of intrusions, investigate (i.e. track down the
  responsible individual(s)) and, in most cases, to hand their information over
  to law enforcement. In my personal opinion, law enforcement should be
  reviewed critically when it comes to computer crime prevention. The reason
  is that the effects of law enforcement are, in this case, very limited.
  Intruders can be tracked, which however requires reasonable effort most of
  the time, not to mention the poor efficiency of computer crime trials, but
  the problem is that the possibility of incident occurrence is not related
  to single intruders, but to the level of security present on your network.
  If you manage to track down a particular individual compromising your
  security, but do not greatly improve your security after a security incident,
  chances are good that intrusions from other people keep occurring.
  Prevention of computer crime in general cannot be established by introducing
  harder penalties or better methods of law enforcement either, as deterring
  measures to prevent committing of crime can be considered as inefficient in
  this case [41], and a prevention system that relies on extensive reporting
  and countermeasures against any insignificant intrusion related activity
  could even lead to Internet security getting worse [42].

  4.1.3     Establishing an incident response infrastructure

  As a measure against developing intrusion technology, information exchange
  between institutions and organizations, companies and countries play a key
  role in early identification of new software, methods, and strategies adopted
  by intruders, which is essential for the security industry to keep up with
  them. Insights about methods that have individually proven to be successful
  against intrusion or attack methods need to be spread to improve global
  security. Incident Response Teams have to consider offering solutions that
  take common organizational problems into account like low budgets for
  security and fear of image loss. By designing solutions and emergency
  measures that are applicable despite of such problems of companies and
  organizations, incident response will assure helping a larger community,
  and incident response and consulting services will also gain popularity.
  In the same way in which security organizations and private Incident
  Response Teams should be cooperating with each other, an incident response
  structure should be established in form of a global security consortium,
  that coordinates information exchange between national, local, and private
  Incident Response Teams. If members from as many as possible countries would
  offer emergency consulting and incident response, while featuring 24 hour
  hotlines with real-time support, anonymous incident reporting, and incident
  reporting over the Internet using secure services, there would be an ideal
  flow of incident information, statistic information and latest security
  measures. Additionally, all options, including law enforcement, should be
  optional for help seeking attack victims, to enhance flexibility of the
  offered services, and different urgency levels and guidelines should be
  established, to assure that individual emergency incident response is
  available in wide spread or specifically imminent cases.


  4.2       Operating systems

  A coherent security architecture must be based on security established on
  different recursive layers of information processing. Strong security
  capabilities of the operating system are mandatory so that further security
  implementations in facilities such as network transport, user access handling
  and application stability can have reliable effects. The following section
  deals with some of the basic features that should be implemented at kernel
  level to enable high-level information handling facilities to provide a
  maximum of stability and protection to information systems.

  4.2.1     Privilege separation and kernel-based security

  Establishing security at system kernel level means to achieve optimal
  control, stability, and predictability of low level system events. For any
  truly secure operating system, it is therefore mandatory to use different
  security levels in which it can operate. At least two different modes of
  operation should be established, a maintenance mode, in which all systems
  resources can be freely accessed while being off-line, and a regular mode,
  in which the kernel will protect critical and fundamental system facilities
  and prevent any user or super-user intervention against these to assure
  basic system stability and security. [43]
  The next security measure to apply to kernel design are better user-level
  privilege restrictions, to narrow down possible misuse of functions which are
  not supposed to be called in certain process- or privilege specific context.
  Privileges including the triggering of system events and access to resources
  and data need to be separated and managed individually by the administrator.
  If an access matrix could be created and managed, which controls access
  over all specific privileges, compartmented sets consisting of only the
  privileges necessary in each case could be delegated to specific processes
  and entities (different user levels / accounts). One set of permissions could,
  for example, be represented by the network family of functions, using access
  control to manage user level based privileges of opening different types of
  sockets, binding to privileged ports, or establishing active and passive
  connections. Additionally to determining privileges dependent from the file
  system flags of a binary and the authorization of the entity under which a
  process is run, dependence of other conditions should also be relevant to
  determine which privileges are delegated to a running process; for example,
  if the factual user ID does match the effective user ID, or if a process is
  running in a restricted (chroot()'ed, for example) environment. [44]
  Further methods of hardening the operating systems core operations include
  methodological and structured kernel design, aiming at redundant security
  and verification layers, abstraction of different compartments of kernel
  tasks (I/O operations, cryptographic/mathematical operations, memory
  and resource access, network related functions), a maximum of facilities
  that can work and fail independently from system stability and security,
  and a kernel designed to use only completely defined, audited and documented
  operating methods to ensure reliable kernel behavior under all circumstances.

  4.2.2     Kernel-based authentication

  One of the big security weaknesses of systems exposed to the Internet are
  remote vulnerabilities of network daemons which can be exploited without
  even having finished the authentication stage of a service. Since the
  authentication methods of most service protocols are defined in detail
  via RFC and other established Internet standards, it would be possible to
  perform at least the authentication part of many sessions with a unified
  interface, just like incoming packets are all handled and processed equally
  by a systems protocol stack. I am only suggesting this as an optional solution
  to eliminating some of the widespread weaknesses in server software, and if
  authentication is applied at kernel level, it must not only be designed with
  security, but also availability, stability and performance in mind. In my
  proposed approach, authentication would be implemented in the protocol stack,
  and could be optionally enabled for certain services. The protocol stack
  would, after receiving a session request, act as a proxy and establish the
  session at kernel level after accurately identifying the client is making a
  valid request (for tcp services, by completing the 3-way protocol handshake),
  and before passing session control to the application authenticate the
  session using the authentication standard of the services protocol which is
  assigned to the destination port and then invoke the actual server
  application. From there, it could either, as a temporary solution be checked
  that the authentication fields contain sane values and the session including
  the initial authentication data is then passed to a traditional application,
  or as a better future method, the kernel would be passing an authentication
  token to a future server application which would start taking control of the
  session after the authentication stage. This service should be an option
  that can be activated as an alternative to traditional session initiation.
  If applied at kernel level, it could also take a unified approach at secure
  authentication and session key exchange via kerberos or other cryptographic
  challenge protocols [45]. The described method could, of course, also be
  applied to a system by implementing it into a multi-service network
  daemon similar to inetd(8).

  4.2.3       Privilege and permission separation

  4.2.3.1     Sand boxes versus protective cages

  To effectively separate the privileges of a users' processes, a system
  needs to employ what I could be called access oriented design - kernel based
  access controls have to be present in a multi-user system architecture.
  This can be realized either with access oriented processes or access oriented
  user environments, which will be explained in detail below. The purpose of
  this design is not only to enforce access restriction but additionally the
  implementation of trusted paths, through which trusted information and
  executable content can be accessed and executed while being protected against
  manipulation of information, malicious code, and unwanted execution of
  generally unclassified or untrusted code. This concept could be called
  'mandatory restricted code execution' and is especially necessary when using
  closed-source systems and applications where the user can not clearly
  determine the actions taken by a program, and to protect users against being
  tricked or forced into executing trojan and malicious code, that has either
  been acquired or introduced by an intruder who manipulated the system.
  In the "sand box" model, user processes are access oriented receiving only a
  restricted set of resources and privileges, that forms a virtual environment
  in which they operate. This prevents the processes from executing external
  resources and any untrusted code that has not been approved as being a part
  of the "sand box". An example for this is the Java Virtual Machine (tm) and
  various script languages for web content which are executed at the client
  side. However, these kind of restricted processes and especially shells are
  hard to securely implement and to manage, they are overly confining and
  they are based on a security design which can be overcome, if any aspect of
  an allowed program, privilege or resource should accidentally allow to
  execute arbitrary programs or code, breaking the restricted environment.
  An alternative model is an access oriented user environment which delegates
  privileges to each process based on access control guidelines and
  restrictions related to user identification and the trusted state of binaries
  and files. I refer to this model as the "protective cage", in which the
  associated processes reside inside a protected environment with the full
  set of functions and resources at their disposal (although access to
  them is of course still being controlled at kernel level). To enforce
  mandatory restricted code execution in this model, the system should maintain
  a list of trusted system binaries and their cryptographic checksums. These
  checksums could be kept in a special area of the file system or configuration
  database file, and must never be able to be modified or created in the normal
  system security level. To make changes to this database, physical interaction
  should be necessary (e.g. rebooting the machine into maintenance mode and
  operating at the physical console) for the super-user account to commit any
  changes. In the normal system mode where critical resources are being
  protected, the kernel must recognize such files and perform cryptographic
  file integrity verification on them. If the cryptographic verification fails,
  the files should be flagged as untrusted and therefore non-executable, and an
  alert should be automatically issued so the original files can be restored by
  the administrator. This protection is especially recommended to be applied to
  setuid/setgid programs, shared libraries, kernel modules, system maintenance
  tools, and servers that run with elevated privileges. It should also be used
  to generate a restricted environment for users with elevated privileges, who
  can then chose to activate the restricted environment (the "protective cage")
  at any time, in order to be sure to only access trusted binaries which have
  been initially approved. A feature which could greatly support this scheme
  would be file system implementations which support new flags and file system
  attributes which represent capabilities and privileges [46].

  4.2.3.2   Differentiated access permissions

  Separating access permissions to data and shared resources primarily serves
  the purpose of achieving confidentiality for individual users. Cryptography
  should be a standard feature of future file systems, to assure privacy, and
  to prevent attacks aimed against the compromise of confidential data. This
  approach should include time-based security, unique key creation for each
  user, and transparent encryption and decryption features of the kernel
  coupled with user specific data keys. That way, a separated access to
  non-shared information resources on one system could be achieved, which
  would help to mitigate the potential of race condition exploits and
  espionage of security relevant or otherwise confidential information
  left accidentally unprotected by users.

  4.2.4     Auditing requirements

  Kernel based auditing facilities are key factors for establishing fundamental
  security and control on a system. One purpose of audit functions is to ensure
  that critical parts of the system configuration, which can have impacts on
  the machines security, meet certain security requirements in a way that
  implements the desired security policy. Parts of the system configuration
  compiled and implemented under individual human control (everything that is
  variable, configurable and optional for the user) should be evaluated and
  parsed in a restrictive way, that ensures fail-safe security. A systems
  interface should not be counterintuitive, but its error tolerating and
  tolerance features for arbitrary input must not exceed a maximum level beyond
  which erroneous and insecure configuration can impact the systems security
  measures, without refusing to accept such configurations or at least issue
  clear and understandable warnings. A common problem for large sites is
  to maintain secure configuration on a large amount of machines equally. My
  suggesting is to design systems which accept and propagate site policies,
  in form of distributed configuration management. A facility could implement
  features to transfer configuration information and desired system condition
  to other hosts on the network, cloning or reproducing a system state of one
  host which has securely been configured and audited with scrutiny to other
  machines on the network.
  The second purpose of auditing is to generate audit trails, information about
  system events, network- and user activity, which are needed to recapitulate
  the flow of events and identify possible intrusions, configuration errors
  and other critical irregularities. Though present logging facilities already
  generate an overwhelming amount of information, they do not greatly
  differentiate between regular, informational audit information and security
  relevant (audit trails that can especially show the existence or absence of
  intrusions and irregularities) as well as security critical (audit trails
  which are created when system security or stability is being or has been
  actively harmed) information. The monitoring of security significant events
  should be focused on, and stored in a way that one can easy differ between
  events showing unusual activity and information recording regular activity.
  Ideally, a system should shall have the ability of recording all occurring
  events down to single functions called at kernel level, and employ mechanisms
  which let the user selectively and dynamically manage the types of audit
  trails that the system should generate.
  System events which should especially be audited and extensively documented
  by auditing facilities include any processes initiated with elevated
  privileges, and events that could intentionally or unintentionally generate
  a point of access on a machine, such as binding to a port, handling data via
  low layer sockets or system calls, and the receiving of network traffic.
  These facilities must lay the foundation for the auditing requirements which
  have to be further implemented at higher levels, such as system loggers,
  process communication, and intrusion detection / auditing applications,
  which are described in the following section.


  4.3       Auditing software

  4.3.1     Evolving intrusion detection

  Since the first traffic loggers and port scan detectors had been designed,
  classical intrusion detection has been relying on monitoring network traffic
  and system events and identifying unusual actions and objects to determine
  intrusions. While this is a valuable concept, it does contain fundamental
  weaknesses (as described in 3.2.2) and has to be completed. Sophisticated
  attacks against a system which either employ evasion techniques [36] or try
  not to violate a given ruleset (for example, by gaining access from a trusted
  host and using compromised authentication data) can still very possibly be
  successful without even being noticed by classic detection methods. To
  substitute these weaknesses, future intrusion detection should be designed
  to detect intrusive events by employing heuristics. So, you should actively
  analyze all system actions and network traffic and intelligently determine
  what probably constitutes anomalous events. A sophisticated approach to
  intrusion detection heuristics would be to let an IDS analyze regular events
  on a network and supply it with hints about what could constitute an
  intrusion, in form of information about how different attack scenarios cause
  certain network and system events to occur, and in which contexts.
  An easier method would be to regard statistical anomalies as possible
  indications of an intrusion, outweighing occurrences of different events,
  depending on network throughput, connection states, errors reported by
  applications, etc. while differentiating between the severity of certain
  events, e.g. some events are regarded a less significant indicator for
  intrusions, so that it takes a huge amount of those events to trigger an
  actual match, and other events which are more security critical or more
  common and reliable indicators for intrusions are regarded as highly
  significant and trigger alerts after only few occurrences.
  Future IDS should additionally be able to distinguish between different
  attack phases. [47]
  IDS should react differently to these phases. While only internally
  recognizing initial information gathering, it should issue an alert when a
  system is being scanned intensively, and when an intrusion attempt is
  recognized that endangers system security, the intrusion system should,
  in addition to issuing an alert, actively facilitate corrective action to
  prevent impacts on security (depending on the kind of attack, filtering rules
  should be set, the intruders connection to the server should be terminated,
  or abusive access to a service should be revoked automatically). To determine
  at which point which action should be taken, threshold values, determining
  the maximum tolerable incident indicators, should be either configurable or
  determined by the IDS based on generic average values and the statistical
  analysis of traffic flow on the particular network on which it is operating.
  Another concept that is beneficial to intrusion detection operations is
  the ability to gain and evaluate the maximum amount of information about
  ongoing events as possible. Therefore, future IDS should work closer with
  audit trails produced at system and application level, and be generally
  designed as distributed applications, in form of remote network agents which
  gain and pre-process audit data and forward relevant information to a
  central, possibly dedicated host on which a IDS server is running and
  evaluating the different events by analyzing them in context.

  4.3.2     Evolving proactive auditing technology

  To verify the presence of robust and (mostly) impenetrable security measures,
  it is always advisable to perform active auditing in form of version and
  configuration reviews, and by testing servers and system protection.
  Since manual or systematic file auditing of the code base would be very
  costly and inefficient, the major part of these proactive auditing tasks
  should be carried out from the perspective of an intruder, namely, by
  scanning a system for possibilities to compromise its security. While
  current auditing scanners are already quite sophisticated and spot a large
  range of remote and local vulnerabilities and mis-configurations, a basic
  problem they suffer from is similar to the IDS problem; their scanning
  signatures have to be updated frequently, as new programs containing new
  vulnerabilities come out. Therefore, software distributors should be
  encouraged to publish auditing tools for their systems and applications,
  detecting especially insecure configurations, and to develop and maintain
  standardized vulnerability and mis-configuration pattern databases which
  can easily be implemented into auditing scanners.
  Auditing should perform its task systematic and thorough, with the aim to
  support reliable configuration base design, which is especially important
  when scanning firewalls, intrusion detection system and trying to penetrate
  critical facilities such as system loggers. The penetration aspect of auditing
  should also always be implemented; nowadays, checking for immunity against
  latest Denial Of Service (e.g. fragmentation, land, syn floods) should be
  mandatory as well as either employing basic low level IDS evasion tactics
  to scan, or specifically penetrating and detecting IDS which suffer from
  such weaknesses. It is also recommended that an auditing tool uses a core
  part which gathers as much information about a system as possible (e.g. by
  recording all servers versions and remotely determinable configuration
  aspects) and then evaluates, determines and attempts to exploit certain
  present vulnerabilities with a separated evaluation part. The evaluation
  part of auditing software should be designed modular and extendable, as
  future necessity to detect new vulnerabilities is certain to come.
  One of the biggest advantages for the black-hat system intruders is that
  they can carry out attacks and scans on a distributed basis. [48]
  Developing distributed aspects is an approach that scanning software should
  take as well, to scan internal networks completely. My suggestion for future
  scanners is to implement Internet worm like behavior into them. They could
  be constructed to take advantage of all existing vulnerabilities to spread
  through a network and identify its weaknesses, in a way simulating the
  behavior of real intruders. This means to take advantage of mis-configured
  proxy servers and protocol weaknesses to try to bypass firewall rules,
  exploit vulnerabilities in remote servers, then copy themselves onto the
  compromised systems, trying to get higher privileges by exploiting local
  vulnerabilities and then using the compromised systems resources to
  gain unauthorized access to trusted hosts and to carry on the scanning
  process from there. Naturally, the scanner has to be instructed to audit
  only a predefined domain or network range. I think the development of such
  an auditing tool would make an interesting open project, that could assist
  in improvement of coherent network auditing techniques, and also visualize
  the methodology of intruders and occurring security incidents on the
  Internet in a bigger scope.


  4.4       Networking architecture

  Originally, the Internet was designed for military and academic purposes,
  for researching, providing access to data over long distances, and as
  a communication infrastructure for a relatively small set of institutions
  and persons that knew and trusted each other. This scenario is the origin of
  the Internet's network structure as we know it today. Many of today's protocol
  standards for data transmission and packet switching have been designed in an
  environment in which essentially everyone was considered trustworthy. These
  standards can no longer satisfy today's ever-growing demands of industrial,
  civil and commercial applications. These traditional protocols and methods
  are still being deployed on the homogeneous, un-trusted Internet of today,
  while the rate of its members is drastically increasing, and its overall
  bandwidth is growing by nearly one hundred percent every year. Through the
  latest incidents and attack methods, it has become obvious that new
  standards have to be defined and implemented to suit the high performance
  and security demands of today and the future.

  4.4.1     Routing security
  
  4.4.1.1   Improving availability

  With steadily growing bandwidth, the impact which intentional disturbances
  can have on network availability have become more serious than all other
  weaknesses and common malfunctions. Therefore, a central point of future
  routing technology has to be the prevention of intentional attacks by
  minimizing the opportunity for attackers to commence such attacks.
  To protect against source address spoofing, all routers should perform
  mandatory sanity checks in form of forcibly blocking traffic coming
  from local network ports with foreign source addresses, and dropping
  packets for which no predetermined routes exist, when they experience
  large amounts of traffic with different source addresses that exceeds
  a threshold after which it is considered as a packet flooding attack
  which employs randomly forged IP source addresses, in order to assure
  better service for machines already known to have authentic IP addresses.
  Approaches to preventing attack and optimizing traffic flow will often
  require expensive routing features, complicated algorithms for routing
  large amounts of traffic between different prefixes efficiently, and access
  control lists, while the use of these techniques can degrade the performance
  of routing significantly. To limit the necessity for increasingly
  sophisticated and expensive hardware, a solution should be designed that
  makes use of different multiprocessors to handle separate tasks.
  For example, one processor (or one set of processors) takes care of
  maintaining, parsing and applying extensive routing policies to traffic,
  and the other processor is just instructed with the results (i.e. the
  defined route) and can concentrate on I/O operations for optimal traffic
  forwarding performance. An additional advantage that this concept could
  bear, is processors mutually substituting each other to prevent complete
  routing outages. For example, if the I/O forwarding processor would get
  overloaded, the other one would recognize that it is no longer responsive,
  and fall back to autonomous I/O forwarding mode, using static routing from
  a predefined set of restrictive backup routes, and if only the route-
  determining part would get overloaded, the I/O processor would also use this
  set to operate independently. The router could then also possibly reset the
  overloaded CPU and re-initialize it, without needing to reboot and
  interrupting any active traffic, while the remaining processor stays in
  emergency mode until the other one is back.
  Another source of errors that have big impacts on network availability are
  misconfigurations in routing tables. Routers should encourage engineers to
  make extensive use of dynamic routes determined by the router, by presenting
  easy and feasible approaches for large and medium networks to migrate from
  static routes. Static routing, mostly via plain RIP, is still too popular
  and can cause big errors which are hard to track, if a large amount of route
  configuration is done manually. Routers, in general, should be less error
  tolerant when discovering that routes to unreachable hosts are set. [49]
  A capability of the Internet Protocol are Type Of Service and Quality Of
  Service facilities, which make it possible to set different priorities
  for different kinds of data streams. These facilities should not only be
  utilized to determine different types of sessions, but also to determine
  different security and authentication levels of traffic. For example, traffic
  from a host using a protocol which can reliably identify the host as the
  authentic origin (such as IPSEC or IPv6), and traffic transported by
  reliable connection-oriented protocols (after the session link has been
  established) should be able to be routed with a higher TOS or QoS priority
  on demand. This could improve availability of legit network traffic, while
  the priority and therefore the impact of packet flooding attacks, which
  mostly base on forged and connectionless traffic, could be reduced.

  4.4.1.2   Improving access controls and authenticity

  The authentication features which need to be improved are mostly of
  internal nature (i.e. routing protocol related). Routers need to operate
  in a stable and tamper proof manner, which includes that no data may be
  manipulated from arbitrary sources. Therefore, cryptographic user and
  session authorization should be mandatory for all future internal routing
  protocols and administration interfaces.
  Authenticity, in this case, is especially a problem when it comes to
  reliable detection of the origin of traffic. IPv6 and other future
  versions of protocols which implement security will improve the level
  of authenticity. However, they cannot fully and immediately eliminate
  these issues [50], therefore, measures of origin determination by
  tracking back traffic (see also 3.1.3.2) have to be evolved additionally
  to migrate to new protocol standards.
  As it is known, actively tracing traffic back to its origin can be a
  hard task. The issue is complicated due to co-operation problems with
  other networks and due to the fact that the tracing process via routing
  table information has to be done very quickly after the traffic is received
  in order to be successful. My suggestion is to develop a fast, remotely
  accessible traffic accounting facility which should be implemented in
  the routers of Internet backbones and big networks which route global
  traffic. Although read access to routing information is not generally
  considered as confidential, it can reveal the internal routing structure
  of networks, and may therefore be limited to authorized hosts. The routers
  should each recognize the routers authorized for tracing directly connected
  to them. A backtracking feature could work much like the RECORD_ROUTE
  facility in ICMP, and could be implemented as follows.
  An administrator logs into a router and requests origin information for
  a packet which pretends to be coming from a certain address. The router then
  determines from which external port, and therefore, from which directly
  connected router the packet came. The router issues a request to that
  router, which then determines its own port from which the packet entered.
  That router then tries to query the next router, and the chain of queries is
  followed until a router is reached which does not respond to backtracking
  queries. If this is the case, the last backtracking router sends information
  back to the router which originally requested a trace, submitting it the
  address of the last determinable router. If such a feature would be developed
  and actively implemented, an easy interface to gathering origin data, which
  would help to narrow down the real origin of any traffic, could be designed,
  which could represent an interesting alternative to the necessity of
  Internet-wide co-operation between backbone and service providers.

  4.4.2     Protocol security

  Improved Internet protocol standards, which offer enhanced integrity,
  confidentiality, and availability have already been due for some time.
  Internet transport and session layer protocols lay the foundation of
  network traffic, and if they have weaknesses, the chain of network
  security architecture consists of a weak link, at which it can be broken.
  Additionally to these issues, the currently available space for Internet
  addresses will not be sufficient anymore for a long time. In a period of
  as short as five years, all current IP addresses could be used up, and
  the industry will be forced to migrate. However, this weakness of IPv4 has
  had an impact on the Internet's infrastructure already [51].
  However, many of the next generation protocols have actually been around
  for some time. Clearly defined and suitable standards for protocols like
  IPv6 already exist. They have been created more than two years ago, and offer
  transport-level encryption, reliable origin determination via authentication
  header (this does take care of spoofing attacks and reliable authentication
  of connectionless sessions), and different traffic priority levels. If two
  parties both employing these techniques communicate using these standards,
  high authentication and confidentiality demands can be satisfied. Therefore,
  it should be considered as an alternative to non-standardized VPN technology,
  which can often be quite expensive and hard to implement. Everyone is
  encouraged to make use of the new IP security standards, as migration is
  quite feasible. IPv6 addresses are already being assigned by ARIN since 1999,
  and used on the Internet. Until the public breakthrough of the new version
  of IP, alternatives in form of IPSEC tunneling via IPv4 should strongly be
  considered. Besides implementing IPSEC capabilities at operating system or
  protocol stack level, there are other good approaches to implement IPSEC
  with a minimum of effort. Other security improved protocols worth mentioning
  include SDNS (Domain Name Service Protocol with secure authentication), ICMP
  next generation (which will be implemented along with IPv6), and RIP II (which
  can easily be employed in current networks and is strongly recommended
  for medium to large networks still using RIP I).
  When it comes to introduction of security enhanced protocols, a fundamental
  problem the Internet society is facing is the lack of current Public Key
  standards and a Public Key Infrastructure, which are needed because a core
  aspect of the security features of security enhanced protocols is mostly
  cryptography using asymmetrical cryptography.

  4.4.3     Public Key Infrastructure

  One of the crucial reasons why there has not yet been a breakthrough in
  using IPv6 and other protocols based on public key cryptography on standard
  environments, are the difficulties in establishing a worldwide Public Key
  cryptography standard and infrastructure. Although PKI is an important
  matter and should therefore be standardized with scrutiny, a standard that is
  acceptable for everyone should be found as soon as possible, as the further
  development of the Internet depends on it. Apparently, there are more
  factors than only the technical aspect involved, for example national
  cryptography laws and design of individual policies involving PKI.
  The proposal in this paper, however, concentrates on the technical aspects
  of implementing a PKI solution for Internet Key Exchange (IKE) which is
  needed for transport-layer encryption and authentication, because this
  could drastically improve general security standards on the Internet.
  The basic requirements that an IKE solution should implement are a
  transparent exchange of public host keys (so that it can be integrated
  in applications and protocol stacks), providing authentic verification
  of the key exchange servers, and a distributed design that makes a
  decentralized key server structure possible. One of the currently
  proposed protocols is ISAKMP, which makes use of cryptographic
  challenges and signatures to authenticate requests, and can be used for
  exchanging keys for arbitrary algorithms and protocols. While ISAKMP
  could become a good choice for exchange of public keys for a variety
  of different services with cryptographic authentication, it relies on the
  existence of a hierarchical set of Certification Authorities [53]. Therefore,
  alternatives should be considered for the key exchange of host keys.
  The IPv6 Security Association, which is used to authenticate and encrypt
  traffic at the transport layer, associates each host with a unique public
  key identification number.
  My suggestion is to use an improved version of the Domain Name Service
  protocol to exchange public keys amongst the Internet, since the DNS protocol
  is extremely suitable for associating a unique value with a certain Internet
  address. Additionally, there is already a working DNS zone hierarchy
  present on the Internet, which eliminates the inevitable necessity of a
  global Certification Authority infrastructure. A new DNS protocol version,
  which employs key- or challenge-based authentication would be sufficiently
  secure to authenticate domain name servers as being authoritative for a
  specific domain, and for the keys associated with the hosts on that domain.
  This system would additionally improve protection against spoofing attacks
  which involve attacks against the Domain Name System, and there are good
  technical approaches present to implement it [54].
  The Security Parameter Index could then contain information about the
  authoritative DNS records. In this model, the registration of new
  IP addresses could also contain public key generation and assignment
  on authoritative Domain Name Servers by address registration centers with
  local, national or worldwide authority for the assigning of IP addresses.


  4.5       Improving software design

  Nearly every information security problem of the past has been a result
  of vulnerable, insecure or otherwise weak software. Conceptual approaches
  to the design of standards and software have been done with merchantability,
  ease of use, and ease of implementation in mind. While such concepts are
  good, they should never lead to security and stability issues being
  disregarded. Within this scenario, better approaches to developing, designing
  and implementing code are essential. The following section will offer
  approaches to systematically designing and assessing secure software, and
  point out some of the most important security considerations that
  should be made in the basic security design for software.

  4.5.1     Technology standards

  A major deficit of today's technological standards are vague specifications
  and lack of technical detail. When a new protocol architecture is being
  described, software developers should at least given hint about where
  possible caveats and vulnerabilities could be present. Often, developers have
  to analyze such weaknesses themselves when designing software that should
  suit new standards. Since standards generally take time to fully understand
  and to implement, people who implement them should at least be given support
  in the form of descriptions in the nature of a standard, along with their
  strengths and weaknesses. As a positive side effect, this requires designers
  of standards to analyze and rethink details of their technical proposals.
  Drafts for completely new concepts should also contain the descriptions of
  mechanisms that can systematically help to eliminate weaknesses and security
  hazards. It is suggested that they at least describe one valid, complete 
  configuration of a functional software implementation under which no
  fundamental security vulnerabilities are present.
  Developers and software vendors should always be given the opportunity to
  use identical interfaces and methods for their implementations. That way,
  a security and usage policy determined suitable for one product could affect
  security for other products and could be universally applicable, without
  having to regard technical differences on specific platforms or brands.
  Technical concepts which leave the definitions of exact structures and
  methods of a programming standard to the developers will result in
  products based on the same standards which are factually different in
  detail, and possibly in error susceptible code. Examples include the
  network file system, remote procedure calls and other applications using
  the early external data representation standard as well as early versions
  of Internet smtp agents. For organizations and communities which are actively
  developing production standards, it is strongly recommended to include
  details and practical examples, and to think over the architectural design
  of standards in general to make sure that the concept is foolproof.
  Something else that the stability of software industry is also relying on is
  the fast development of and agreement upon practical standards. If
  responsible organizations completely fail to develop such a particular
  standard in a special case, leaders in the software and security industry
  should be encouraged to cooperate with each other and develop a self-approved
  de facto standard which complies to the appropriate criteria. [55]

  4.5.2     Network application security

  Network applications should be designed with special care about their
  security, because they are generally supposed to be used in a non-trusted
  environment in which anyone can access them, and therefore exploit present
  weaknesses in their architecture. The security demands of network application
  include stability, integrity (i.e. they must be fool- and tamper proof),
  performance and confidentiality. The latter should be achieved by routine
  encryption of sessions using SSL or similar techniques. Cryptographic
  authentication is also an important issue, which should be used to enhance
  verification and authenticity insurance of transmissions on both client and
  server side, to prevent insertion and manipulation of traffic, and to
  generate audit trails whose content cannot be affected by bogus connections,
  and uses the cryptographic origin verification to generate a reliable
  transcript of all security events and the actual parties involved.
  For this purpose, a challenge protocol should be used, for example Kerberos,
  that never sends actual authentication data in plaintext across the wire.
  To design stable and reliably working programs, the complexity of source
  code and functions should be reduced and kept on a minimal basis.
  It is also a generally bad idea to introduce default configurations which
  with a program runs. Flexibility and options can help a user to
  customize the behavior of a program and therefore improve security in
  detail where it is needed. The introduction of more intelligent and user
  friendly configuration management would be beneficial, but is not required.
  Instead, developers should hire people for the purpose of writing more
  comprehensible documentation. The documentation should not only describe
  the usage and features of a program, but try to explain the technical
  methods it uses to fulfill its tasks. Educating users to understand the
  programs they use can be a great method of improving security that should never
  be underestimated. Networking daemons should ideally work in a secure, custom
  environment, i.e. under a separate account with the minimum of privileges
  needed to fulfill its task, to prevent access and possible compromise of
  large parts of a systems resources by remote users.
  A final important thing that should be mandatory for the development of all
  networking applications is systematic auditing of the program. Developers
  should try to systematically uncover all implementation flaws, beginning
  with main features and supposedly fragile aspects of the program and
  proceeding to data structures and overall layout.

  4.5.3     Software development security design methodology

  Despite all security improvements of access control measures, conceptual
  design, policies and standard, the most important issue to consider is
  the authoring of secure code. This can quite be a challenge for software
  producers, while the actual difficulty of design methods are not the major
  problem, but the fact that many programmers are unaware of these methods. The
  following section will try to help programmers to recognize the basic aspects
  that need to be considered for writing program code which is sufficiently
  secure for the implementation of future applications and systems. First,
  most programmers need to realize that security has nothing to do with
  functionality. Most software vendors do not have standard security systems
  for code creation and review in place. They are relying on a method of
  software development that focuses on immediate results. While this approach
  does lead to fast development of feature-rich software, it fails horribly at
  implementing stability and reliability into the software's operations.
  Before explaining in detail how to apply secure coding methodology, I am
  going to explain where to apply it. It is mandatory to employ secure,
  fail-safe coding practice when designing network daemons, suid/sgid
  applications and all other software that runs with elevated privileges
  (most commonly root in today's environments). Programs with elevated
  privileges sit on security boundaries. Most of the time they take input
  from other programs that have lower access privileges than they do.
  This means, a program running with elevated privileges can, at worst,
  be forced into executing arbitrary instructions that have the elevated
  privileges of that program. This is the reason why such programs have to
  be designed with extreme scrutiny. Generally, program security should
  always be considered when writing program code, as code can and is often
  being reused for completely different tasks and purposes.
  Some basic guidelines for program design include writing simple code.
  Avoiding complexity and reducing the code size greatly decreases the
  amount of bugs and potential bugs in the form of weaknesses in your code.
  Another crucial point is open design. Nobody should rely on security
  through obscurity, as every publicly available program, even if it is
  closed source, can be completely reverse engineered. Your code should
  also be comprehensible for yourself and others, so that code reuse
  is feasible without having to completely re-analyze it. To realize this,
  code should be well-structured and commented. When it comes to user
  interaction, programs should be easy to configure and control in a
  secure manner. They should also offer options to generate extensive
  audit trails for verification and event recapitulation purposes.
  The default configuration of a program should be made fail-safe, i.e.
  so that it denies any form of access and disables extended features by
  default. Additionally, programs with elevated privileges should employ
  separation of privileges. Necessary privileges should only be gained
  or activated at different times in different routines or processes,
  and generally, the principle of least privilege should be enforced.
  To get more into technical details, common programming mechanisms and
  functions should be evaded, along with using shared system resources,
  which all can increase the volatility of the program. Your own, already
  audited and approved, secure code should be frequently improved and
  reused in new programs. Inheritance of large, bulky types and functions
  which call sub functions themselves, should be avoided. Instead, code
  should be re-implemented where it is beneficial to overall program security.
  Outside input (as in users, network traffic, system signals and events)
  should generally be mistrusted, and even considered to be able to take
  direct malicious actions against a program at the worst time and in
  the worst way imaginable. Internal protective and preventive measures
  against vulnerabilities to which a program might be exposed due to its
  nature, should be implemented, for example in the form of sanity checks,
  excessive load- and internal resource usage quotas. Special methods and
  constructions that should be avoided at all costs include all non-bounds-
  checking functions, complex and foreign data handling algorithms, such as
  getopts(), string parsing operations without bounds checking, gethostbyname()
  (note: due to weaknesses in the current DNS protocol, hostnames should be
  determined via dual-reverse lookup, meaning that a normal query and an
  additional inverse query should be performed for each lookup), handling of
  symlinks and other special files, checking files before overwriting and
  accessing them and using secure, non-predictable temporary file names to
  prevent race conditions, preventing direct memory access and core file
  creation in critical situations, using real randomness and unpredictable
  random seed for random number generators, making sure that buffers are
  always bound with a terminating binary zero, setting timeouts on network
  operations, and running in a restricted (for example, chroot()'ed)
  environment, where possible.
  Additionally to all these security precautions that can be taken, code
  auditing and reviewing is absolutely necessary to ensure the stability
  and security of programs, just as both preventive and proactive auditing
  have to be used to adequately secure a computer system. Code auditing
  includes trying to overflow every static buffer, creating all conceivable
  race-conditions, looking for exploitable vulnerabilities from the perspective
  of an intruder who tries to use weaknesses in the code to gain elevated
  privileges. Secondly, the code has to be audited systematically. This means
  to review every access to any functions and to any objects in the code,
  making sure that operations do not fail in the presence of an intelligent
  and malicious adversary who is trying to forcibly generate faults.
  As a last bit of advice, it should be regarded that spotting bugs in a piece
  of software which is currently in production usually requires having other
  people test the code than those who designed it, to review it from an
  independent perspective.





 
  5           Final words

  I hope that this paper has been able to give you some insights pertaining to
  methods that can be used to improve information security in the future.
  I know that the work on this subject was certainly interesting for me and
  helped me to better understand some security issues in context. I hope that
  my attempt to put different aspects and problems of today's security issues
  on the Internet into coherent context has been successful, and that the
  proposed solutions are useful and comprehensible as well.
  The Internet is a medium with a high potential for development, however,
  one of the side effects is the unlimited flow of information. It is therefore
  quite important to use ones common sense and judgement, without being
  influenced by unreliable sources of information. This also means that
  authorities and established organizations as well as common standards should
  not blindly be trusted. Instead, relying on one's common sense to assess
  proposed and established solutions regarding criteria of security, economy
  and feasibility is essential. Static guidelines such as described in the
  rainbow books, early Internet standards and international standards represent
  the foundation of many parts of today's current security architecture.
  However, some of these guidelines are no longer applicable to the dynamic,
  evolving Internet of today and need to be replaced or renewed.
  Additionally, experience has shown that hierarchic and centralized
  structures, while normally being useful, are often weak points on the
  Internet whose structure itself promotes decentralization.
  One should be aware that misinformation can spread quickly on the Internet
  and cause severe effects. Making up concepts such as Information Warfare,
  are, in my opinion, counterproductive, as focusing on educative approaches is
  generally much more beneficial to the Internet community than counting
  on scare tactics. For example, increased break-in rates into banks lacking
  fundamental security would not be considered as warfare, either. What can
  be considered as Information Warfare is mostly unrelated to information
  security issues on the Internet and should not be used to generate hysteria
  with little factual background in reality.
  Authorities, especially among different governments, political groups, and
  the media have been propagating the solution to security problems in a way
  that promotes security through obscurity.
  But I am confident that the society will tend to walk on the right way
  in the future.
  Even simple or small solutions can help to improve security in general,
  if security issues and measures are identified and treated properly.





  6         Footnotes: technical background, definitions and explanations


 [1] Information security has to be understood as a process aiming
     to improve protection of confidentiality of information, protection
     against unauthorized access and modification of data and the
     protection of the availability of resources and services.

 [2] I am applying the term 'intrusion software' to any kind of software
     that has the single and sole purpose of assaulting or gaining access,
     information or privileges to resources unauthorizedly, including
     vulnerability exploits, although it should be noted that they generally
     do not themselves represent a security issue, but can multiply a threat
     potential that exists due to a present security vulnerability.

 [3] Distributed attack tools are a kind of software that allow processing
     of tasks using distributed resources, in this case with a malicious or
     intrusive intent, such as Denial Of Service.
     References:
     http://packetstorm.securify.com/distributed
     http://www.cert.org/incident_notes/IN-99-07.html
     http://www.cert.org/advisories/CA-99-17-denial-of-service-tools.html

 [4] Resources is a very general term. In the context of this paper, consider
     them as server processes giving access to different privileges, available
     computer memory and processor time, different network capabilities and
     devices, and different kinds of confidential data.

 [5] Known methods of security compromises take advantages of a small set of
     known vulnerability categories, such as weak system kernel protection
     of privileges, undefined behavior on exceptional conditions, unchecked
     data structure bounds / buffer overflowing, unreliable input parsing,
     configuration problems, unreliable access validation, and file/resource
     temporary access insecurity known as race conditions or atomicity errors.

 [6] Access control is a concept that must be able to isolate the full access
     to a systems privileges and capabilities and delegate it selectively to
     different users, resources and processes. Without access control starting
     at the system kernel, access to a system could not be effectively
     authorized and validated, and a separation of privileges that can be
     gained by remote, local, and physical access to a computer system
     could not be achieved.

 [7] As shown by Bruce Schneier and many others, cryptography can be applied
     to improve and secure numerous computing processes. Without access
     controls on a lower level, like a system kernel effectively enforcing
     basic security, most cryptographic measures would be futile because they
     could be circumvented on a lower level; for example, encryption keys and
     system encryption functions could be compromised.
     References:
     http://www.counterpane.com
     "Applied Cryptography: Protocols, Algorithms, and Source Code in C"
     by Bruce Schneier (John Wiley & Sons, 2nd edition, October 1995)

 [8] I define a point of access as any feature or service that has the purpose
     of giving a user access to a systems resources - that is, privileges,
     data or access to other facilities or machines. Practically, a point of
     access is a remote server program, or a local running / suid application
     giving access to higher privileges and data. Every point of access must
     be considered as a possible source for security vulnerabilities and entry
     point for intrusions, while the highest possible access that can be gained
     through an access point is the complete set of system privileges the
     access points' compromisable process thread has at its disposal.

 [9] Denial Of Service is a category of attacks aimed against availability
     of any resources. Exploits of structural weaknesses that result in DoS
     include packet flooding with superior bandwidth, syn flooding and other
     bogus service requests, and exploiting specific vulnerabilities in
     server or operating system software to crash it; while no unauthorized
     access is gained via those attacks, they are much easier to commence and
     sometimes only avoidable with expensive and extreme protective measures.

 [10] Probes can consist of any unusual traffic to your networks host, such as
     connections from the same remote host to all of your services ports,
     unusual errors like reset connections, and incoming packets that seem
     not to serve the purpose of actively communicating with a known service.
     A Network Intrusion Detection System can help in identifying such
     irregularities, while it is, however, not completely reliable and
     leaves the duty of interpreting threat potential and imminence to you.

 [11] Network egress filtering is a measure to identify and minimize incoming
     traffic with spoofed IP addresses and is accomplished by configuring your
     border routers to refuse incoming traffic from unassigned and unreachable
     (not present in global routing tables) hosts, and traffic with IP addresses
     that should not be coming from a specific router port (for example, source
     IP addresses from your local network coming from an outbound port). Network
     ingress filtering, as described in RFC2267, basically means not to permit
     traffic from an inbound port with source IP addresses other than from your
     local network emanating to external networks. While these measures cannot
     protect from DoS attacks or intrusions, they can be used as an extra
     facility for logging and detecting DoS and intrusion attempts that make
     use of spoofed IP addresses.
     References:
     RFC 2267 - Network Ingress Filtering: Defeating Denial of Service
                Attacks which employ IP Source Address Spoofing

 [12] A loghost should be a secure machine with a minimum of remote access
     points to which log data is forwarded in real-time. To forward sysklogd(8)
     traffic to a loghost, syslogd.conf entries like this one are added:
     *.*      @loghost.mydomain.com
     If you use Cisco routers, forward IOS system logs there as well:
      service timestamps log datetime localtime
      logging loghosts.ip.address

 [13] Reliable remote OS identification can be done by querying a machine with 
     a set of TCP packets to which response is undefined in official protocol
     standards, and identifying the operating system by evaluating the
     individual replies to these packets. This can be done with many auditing
     tools, and was originally implemented in Queso and nmap. To avoid remote
     identification, one has to use special firewalls or change the kernel
     behavior (for example, by modifying tcp_input.c in the Linux kernel).
     References:
     http://www.insecure.org/nmap/
     http://www.apostols.org/projectz/queso/

 [14] A network information center provides authoritative administrative
     information about networks that belong to the Internet. Like Domain
     Name Services, it employs a hierarchical structure of NICs, InterNIC
     and ARIN being the highest authoritative source for information about
     domains and networks and information about further network information
     centers that provide information about local networks, such as RIPE,
     APNIC, and country specific sources (like whois.nic.<domain/country code>).
     A WHOIS query can be made using the UNIX tool whois, or simply by
     connecting to a NIC's whois server with a telnet connection to port 43,
     and entering a domain name, word, or network address to inquire about.

 [15] The definition of the last trusted state before a compromise is a
     delicate subject. The most reliable backup is the backup made before the
     system was connected to any network in the first place. Before making
     a backup, one should briefly analyze the system, and perform a checksum
     comparison to ensure the trusted state of the system.

 [16] An easy way to do this with md5 checksums and PGP would be:
     find / -type f -exec md5sum '{}' \; > tmp ; pgpe -r me tmp -o checkfile
     To verify system integrity, you would decrypt the file and check the
     file changes with md5sum -c checkfile.out from a trusted environment.

 [17] Possessing only a small history of security vulnerabilities is solely
     a significant indicator for open-source software that can be audited and
     examined over a long time by a big group of people. While non-open-source
     cannot generally be considered as less secure, cases where only few
     vulnerabilities in such a system have been found yet are less significant,
     because spotting the same vulnerabilities in different software is much
     easier and performed faster if its source code is publicly available.

 [18] Many recent security hazards were a result of vulnerabilities in software
     packages, which got fixed relatively soon after their release, but to which
     many large networks and companies were vulnerable, because they immediately
     installed new versions of operating system and software distributions after
     they had been released. 'Good' examples include vulnerabilities of the
     IMAP/POP mail application suite, Qpopper, recent Solaris 2 vulnerabilities,
     vulnerabilities in RedHat and SlackWare Linux distributions, beta versions
     of ProFTP/wu-ftp servers, KDE/Gnome programs, countless experimental CGI
     scripts and many other cases.

 [19] The method of authenticating access with passwords is a weak and
     theoretically outdated security mechanism, and represents a fundamental
     weakness in today's overall security architecture. Besides buffer
     overflowing and password sniffing, brute force password cracking is one
     of the most efficient and popular intrusion methods, for which many
     local password crackers like John the ripper and session brute forcing
     programs are out. A recently upcoming trend is to use distributed
     technology to defeat even strong passwords; while distributed password
     crackers such as Saltine are already public, in my opinion it is very
     possible that distributed session brute forcing tools have already
     privately been developed and can defeat most password authentication.
     References:
     http://www.false.com/security/john
     http://www.thegrid.net/gravitino
     
 [20] Password aging, which can be enabled in many authentication systems,
     forces the password to expire and a new one to be chosen after a
     specified amount of time. This reduces the risk of passwords being
     brute-forced by front-door login attempts, password file cracking
     or traffic sniffing, all of which takes an intruder a reasonable amount
     of time to be successful. It is of course also required to enforce
     the use of strong passwords to maximize the duration of brute force
     attacks, in which every possible password combination is tried or
     passwords from a wordlist are used to guess a password. This can be
     done by enlarging the systems password dictionary file with bigger
     word lists (it contains all passwords that cannot be chosen), and
     by enforcing stronger criteria (length, mixed case, special characters).
     An approach in which all this can be easily configured are authentication
     systems that employ PAM (Pluggable Authentication Modules).
     References:
     Open Software Foundation RFC 86.0 - Unified Login with Pluggable
                                         Authentication Modules (PAM)

 [21] A quick approach to find common coding flaws is to search for use of
     functions belonging to the strcpy, strcat, sprintf, gets and scanf families
     in the C source code, in order to find possible buffer overflow
     vulnerabilities, as shown by Aleph One. A more detailed analysis means to
     specifically analyze functions which parse user and file input, and doing
     process traces (e.g. to analyze the possibility of race conditions).
     References:
     Aleph One, "Smashing The Stack For Fun And Profit", Phrack Magazine,
     Volume 7, Issue 49, File 14 of 16, 1996, www.phrack.com.

 [22] Real-time event monitoring software often comes with the feature of
     remote management access. Any remote access represents a theoretical
     vulnerability potential and should be avoided, most of all if you need
     a high-security solution involving real-time monitoring. Besides the
     categoric problems, there have been actual weaknesses of remote management
     facilities, for example in older versions of the Checkpoint Firewall-1
     Authentication Agent, which could, if poorly configured, be used to add
     remote authentication access from any host without authorization.
     References:
     "fw1-lpsnoop.pl" - exploit against FW-1 Auth. Agent by acd@weirdness.net

 [23] While remote scanning and auditing tools, which search vulnerabilities in
     a way an intruder would do (i.e. proactively), have been around for some 
     time, they have been gaining popularity since 1994, when it became popular 
     using such methods to improve system security, and they were started being 
     used by an increasing number of people to actually gain unauthorized access.
     A pioneering paper is certainly "Improving the Security of Your Site by
     Breaking Into it", which was developed in parallel to SATAN, one of the first
     publicly used security scanners. This paper also already identified the
     main problem of vulnerability scanning; that new vulnerabilities appear
     frequently and scanners have to be updated to include detection of those
     vulnerabilities. My private humble approach, NSAT, attempts not to scan for
     known holes only, but for the presence and versions of remote services,
     with the aim of producing detailed, vulnerability-independent scan and
     exploit result logfiles that leave a maximum of possibility to evaluate
     them for the user. (Ahem ok, a little, cough, private advertisement here ;)
     There are many other good freeware programs out with databases that are
     being frequently updated with new vulnerabilities, of course...).
     References:
     http://packetstorm.securify.com/docs/hack/security.html
     http://packetstorm.securify.com/UNIX/audit/saint-1.4.1.tar.gz
     http://packetstorm.securify.com/UNIX/scanners/nsat-1.11.tgz
     http://packetstorm.securify.com/UNIX/audit/nessus/nessus-0.99.2.tar.gz

 [24] A definitive guide to protecting confidential data locally is
     "Anonymizing UNIX Systems" written by van Hauser of THC, which describes
     how to reconfigure a Unix operating system to resemble a confidential
     and anonymous source for multi-user information exchange and storage,
     while in my opinion it also exposes that today's operating system
     technology is lacking basic data confidentiality achievement standards.
     References:
     http://www.infowar.co.uk/thc/files/thc/anonymous-unix.html

 [25] To penetrate a networks availability via DoS, almost any compromised
     system is a big advantage for an intruder, who can use the systems
     resources / bandwidth and the anonymity to hide his true origin in an
     attack against you. Therefore, the problem of Internet security has
     to be seen in a bigger context; the security infrastructure of all
     systems has to be improved to effectively protect single systems.

 [26] A popular application-/system-based DoS attack, the SYN flood, consists
     of sending spoofed packets representing tcp connection attempts,
     resulting in filled up tcp connection tables and unresponsive tcp
     services due to many half-completed connections at the victim's site. The
     cryptographic challenge protocol known as SYN cookies authenticates real
     connection attempts, dropping spoofed packets from sources that
     remain unauthenticated for a certain amount of time.

 [27] There exists a technique called firewalking, named after the
     auditing tool by Mike Schiffman, that can reliably predict which protocols
     will pass a point behind a filtering gateway, and which tcp/udp ports on
     firewalled systems are open, by sending tcp or udp packets with a IP TTL
     value that causes the packets to expire just before they reach their final
     destination, thus sending back an ICMP_TIME_EXCEEDED reply to the
     firewalking source host. Therefore it is recommended to prevent emanation
     of these ICMP messages to external networks.
     References:
     http://www.packetfactory.net/firewalk

 [28] Simple Network Management Protocol is a universal protocol that can be
     used to record various information and statistics about network
     configuration and traffic. It can, for example, assist in detecting sources
     of high traffic coming from or to your network. However, by default, SNMP
     is using no password authentication, and UDP sessions, which can easily be
     spoofed. A MIB (Management Information Base) can contain sensitive
     information and remote access to routing interfaces, connection tables,
     plaintext passwords, administrative info, system configuration, and even
     remote command execution, all of which can be compromised. Using the most
     secure configuration available must therefore be mandatory, i.e. SNMPv2
     with password protection, no default MIB names, no remotely writable MIBs,
     strong passwords, and filtering of traffic to SNMP facilities. There are
     also free auditing / brute forcing tools out which can be used to secure
     (or compromise) SNMP servers, like snmpwalk(1) (which has become a
     common unix system command on many systems), and the snmp scanning and
     wordlist brute forcing tool by ADM.
     References:
     ftp://adm.freelsd.net/pub/ADM/ADMsnmp.0.1.tar.gz

 [29] TCP interception is a feature introduced by Cisco routers, but possibly
     present on products from other vendors which can be used to mitigate
     the impact of TCP SYN flooding attacks. A router that uses this feature
     will act as a proxy, responding to a remotely initiated tcp connection
     attempt in the first place, and only relaying it to the actual hosts when
     it has been established. By utilizing the bigger connection tables routers
     have at their disposal, and allowing minimal connection timeout values,
     the tcp interception feature can, if properly configured, help to
     withstand moderate SYN floods.
     References:
     http://www.cisco.com/univercd/cc/td/doc/product/software\
     /ios113ed/113ed_cr/secur_c/scprt3/scdenial.htm

 [30] For high availability it is advisable to block tcp/udp ports of services
     which should not or do not need to be available to the rest of the
     Internet, because they could be penetrated from external hosts, harming
     internal network availability, or specific services could be used to
     multiply an attackers bandwidth, e.g. if a connectionless service replies
     with a larger amount of data than is needed for the initial service
     request. An example DoS can be commenced using forged bind queries (but
     note that the external DNS, i.e. the nameserver authoritative for your
     domain must be available from the whole Internet!). 

 [31] Patterns that can indicate DoS attacks include unusually high amounts
     of packets of any protocol, but most of all ICMP (because DoS often
     generates ICMP error messages or echo replies). Further patterns include
     many tcp or udp packets with sequentially incrementing or decrementing
     destination ports, or destination ports that appear to be unused or random,
     and icmp/udp traffic coming from sites that don't block directed broadcast
     traffic, which is detectable by searching for incoming packets that seem
     to come from different hosts on the same subnet, or by comparing suspicious
     IP addresses with public known-broadcast databases from projects which
     periodically scan the complete Internet broadcast address range (see
     references below) or probing the sources' IP broadcast addresses for
     multiple replies from different hosts (seen as DUP's if using ping(8)).
     References:
     http://www.netscan.org
     http://users.quadrunner.com/chuegen/smurf.cgi
     http://www.powertech.no/smurf

 [32] The figure below shows how a DoS attack commenced by a distributed attack
     tool (floodnet) would need to be traced back. This particular trace
     would require coordination with at least two other networks, on which
     the distributed software is installed, and all backbone providers
     responsible for routers between the attack victim and one of the flood
     daemons, and the backbone providers responsible for the routers between
     the flood daemon and the master server or controlling client, if the
     distributed tool would employ forged IP addresses in its client/server
     communication process.
     (Note: I know that my ascii drawing style sucks, my apologies :)

     [ Attack Victim ] <---- Incoming packets with spoofed IP source address
             |                            ^^^
             |                            ^^^ sending out DoS packets
             \-- hop-by-hop trace --> [ Flood daemon ]
                                     |           ^^^  client/server traffic,
                                     |           ^^^  possibly also spoofed
                                     \-- trace -> [ Master control server ]
                                                        |
                                                        | By watching outgoing
     Fig. 1: Tracing Flood Network attacks from         \ traffic, or examining
             the perspective of a victim         files on the server, the other
             of a distributed DoS attack         flood daemons can now be found

 [33] Recently, there have been reported incidents that NIC's were tricked
     via mail spoofing to change DNS authority records. Once this was done,
     attackers used their own, now authoritative DNS records to point domain
     names to different IP addresses, hijacking site traffic. A popular method
     of social engineering is also to create and post PGP keys or certificates
     carrying the same or a similar name as an authoritative institution, then
     using them for spreading trojans or whatever from 'trusted' sources. As it
     shows, services using hierarchical structured authorities inside the
     decentralized Internet are quite susceptible to such attacks.

 [34] Another structural problem is that resources of hosts lacking security can
     be used by attackers to penetrate other, secure hosts and networks that
     have nothing to do with the insecure ones. Multiplying attack potential
     through insecure systems for DoS purposes has its own history, starting
     with forged connections between udp services (chargen, echo, etc.), smurf
     attacks, compromising systems to scan or flood other systems, and lately
     distributed DoS, and exploiting, for example, DNS service or the MacOS9
     protocol stack to multiply bandwidth, using hosts completely unrelated
     to a victims site to penetrate it.

 [35] Since being developed and discovered in 1983, computer viruses and
     worms have been propagating in executable files, boot sector code,
     ansi characters, system libraries, interpreted scripts, vulnerability
     bulk scanning and exploiting packages, news groups, web documents and
     scripts, document macros and interpreted html code. They've been using
     everything from basic machine code instructions to script and system API
     functions to operate, and there are several thousand different viruses,
     which all use slightly different techniques to operate. All completely 
     new virus code being invented has its own, new and unique pattern.
     As shown by the theorem of Dr. Fred B. Cohen, due to the nature of
     viruses, virus detection can never be reliable, as the occurrence of false
     positives and false negatives can never be completely eliminated.
     References:
     "A Short Course on Computer Viruses",
     Dr. Fred B. Cohen, ASP Press, 1990

 [36] There are already numerous different approaches to bypassing today's
     NIDS software, and I am sure that their number will increase further as
     intrusion detection gains more popularity. You might say that making use
     of these techniques is hard and requires technical knowledge and skill,
     however it is no problem to code intrusion software that employs these
     techniques in a sophisticated manner and makes them available to everyone
     using an easy program interface. Evasion tactics include using requests
     which are rfc compliant, but seldom to never used to get the same
     intrusion or scanning results (i.e. requests that are supported by servers
     but not used by most clients). Also, using non-rfc compliant, but silently
     supported requests that differ from normal sessions, or exploiting server
     bugs which make them accept non-compliant behavior can be used to fool ID
     systems; basically anything that uses different commands or data encoding
     has a high chance of being a pattern that works to accomplish the original
     server communication but is not being scanned for by many IDS. As IDS need
     to be optimized to parse much traffic, overloading an IDS with bogus
     connections can also distract its attention from you; moreover, it can even
     act as a network wide Denial Of Service, if a NIDS is required to process
     all traffic before it is forwarded. Another method with many possibilities
     is to use transmission protocol capabilities and options that are normally
     not encountered in normal sessions. Capabilities unexpected by IDS are
     IP fragmentation, TCP segmentation, IP and other protocol extra options,
     and traffic that looks invalid to the IDS but will be processed by the
     protocol stack and applications without causing sessions to end, for
     example fake SYN/FIN packets, TTL values, sequence numbers, overlapping tcp
     segments, and sending tcp packets which contain each only partial requests.
     References:
     "A look at whisker's anti-IDS tactics", rfp, http://www.wiretrip.net/rfp/
     horizon, "Defeating Sniffers and Intrusion Detection Systems",
     Phrack Magazine, Volume 8, Issue 54 Dec 25th, 1998, article 10 of 12

 [37] Assume you are establishing network intrusion detection to protect an
     ISPs NOC hosts, being on the same class C subnet as dialup hosts. Nowadays,
     BO and other windows backdoor scans, or netbios sweeps are occurring very
     frequently on most dialup host subnets. However, if you run something like
     OpenBSD with high security, and now get hundreds of alarms that you are
     being scanned for windows holes (false positives), it distracts your
     attention from real problems. Keep in mind that not everyone has the time
     to find out how serious a particular intrusion attempt has to be taken
     (there are already thousands that most IDS scan for). Additionally, IDS
     logs should be kept small because they are generally checked on a daily
     basis if not more frequently. Therefore, my advice is to perform a system
     audit and only activate IDS alarms for attacks against services or
     protocols that you really use and especially ones that could be security
     critical. That way, you know that something serious might be going on
     when you are actually getting IDS alerts.

 [38] Scanning for timestamp changes can indicate many of the intrusions that
     involve accessing (reading or listing) and modifying your trusted system
     data. Scanning for access/modification time and permission changes is easily
     done with the find(1) command, or using script languages like Perl or Tcl,
     which feature many functions for file examining and scanning. This tactic
     is even popular among intruders, who use this to detect activity by legit
     users or other intruders active on the same host. While this narrows down
     the possibilities of undetected activity, timestamps can be changed
     arbitrarily or copied from other files timestamps by anyone having write
     access to the file via touch(1) command or using the utime(2) function.
     References:
     http://mixter.void.ru/suspend.c

 [39] Remote access backdoors do not necessarily have to use established network
     connections or open ports. As any technology advances, so does intrusion
     software. Backdoors can be listening on raw sockets, waiting for packets
     that match magic values, or that only make sense if decrypted with a secret
     pass phrase. Some example backdoors are ICMP tunneling backdoors, which
     have been around for some time, kernel module backdoors that can grant
     remote interactive or non-interactive access when receiving magic values
     in IP packets, or backdoors that listen to traffic on data link or raw
     protocol level. Examples of a remote access backdoor and a sniffer written
     by me, both featuring remote access on decrypted magic values, traffic
     encryption, and random communication protocols are Q, an on-demand
     shell daemon and e4d, a distributed sniffer.
     References:
     http://mixter.void.ru/Q-0.9.tgz
     http://mixter.void.ru/e4d.tgz

 [40] Thinking like a hacker includes questioning concepts, especially
     technological ones, and examine them in detail rather than just acquiring
     and using them. Note the difference between individuals I use to refer as
     intruders or attackers, who are in fact penetrating system security and
     might be using their hacker ambitions which help them in accomplishing
     this, or just could be using intrusion methods and software which almost
     everyone could use. Educating users, employees and administrators to think
     and solve problems this way would be greatly beneficial to security, as
     many security problems and incidents which nowadays have to be worked
     against using extensive coordinated time and money resources, could be
     prevented and resolved individually if people were taught how to acquire
     appropriate technical background knowledge themselves.

 [41] Law enforcement, when dealing with computer crime, is especially
     inefficient because it can be hard or even impossible to track an intruder.
     Intruders can strike from any country in which they are possibly safe from
     foreign law enforcement, and sophisticated intruders can and will cover
     their identity by traversing through compromised machines or manipulating
     phone networks. Additionally, active intruders seem to be very little
     afraid of being caught and possible consequences they would be facing, even
     when not being able to efficiently cover their tracks, as shown in the
     statements in the article by YTCracker, who is actively attacking systems.
     References:
     http://www.hackernews.com/bufferoverflow/99/yesitis.html

 [42] A growing amount of mis- and overreactions to scanning and probes is a
     doomed strategy that actually leads to security through obscurity. If
     anyone performing extensive network connections to acquire information
     about a system has to watch out for consequences, network security will
     no longer be transparent. This is an advantage to intruders, who can
     utilize previously compromised machines to hide their origin, but a big
     disadvantage to individuals who care about the security of systems. For
     example, I routinely examine servers before I do electronic financial
     transactions over them, to ensure that my information is safe from
     manipulations or eavesdropping. There have also been interesting scanning
     projects, which helped to discover and fix vulnerabilities, such as
     broadcast scanning (see [13]) or the Internet Auditing Project using
     BASS. Such beneficial projects are increasingly harder to perform using
     legit resources without having to think about possible consequences.
     References:
     http://www.securityfocus.com/data/tools/network/bass-1.0.7.tar.gz

 [43] Facilities whose protection is critical include file system attributes
     such as immutable or append-only which are used to protect trusted
     system binaries and audit trails from manipulations, as well as access
     to network interface capabilities and other special devices and resources
     like hard drives, read/write access to kernel memory, functions and
     control facilities, which all could, if accessed at low level with
     user or root privileges, be used to harm system security or stability.

 [44] A general technical approach to establishing separation of user level
     privileges could be realized by a kernel performing verification of current
     access permissions as part of the built-in system calls, or a system in
     which the kernel checks the called function with parameters and the
     mandatory privileges of the calling process each time a process hands
     execution control to the kernel via interrupt with the request of calling
     a system function that can be managed using access control.

 [45] Cryptographic challenge protocols can greatly improve authorization
     and confidentiality aspects of sessions. A challenge function such as
     Kerberos would consist of a client request which transmits an encrypted
     magic value to an authentication service. The authentication service then
     responds with a message digest (generated by a cryptographic one-way hash
     function) which contains the unique session identifier (or one-time
     password) and the magic value. The client then adds a secret known by the
     server and generates another digest which is sent to the actual server to
     establish a session. If both the unique session identifier and the secret
     match, the client is authenticated. In similar ways, a session encryption
     can be securely obtained over untrusted network links without having to
     be transmitted in plaintext and a secure session can be established.

 [46] The current standard unix permissions consist of user and group
     ownership identification, read, write and execution privileges separated
     for owners, group members and others, and suid/sgid flags which instruct
     the kernel to initially start a program with its owners effective user
     or group identification and the related permissions. File system attributes
     which can only set by the super user at a low secure level include file
     immutable and append only prevention.
     The POSIX file system privileges, which are proposed standard for the
     ext3 file system, already implement permission bits that assign
     privileges to do special networking operations (binding to privileged
     ports, opening raw sockets, accessing special files, etc.) to the process
     which is executed from a properly flagged binary.

 [47] Intruders commonly structure their activity into different phases, and
     it is also often unavoidable for them to do so. For example, attackers
     first have to gain information about their targets by using dns zone
     transfers, ping sweeps, or connections to their services, then examining
     the versions and configurations of running servers and as the next step
     launch exploit attempts. While the first steps an attacker performs are
     legit network traffic which constitute no intrusion, they should be
     recognized by heuristic intrusion detection to flag further traffic from
     the same hosts to be monitored with increased attention.

 [48] Vulnerability scans and compromises have been performed by intruders
     with distributed methods for a long time, while the actual use of
     distributed attack and intrusion software seems to be gaining popularity
     only recently. Intruders operate within a circular scheme; they first scan
     a host, then compromise it. Next, they install intrusion tools to hide
     themselves and commence further scans from their victims. The intruders
     use compromised resources at their disposal to perform further scans,
     sniffing attacks, and remote compromises from there. The more machines an
     intruder compromises, the larger is the amount of resources he can use for
     distributing scanning and compromising tasks amongst different computers,
     enabling him to seize control of more resources and so on.

 [49] Misconfigurations, which are in this case represented by static routes
     which propagate reachability of certain networks through one gateway, but
     are unable to actually deliver the traffic reliably, can act as the cause
     of major network congestion. Additionally, attackers can take advantage
     of static routes which are less error tolerant by attacking gateways which
     are configured to be accountable for a big amount of traffic. Therefore,
     routers in general should be less error tolerant when it comes to
     misconfigured and unreliable static routes, as mentioned in RFC 2725,
     which consists of valuable information to improve routing security. It
     should also be considered to develop advanced, open interfaces between
     routers, so that they can remotely exchange information and policies to
     determine if a route is allowed or appreciated by a remote Autonomous
     System instead of routing statically and blindly without being able to
     reliably predict if the traffic will ever reach its destination.
     References:
     RFC 2725 - Routing Policy System Security

 [50] Migration from old to new protocol standards with improved security,
     such as IPv6, will be done in partial steps, and networks based on
     protocol standards with improved security features will therefore
     require to be downward compatible until the migration is completed,
     in order to be accessible by the rest of the Internet. Until this
     compatibility is given, the possibility is left for attackers to
     use old protocol versions to operate in networks with improved
     security protocols in a way that they can still hide their origin.

 [51] The Internet Protocol version 4 only reserves 32 bit for address storage.
     This has lead to network address space tending to become rare, and
     the establishment of some well-constructed, but temporary solutions,
     for example Network Address Translation and Classless Inter-Domain Routing
     (CIDR). CIDR employs a tactic that disregards the traditional separation
     into network classes, making it possible to assign addresses to networks
     with arbitrary amounts of hosts. However, CIDR concepts have drastically
     affected the complexity of routing methods, and have caused some
     confusion where they were applied improperly. Despite their usefulness,
     such concepts have also weakened formerly coherent Internet structures.
     For example, Routing Information Protocol version I, which is still the
     most commonly deployed routing protocol, has not been designed to be
     compliant with CIDR. The introduction of this concept therefore
     made it necessary for many routers to employ new methods, or just use
     static routes, which can represent structural weaknesses [49].
     References:
     RFC 1519 - Classless Inter-Domain Routing (CIDR):
                An Address Assignment and Aggregation Strategy

 [52] As described by the concerning RFC, and already implemented in
     existing solutions, IPSEC capabilities can be established either in form
     of "Bump-in-the-stack" implementations, which are inserted at network
     driver level, and transparently convert locally used traditional IPv4
     traffic and traffic with IPSEC features deployed on the network.
     Another method is the use of the "Bump-in-the-wire" implementation, 
     which employs similar transparent traffic conversion techniques at the
     network interface by using dedicated cryptographic processor hardware.
     Using the latter, it is also possible to establish traffic conversion
     at the network border, by using a security gateway to verify and convert
     IPSEC traffic to plain IPv4 before passing it to internal hosts, and
     transparently converting outgoing traffic to IPSEC, making it possible
     for hosts on the local network to continue using traditional IPv4.
     References:
     RFC 2401 - Security Architecture for the Internet Protocol

 [53] Certification Authorities are a concept meant to generate a
     hierarchical set of institutions which issue and authenticate public
     keys. Each CA's authority and trust is verified by a higher CA,
     leading to a structure of a Root CA and different lower authority
     layers of Trust Centers, which register and assign public keys. The
     have been problems of cooperation and administration that are presently
     complicating the introduction of this concept, and the trustworthiness
     and security of Certification Authorities are further issues. It should
     be considered to establish a PKI concept without the inevitable necessity
     of a working CA hierarchy, as the secure implementation of centralized
     structures generally stands in conflict with the decentralized nature
     of the Internet and is therefore hard to realize.
     References:
     RFC 2407 - The Internet IP Security Domain of Interpretation for ISAKMP
     RFC 2408 - Internet Security Association and Key Management Protocol
     RFC 2409 - The Internet Key Exchange (IKE)

 [54] Using cryptographic authorization, association of public keys with IP
     addresses would be more secure than the association of hostnames with
     addresses currently is. The present DNS protocol is susceptible to
     spoofing and insertion attacks, which could however be eliminated in next
     generation DNS, using cryptography and high level authority public keys
     for name servers to reliably verify the origin of each other. The DNS
     protocol could then easily be enhanced by new DNS record types to request
     public key and key ID transmission, as it was proposed in RFC 2539.
     References:
     RFC 2535 - Domain Name System Security Extensions
     RFC 2539 - Storage of Diffie-Hellman Keys in the
                Domain Name System (DNS)

 [55] For example, the International Standards Organization (ISO) had
     recently decided not to standardize cryptographic algorithms for security
     software and networking applications. Such decisions can throw back
     technological efforts which depend on a certain standard being
     developed. In such situations, developers should consider not to
     rely on certain standard organizations, but work together with other
     leaders in the industry to develop and deploy their own, self-approved
     standards. Additionally, all developers are generally welcome to issue
     RFC (Requests For Comments), a method, from which the Internet community
     is always going to benefit, and which should be used by everyone when new
     standards are necessary or desirable, but have not yet been formulated.