George Wilson Khaukha. Die Discorsi: 1. Innere Politik by Andre Budke. It's Over! Is It? Rosie Kuhn. Betsy Ross. Colorimetria: sistema di colore Carlieri-Bianco by Maria Bianco. Sophie Ortega. There are numerous alternatives for authentication, such as one-time passwords e. There are also various options for storing authentication information.
Since Telnet does not use any encryption mechanisms, the entire session including the exchange of authentication credentials can easily be intercepted.
On mallet start the password sniffer dsniff. Using the option -m enables automatic detection of protocols and -i defines the interface the sniffer should listen to.
Connected to bob. You have mail. This circumvents the risk incurred by entering a password, which could be intercepted by an adversary. Authentication is only based on the user name and the corresponding IP address. Rsh also suffers from security vulnerabilities. Any password transmitted is sent in the clear. Moreover, its IP address-based authentication can be exploited by IP address spoofing where the adversary fabricates IP datagrams containing a fake source IP address. Finally, after login all subsequent information is also sent in the clear and is not authenticated.
Problem 4. What is a fundamental argument against authentication based on MAC addresses in most network settings? It solves many of the security-related problems of rsh and Telnet.
Since SSH encrypts all communication, it provides secure connections that are resistant against interception and it offers protection against message manipulation as well. Note that in debug mode only one connection can be established and sshd quits immediately after the connection is closed. By default, the debug information is written to the standard error output.
In order to analyze the specific steps, we redirect the error output to the standard output first and then pipe the standard output to the command less. You can use tcpdump or Wireshark on mallet to convince yourself that no plaintext information is sent. Most users apply SSH as just described, using a user name and password. But SSH also offers the option to remotely log in without entering a password.
Instead of the IP address-based authentication of rsh, public key cryptography may be used. When carrying out the following experiments, it may help to also read the corresponding manual pages of sshd, ssh and ssh-keygen. In order to preserve the comfort of rsh, we abandon the option of using a passphrase -N "" , i. Your identification has been saved in alice-key. Your public key has been saved in alice-key. Instead of comparing string representations of fingerprints, images can be compared.
The authentication is based on the knowledge of the private key. SSH has numerous options. For example, you can restrict clients to executing predefined commands only, and you can deactivate unnecessary SSH features such as port forwarding or agent forwarding. As an example, the following restricts Alice to executing the command ls -al on bob. For these kinds of tasks, the no-pty option is recommended, which prevents allocating a pseudo terminal.
The execution of interactive full-screen programs is also prevented e. What is the main threat that still remains? In order to improve the security of a system, private keys should only be stored in encrypted form. However, it can be annoying to re-enter the passphrase repeatedly. For such situations, OpenSSH provides a program named ssh-agent. When using it, the passphrase must be entered only once per login session and key, i. To add an identity, you simply use the ssh-add command.
You can repeat the above steps and generate a new key pair e. Every time you use the newly generated identity to access bob, you are requested to enter the passphrase. Try it! Try it out and afterwards log out alice from alice. Now you will be asked to enter the passphrase for the key again every time you access the key. For every file, the permissions to read, write, execute or any combination thereof, are individually defined for the three classes of users: user, group and others.
We will see additional concepts later, but even this simple model suffices for most practical problems and it is both easy to understand and administrate.
What is their meaning for directories? Find the answers through experimentation! Just prepend sudo to the above command. Also replace with the path to the actual directory you want searched. Which files or directories might not be configured properly?
Which permissions could be more restrictive? When creating new objects in the file system, the default permissions are important.
Although default file permissions depend on the program that creates the new object, the permissions are commonly set to for files and to for directories. The user can influence the default file permissions for newly created files by defining a corresponding user mask umask value.
This value can be set with the umask command. Incorrectly set user masks may result in newly created files to be readable or even writable for other users.
Why is this a good default? Note that not all Unix-like systems behave in this way. Some systems inherit the group from the parent directory. Hint: The invocation order is described in the manual page of bash. This is because these operations do not change the file itself but only entries in directories.
This is not a problem in most cases. However in a shared temporary directory, this can be a serious problem since every user is allowed to manipulate arbitrary files in the directory. The problem can be solved using the sticky bit, which ensures that only the owner of a file or root can rename or delete a file. Even more fine-grained permissions and restrictions are possible using file attributes.
Provide an example where it would make sense to use each of these attributes. Note that after removing the access bit of a directory e. By just removing the read bit of a directory e. Now change the user to bob su bob and try to read the file: 4. Is this variant also prone to potential security problems? If so, what are these problems? Within the kernel, user names and group names are represented by unique non-negative numbers. Note that some Linux distributions do not use UPGs but instead assign new users to a systemwide default group such as staff or users.
The Linux kernel assigns to every process a set of IDs. We distinguish between the effective, real and saved user ID the situation is analogous for group IDs and we omit their discussion. The real user ID coincides with the user ID of the creator of the respective process. Instead of the real user ID, the effective user ID is used to verify the permissions of the process when executing system calls such as accessing files.
Usually, real and effective IDs are identical, but in some situations they differ. This is used to raise the privileges of a process temporarily.
If the setuid bit is set, the saved user ID of the process is set to the owner of the executable binary, otherwise to the real user ID. The real user ID still refers to the user who invoked the program. Example 4. Since this binary is owned by root, the saved user ID of the respective process is set to 0 and the effective user ID is therefore also set to 0 whenever a user executes passwd.
Since the real user ID still refers to the user, the program can determine which password in the file the user may alter. For example, if user bob with user ID 17 executes the command passwd, the new process is first assigned the following user IDs: real user ID: 17 saved user ID: 0 effective user ID: 17 The program passwd then invokes the system call seteuid 0 to set the effective user ID to 0. Because the saved user ID is indeed 0, the kernel accepts the call and sets the effective user ID accordingly: real user ID: 17 saved user ID: 0 effective user ID: 0 Commands like su, sudo and many others also employ the setuid concept and allow an ordinary user to execute specific commands as root or any other user.
Setuid programs are often classified as potential security risks because they enable privilege escalation. If the setuid bit of a program owned by root is set, then an exploit can be used by an ordinary user to run commands as root. This might be done by exploiting a vulnerability in the implementation, such as a buffer overflow. However, when used properly, setuid programs can actually reduce security risks.
Note that for security reasons, the setuid bit of shell scripts is ignored by the kernel on most Linux systems. One reason is a race condition inherent to the way shebang! When a shell script is executed, the kernel opens the executable script that starts with a shebang. Next, after reading the shebang, the kernel closes the script and executes the corresponding interpreter defined after the shebang, with the path to the script added to the argument list.
Now imagine that setuid scripts were allowed. Then an adversary could first create a symbolic link to an existing setuid script, execute it, and change the link right after the kernel opened the setuid script but before the interpreter opens it. An adversary could now proceed as follows to run his own evilScript.
Since nice alters the scheduling priority to the lowest possible, the fourth command is likely to be executed before the interpreter opens temp. Hence, evilScript. How could an ordinary user be given the ability to change his own password without a setuid program?
Note that instead of setuid, setgid can be used in many cases. Setgid is generally less dangerous than setuid. The reason is that groups typically have fewer permissions than owners. For example, a group cannot be assigned the permission to change access permissions. Could the setuid programs in the last problem be setgid instead of setuid?
However, as with programs written in other programming languages, shell scripts may contain security vulnerabilities. Therefore shell scripts must be designed, implemented and documented carefully, taking into account secure programming techniques as well as proper error handling.
We already discussed security flaws related to file system permissions. Furthermore, we pointed out that on modern Linux systems the kernel ignores the setuid and setgid bit of shell scripts by default.
Therefore, some administrators run their shell scripts with root permissions to ensure that all commands used in the script have the permissions they require.
In doing so, they give the script too many permissions, thereby contradicting the principle of least privilege. In this section we introduce some common pitfalls, possible attacks and ways to prevent them. Background on shells is given in Appendix C.
The following example shows how an adversary may abuse symbolic links to undermine system integrity. Because of other operations, designated in the script by Finally, execute the above shell script with root permissions. To prevent such attacks, a script should check for symbolic links before using a file and take appropriate actions such as exiting the script. In the attack in Sect. What is this command primarily used for? Many modern Linux systems provide the command mktemp for safely creating temporary files.
Implement what you have learned so far to create the temporary file. The script now looks as follows:! XXX echo "This is the log entry. What can the adversary still do? In general you should not trust externally provided inputs, and this is also the case when users can make their own assignments to these variables. Users may maliciously choose inputs that change the behavior of your script. We saw an example of this in Problem 4. Explain what an adversary could do when using relative paths.
To make your scripts robust against maliciously configured environment variables you may overwrite them at the start of the script. For example, you can define the paths for system binaries as follows:! This prevents the adversary from injecting unintended input. Think carefully about what your script will consume and what you want it to produce.
This time, the script reads a password provided by the user. If the user enters the correct password, the script prints a secret to the command line. Another good practice is to sanitize the input by removing undesired characters. In the following example, only alphanumeric characters are accepted and all other characters are removed. See the manual page of the command tr for more information.
However, there are still good reasons to subdivide disk space into multiple smaller partitions. Often quotas are defined for system users in order to prevent them from filling a partition or even an entire disk.
What kinds of limits can you set? What is the difference between a soft limit and a hard limit? In most settings, users are restricted in how much disk space they can write.
Such a setting nevertheless allows an adversary to exhaust space in a world writable directory without debiting his block quota at all. Under some circumstances, the adversary would be able to fill an entire partition despite existing quotas. The following example shows you how this could work.
For the example to work, switch the user on alice to bob su bob. What can the adversary accomplish with such an attack? How can this problem be solved? Whenever possible, world writable directories should be moved to a partition separate from the operating system. For a system-wide temporary directory, a RAM disk could be used. In order to jail a process in a new root directory, we will have to provide all the necessary commands we want the process to be able to execute within this chroot environment.
As an example, we will execute the simple script chroot-test. Note that in this section the term root does not refer to the superuser root but to the root node of the file system. Then make it executable and execute it. Hence, we will have to provide the binaries and necessary libraries for bash and ls in the new environment.
We therefore first create a bin and a lib directory and then copy all the necessary files. Since we also copied bash and its dependencies, you can also execute an interactive shell in the jail and try to escape. We will now apply this mechanism to the remote access on alice. OpenSSH offers the opportunity to jail the users that are logging in remotely by restricting the files and directories that they may access.
We will use the change root environment built above. Note that you need to be root to execute the next command. You could use this mechanism to build more complicated environments. Then, analogously to the above, you could create different environments for every user and thus restrict them to specific sets of allowed commands within their own home directories. What difficulties do you expect in terms of the administration and the operation of such environments? Note that whenever an adversary gains superuser access within a chroot environment, there are different possibilities to escape from the jail.
One is based on the fact that not all file descriptors are closed when calling chroot. A simple C program 66 4 Authentication and Access Control could be written that exploits this fact. More restrictive solutions than chroot exist, such as virtualization. However, chroot offers a simple and straightforward way to restrict processes and their abilities. In each of these cases, what are the respective subjects and objects i.
What kinds of authorization policies are typically enforced by the access control mechanism? Question 4. Explain two of these. Briefly explain these attributes. Name two such attributes and a security application for each of them. A description of such an attack is given below. The setting is depicted in Fig.
Explain how the adversary can use the technique described in the attack to access a server behind the firewall. That is, describe the chain of events that leads to information being transmitted from the internal possibly secret server to the adversary.
Describe two countermeasures that could prevent such an attack. These countermeasures should not be overly restrictive. For example, closing the firewall for all connections to the Internet would not be an option.
Therefore, adversary Charlie registers a domain name, like attacker. As the authoritative name server for this domain, he registers his own name server. If somebody wants to access the domain attacker. This value determines how long a domain name IP address pair is cached before the authoritative name server is contacted again to resolve the name.
The adversary now provides visiting clients a malicious JavaScript e. Since the TTL of attacker. These events are reported as entries in log files. The objective of logging is to make these events transparent and comprehensible. The log files can be used to analyze and optimize services as well as to detect and diagnose security breaches. Many logging mechanisms are not configured optimally in practice. Important messages go undetected because of the large number of log entries that are triggered by irrelevant events.
Users and administrators often do not even know where to search for specific log files and how to configure the associated logging mechanisms. There are a number of tools available that support administrators with the task of keeping track of log files. Particularly important are tools that analyze the log files. These files often contain many entries which on their own are meaningless or simply not relevant to security.
It is necessary to correlate and filter these entries in order to summarize events and detect suspicious or even dangerous incidents. Furthermore, tools exist that automatically raise an alarm or initiate countermeasures when there is evidence that malicious activities are taking place. Furthermore, you will be able to explain why logging is important, in what situations a deeper analysis of log data can help, and which problems arise with logging and log analysis.
In particular, you will be able to explain how the integrity of log data can be compromised and to what extent log information really reflects the actual status of a system. Finally, you will be able to plan and implement mechanisms to analyze log information for a specific system.
These programs need other options for sending messages to users or system administrators. This enables the administrator to divert the output into one or more log files. Write to file: Many programs write their messages directly to one or more log files.
Syslogd: Many programs route their messages to a central program called syslogd, which writes the received messages to different log files according to predefined rules.
This makes it possible to collect related messages from different programs in a single log file, e. This in turn makes it easier for administrators to correlate and analyze the relevant information.
In addition, syslogd offers the option of sending log messages over a network to other machines, so that log information from multiple machines can be collected centrally. In the following, we will examine rsyslogd reliable and extended syslogd.
One reason is that there is a strict separation between the code and data in kernel space and that in user space. Therefore, kernel messages must be handled differently.
Usually, klogd then uses the syslog API to dispatch the log messages. The program dmesg is used to display the contents of the kernel ring buffer. Problem 5. In particular, when should rsyslogd be avoided? In addition to program-specific log files, there are also system-wide ones which centrally collect messages from different programs.
Therefore, there are associated tools for viewing their contents, such as who 1 , last 1 and lastlog 8. To do so, you must first derive the process ID of rsyslogd. Briefly explain the logging mechanisms and why they are applied.
Which programs use them? Use the manual page of rsyslog. In particular, restrictive access authorization or specific file attributes such as append only are typically used to provide protection against ordinary users without root privileges. However, whenever an adversary gains root access, such methods can be circumvented. To begin with, rsyslogd does not authenticate users.
Shutdown immediately 5. The message created above is indistinguishable from a real message, created by the kernel itself. Even binary files like wtmp can be manipulated using a simple C-program, when the adversary obtains root access.
Undesirable entries can be removed or altered arbitrarily. These are weaker notions that only require manipulations to be detectable. A remote centralized log server has several advantages, which we have already described.
In the following, consider how such a log server can be compromised and what countermeasures can be taken. Be creative in your solution! Such a string might, for example, be the result of an error message generated by a system call. However, it might also originate from user input, such as a user name entered in a login procedure.
The processing of log messages, for example, using log analysis tools, thus requires input validation to prevent potential problems such as buffer overflows or code injection. When this is done, the files are created afresh after a predefined period of time or when a specific size is reached. Files rotated out are usually associated with the current date and are deleted or archived at regular intervals.
Find the configuration file for logrotate on alice and change it so that all log files are compressed after rotation. Before you do this, create a snapshot of the virtual machine and switch back to the snapshot after the experiment in order to have non-empty log files for the log data analysis that will follow later in this chapter. Typically the monitored activities are reported to a management system that correlates information from multiple monitors. Intrusion detection systems may additionally be extended with intrusion prevention systems IPS , which take countermeasures when suspicious activities are reported.
In this section we will focus only on IDSs. A distinction is commonly made between host-based and network-based IDSs. Host-based systems run directly on the monitored machine and can analyze relevant information on the machine such as log files, network traffic and process information.
Network-based systems run on dedicated hosts and are often integrated into a network as probes. Such systems overhear network communication but do not communicate on the network themselves and are therefore difficult to attack.
It is very readable and well organized, and the questions and exercises are generally very good. It is an excellent introduction to the subject and would make a good upper-level undergraduate text. It would also be quite useful as a self-study text for someone new to the field. With the new versions of VirtualBox it is now possible to export all necessary configurations.
For your convenience, first try to simply import the appliances below. If this fails, you may follow the installation and configuration instructions using the virtual disks as described in the book. Do not reassign new hardware MAC-addresses! In this section we provide some links to extensions of the lab environment and the book in different topics.
The experiments highlight key information security problems that arise in modern operating systems, networks, and web applications. The authors explain how to identify and exploit such problems and they show different countermeasures and their implementation. The reader thus gains a detailed understanding of how vulnerabilities arise and practical experience tackling them.
After presenting the basics of security principles, virtual environments, and network services, the authors explain the core security principles of authentication and access control, logging and log analysis, web application security, certificates and public-key cryptography, and risk management. The book concludes with appendices on the design of related courses, report templates, and the basics of Linux as needed for the assignments. The book can be used in undergraduate or graduate laboratory courses, complementing more theoretically oriented courses, and it can also be used for self-study by IT professionals who want hands-on experience in applied information security.
The authors' supporting software is freely available online and the text is supported throughout with exercises. It is very much a workbook, with numerous in-line problems to work on and a nice set of questions and exercises for each chapter; answers appear in an appendix.
Many of the exercises involve using specific software to look at events as they occur.
0コメント