POSIX Permissions and Stateful Firewalls Solution

Introduction




You are Wilbar Memboob, the Security Administrator of FrobozzCo ("You name it, we make it"). You are looking to hire a new system administrator to replace the guy you just fired -- unfortunately, even though his resume looked great on paper and he interviewed well, once you put him at a console he clearly had no idea what he was doing.







To him, proper permissions meant that the application worked; if it was secure then that was just icing on the cake. You should have done something when the other admins starting calling him "Triple-7" -- a.k.a. "wide open". But it was when he changed the company fileserver directory permissions to "ugo+rwx" and the projected budget was "released" early -- including a list of the employees being laid off -- that he signed his own pink slip.




To keep this from happening again, you've created a little test for your new applicants to take. Unfortunately, before you can grade the applicants, you need to create an answer key.




Assignment Instructions




In the assignment portion of this exercise, you're going to create an answer key for your "hiring exam." You'll need to swap in your nodes and complete the exercises below.




Setup




If you don't have an account, follow the instructions in the introduction to DETER document.



Log into DETER.



Create an instance of this exercise by following the instructions here, using



/share/education/PermissionsFirewalls_UCLA/permissions.ns as your NS File.




In the "Idle-Swap" field, enter "1". This tells DETER to swap your experiment out if it is idle for more than one hour.




In the "Max. Duration" field, enter "6". This tells DETER to swap the experiment out after six hours.







Swap in your new lab.



After the experiment has finished swapping in, log in to the node via ssh.



As mentioned in DETER Instructions, changes to DETER nodes are lost when the nodes are swapped out. This means that you must manually save your work between working on nodes in order to keep it. However, this exercise includes experimental scripts to help you save and restore your work.




Saving your Work




After completing the POSIX and firewall-related execises on the server node, cd into the /root directory and execute the script /root/submit.sh; like this:







$ ./submit.sh




...it will make a tarball of all the relevant files and their permissions, including the /root/permissions-answers.txt and firewall.sh script you have updated. You must copy or move the created tarball into your group directory, otherwise it will be lost upon swapout.

Restoring Your Work




The experimental script /root/restore.sh on the server node, takes as input the path to a tarball created by submit.sh described above and restores the files to their proper locations on the system. This includes all the files you are asked to create or change in the first part, as well as the firewall.sh script for the second part.










WARNING: These scripts do not back up all arbitrary changes you may have made to the node (e.g., changing a peripheral configuration file), and it does not "merge" system files with submission files -- it only restores submission files copied by submit.sh. You shouldn't need to change anything else, but see submit.sh and restore.sh to see exactly what those scripts do, and do not delete any of your submission tarballs so that you can go back to an earlier version if need be.







To use the restore.sh, copy a tarball created by submit.sh into the /root/ directory and execute this command:







$ ./restore.sh username-permissions-123123123.tar.gz




You will be asked if you want to automatically overwrite files, and if you want to selectively restore some files and not others. The options are self-explanatory.




Finally, if you don't trust the scripts, you can always make your own backups into your group directory and restore them by hand if you prefer.







NOTE: You do not need to run the submit and restore scripts with sudo. However, if you use sudo to run submit.sh, your tarball will be named after the




root user. This is OK -- just run sudo ./restore.sh root-permissions-2134234243.tar.gz.







Tasks




Your task is to create an answer key for the following test:




FrobozzCo Permissions and Firewall Test




This test is a part of the application process for the administrator position at FrobozzCo. You will be presented with a number of tasks and questions; the tasks must be executed on the server node of the DETER experiment we have created for this purpose (you can use the client node for testing), while the questions must be answered in a plain text file that will be submitted with the results of your tasks. See below for further instructions.







Part 1: POSIX File Permissions and 'sudo'




Instructions




The following section includes a number of permissions, firewall, and file creation exercises. This test will be performed on a live network testbed with a full complement of standard utilities and editors. In addition, you are fully encouraged to use the Internet, man pages, help screens, and any other resources available to you in the execution and answering of these problems.

Please read and use these disambiguation rules for setting the correct permissions. Also, make sure that you test your answers -- POSIX permissions are simple in theory, but in practice many combinations have counterintuitive effects!




Your answers will consist of an archive, created by the submit.sh script described above. The archive will contain:




A copy of the necessary server resources containing the results of your file creation and permissions modifications. You will be graded only on the correctness of your answers, not their elegance nor how efficiently you came to them.



Your written answers to the numbered short answer questions. These should be written in the file /root/permissions-answers.txt on the server system using an editor (such as vim).



Your firewall script.



See below for instructions on submitting your answers.




Home Directory Security










Note: Admins -- members of the wheel group have sudo access. However, unless instructed to do so, use only standard UNIX ACLs -- don't give user accounts sudo permissions or consider the sudo access the 'wheel' group already has. Of course, you need to use sudo to create the accounts, edit root files, etc... this is exactly what sudo is for.







Your server needs two home directories, the usual /home and also /admins for your team. Normal home directories are private, while the homedirectories in /admins will be publicly viewable and somewhat collaborative.




Create the /admins directory.



Create the group emp(see man groupadd).



Create the normal (i.e., non admin) user accounts larry, moe, and curly, and the admin user accounts ken, dmr, and bwk.



Note that several files from /etc/skel are copied into each new homedir.




Use passwd to set their passwords to whatever you like (password security is not important for this test).




make sure you specify the home directories for the admins as being in /admins (see man adduser).



add the non-admin accounts to the emp group and add the admins to the wheel group by editing



/etc/group or using usermod.




add larry, bwk, and dmr to ken's group.



add moe, dmr, and ken to bwk's group.
add curly, ken, and bwk to dmr's group.



Admins are not a part of the emp group.







The permissions on the home directories already exclude prying eyes by default. Set the permission mode on /home itself so that normal users can't list its contents (but can still access their home directories) but so that members of the wheel group have full access to the directory (without using
sudo).




By default, the owner of a homedir is set to be the user and the group class of their homedir. Set the permission modes recursively on the individual homedirectories in /admins (see man chmod) so that:
owners have full access




group users (users who are in the group associated with a user's home directory) can read and create files in that homedir




Set it so that any other users can read and execute any files




Files created by a group member in that homedir should be set to the homedir owner's group. (Hint: Look up what the SUID and SGID bits do on directories.)




Homedir permissions for the normal users should use the default permissions.




Example: larry is in ken's group. larry can create files in ken's homedir, and those files are owned by larry, but are assigned to ken's group rather than larry's group. moe, not in ken's group, can only read and execute files.







The Ballot Box




All regular employees use this directory to submit votes for "employee of the month".




Create the /ballots directory.



Set the permissions on /ballots so that it is owned by root and users can write files into the directory but cannot list the contents of the directory.



Furthermore, set it so that members of the wheel group have no access (not including sudo).



Short Answer 1: Is there any way that employees can read the ballots of other users? If so, what could be done to stop this? If not, what prevents them from reading them?



Short Answer 2: What does the 'x' bit mean when applied to directories?



The TPS Reports Directory




Admin employees submit TPS reports in this partially collaborative directory.




Create the /tpsreports directory.



Create the tps user.



Set the permissions on /tpsreports so that it is owned by tps and that members of the wheel group have full access to the directory, but so that no one else has access to the directory.
Furthermore, configure it so that files written into it are still owned by the wheel group, but so that one member of wheel cannot delete another member's files.



Short Answer 3: Which users on the system can delete arbitrary files in the /tpsreports directory?



Short Answer 4: Is there any way that non-wheel employees can read files in the /tpsreports directory?
Short Answer 5: What do '0' permissions mean for the owner of a directory? What privileges do they have over files in that directory?



sudo: Editing Configuration Files










For the following three short answer questions, assume that your answers are unrelated; that is, your answer for question 6 does not impact the answer for questions 7 or 8.







All members of the wheel group do system administration on the server. Because of this, they all have full sudo access to root privilege with the /etc/sudoers directive '%wheel ALL=(ALL) NOPASSWD: ALL'. The "NOPASSWD" means they don't have to enter a passwd upon sudo invocation.




The employee larry is the webmaster for the system, so he has some extra privilege compared to the other employees. For example, larry has sudo access to the command




/usr/bin/vim /etc/httpd/conf/httpd.conf




... with the directive



larry ALL=(ALL) /usr/bin/vim /etc/httpd/confs/httpd.conf ... so that he can update the configuration of the webserver.




Short Answer 6: Is this safe? Why or why not? If it is not safe, is there a better way to give larry this




access? If it is safe, how do you know it is safe? (Hint: search online for common sudo issues.)




sudo: Restarting System Processes




As a part of his webmaster duties, larry often requests the wheel group to restart the Apache server with the command '/etc/init.d/httpd restart'. It would make everyone very happy if there was a secure way to let larry restart the Apache server (but not give him any other access).




Short Answer 7: Assuming the init script /etc/init.d/httpd has no unknown vulnerabilities, is it safe to grant larry sudo access to the command /etc/init.d/httpd restart? If this is not secure, explain why.




POSIX and sudo: Two Wrongs Make a Much Bigger Wrong




Carefully examine the permissions on the server. Look at /etc/group, /etc/sudoers, and the files in the /admins and /home directories (and their subdirectories).




Short Answer 8: Is there some way that moe or curly could subvert this system to gain root privileges? If not, how do you know this is true?




Hint: Consider what happens during the UNIX login process -- the time between when the user enters the correct password and when they can interact with their shell.




Part 2: Firewall Configuration




The test server has a totally permissive firewall installed -- it accepts all inbound and outbound traffic from all ports, protocols, addresses, interfaces, and states. This is basically like having no firewall at all.




Your task is to configure the firewall according to the principle of "least privilege". This means that it should be maximally restrictive while still permissive enough to allow a strictly defined set of tasks. While some of these rules can also be configured in the server software (this strategy is called defense in depth), we want you to implement the rules in iptables only -- do not reconfigure the underlying software.




The firewall has been copied into the directory /root/firewall/ along with a script called extingui.sh to "put out the fire" and clear all the rules in case you make a mistake. The firewall is not enabled by default - - to enforce the rules, execute:







/root/firewall/firewall.sh




... as the root user or using sudo:







sudo /root/firewall/firewall.sh




This will load the rules and start enforcing them. To make sure that you are removing all iptables rules, you should run extingui.sh in between every invocation of firewall.sh or rules might "stick around" which can be very confusing if you are trying to debug the system. This can be done like this as root (or with sudo as above):







/root/firewall/extingui.sh

If you make the server inaccessible with broken rules, don't worry -- you can reboot the node in the DETER console, and since the firewall is not enabled by default, you can log in in order to fix it. Your files will still be on the experimental node as long as you don't swap out the experiment. (Of course, you can permanently save your files in your home directory.)




Finally, only your final product is evaluated -- not the number of times you have to reboot the server. You should expect to lock yourself out a few times.










Your experimental nodes have at least two networks. The first is a control network between your node and users.deterlab.net. This is the network you use to connect to your nodes from users. Your nodes also have an "experimental" network that connects all the machines in a given experiment. For this project, your experimental network connects server and client




The firewall only needs to limit the experimental network interface (the interface with the 10.1.x.x network) and should not ever limit the control network




(192.x.x.x as of this writing) or you may cut yourself off from the node. The experimental interface is one of eth0-ethN and you can determine which using the command ifconfig and looking for the 10.x.x.x interface. Be warned that the specifc interface used may change with a reboot or different experimental node.




See below for instructions on using environment variables to define the experimental interface in your firewall.sh script.







Here's what the firewall needs to do:




passively ignore any traffic inbound to the interface that says it's coming from the server itself (obvious spoof attempt). The server uses the localhost loopback device lo for internal traffic, so it should never see incoming traffic from its own IP on the experimental network interface. (See test case 11, below)



Allow all established traffic on the experimental network interface. Established or related traffic is traffic that is part of previously accepted new connections.



Accept new connections on the experimental network (10.1.x.x) of the types listed below:



Inbound TCP connections to the OpenSSH, Apache, and MySQL servers on their standard ports. (Test cases 1, 3, 5)



The MySQL server should only accept connections from the client host.




Inbound UDP connections to the server ports 10000 to 10005 from the host client. (Test case 8)
Inbound ICMP ping requests and replies. (Test case 6)



Outbound TCP connections to any OpenSSH, SMTP, and Apache (on standard ports). (Test cases 2, 4)



Outbound UDP connections to the ports 10006 to 10010 on host client from the server. (Test case 9)



Outbound ICMP ping requests and replies. (Test case 7)



passively ignore all other traffic. (Do not allow it or respond to it in any way.) (Test case 10)



There are many online resources and tutorials for iptables configuration -- feel free to use them. Be aware, however, not all tutorials emphasize the principle of least privilege and may give you overly permissive advice! In order to properly configure the firewall, you must consider the basic ways the firewall can differentiate traffic and allow only the specific types you require to properly function.




Please read the helpful advice in the next section for configuring and testing your firewall.

Tips and Tricks




This section includes important rules and tips for making sure that your answers are correct.




1. Rules for resolving filesystem permission ambiguities:




Permissions should always be set to reflect the least privilege required to fulfill the requirements. In POSIX permissions, every bit set represents less security, so we want to set as few bits as possible. Resolve any ambiguities with this cumulative list of guidelines:




Files you are instructed to create are to be owned by root unless otherwise specified. Doing the work as root should do this automatically. (You can become root by executing sudo su -.)



Exception: Files in homedirs should be owned by the homedir owner (useradd should do this by default for boilerplate files like .bash_login, etc).




When setting ownership of a file, set the group class to the same thing as the user (owner) class unless otherwise specified.



Example: Create the directory foo. Set www-data as the owner of foo.




Answer: Set www-data to be the user (owner) and group class of foo.




Example: Create the directory xyzzy. Set the group class to www-data.




Answer: Set the group class to www-data but the user class should still be set to root.




Files whose permissions you are not otherwise instructed to change should stay at their default.



Example: Create directory baz. Create directory quux and set its permissions to be wide open.







Answer: Don't change baz's file mode. It should be owned by root (as per #1). Set quux permissions to 0777.




For any files whose permissions you are instructed to change, unspecified permissions are always assumed to be 0 (no access). In other words, instructions for setting file permissions implicitly include all access groups (even those not explicitly mentioned).



Example: Set directory foo so that its owner has full access.




Answer: The correct mode is 0700, since no group or other permissions were specified and we assume that they are 0.




Permissions are assumed to be for all classes unless specified.



Example: Remove all permissions from /dev/hdc.




Answer: Set /dev/hdc to mode 000 (root still has access of course).




Example: Set read and write permissions on /etc/motd.




Answer: /etc/motd should be set to mode 0666 -- all classes can read and write.




When granting permissions, setuid, setgid, and sticky bits are never granted unless specifically required to solve the problem. These bits are special and must be required by the nature of the question or be otherwise mentioned to be granted.



Example: Set a directory so that owner has full access and it's group class members can create files in it.




Answer: The correct mode is 0730 because a user (in this case the group user) requires both write and execute to create files. The question didn't specify anything requiring setuid or setgid so they are not enabled.




Note: the other class in this example has no access because the permission is assumed to be 0 (as per #4).




Note: In #3 above, see that "wide open" for the directory quux meant 0777 not 4777 because setuid was not specified or required.




If any tasks are not possible with the standard POSIX permissions available in this exercise, explain why.



Use Environment Variables in your firewall.sh!
Your firewall script is only supposed to limit the traffic on the "experimental network" interface, as opposed to including the "control network" of DETER. If you block the control network, you're likely to lose connection to your node, or shut off networked file systems, etc.




Unfortunately, different DETER nodes (the physical computers you are given) bring up their networks on different interfaces (and in general you can't control which nodes you get). This means that on one node, the experimental network might be on eth0, and on another node, it might be on eth4 (or any other ethN). This makes writing your script difficult because it is not 100% portable from one node to another.




However, we can use an environment variable to substitute in the right interface. In the firewall.sh script, there is a variable declaration:







ETH="eth0"




You can use this variable with the token $ETH -- the shell will substitute in its value at runtime. Use ifconfig to make sure that ETH is set to the right value for your experimental node (or update it). For example, use ETH in a hypothetical iptables command like this:







iptables -A INPUT -i $ETH -j ACCEPT




This way, you only need to update the ETH variable if your interface changes, rather than every iptables call that specifies an interface.




3. How to test your firewall




Testing your firewall is easy; you just need to make sure that the allowed services are allowed, and that things that should be denied are denied. To do that, we'll use a few tools like telnet, netcat, and others.




You may also have noticed that this experiment swaps in two nodes instead of one. One will be called client and the other will be called server. server is the node with the firewall and resources you want to protect, but you can use client to check to see if the firewall is doing its job. You can also use client as a target to see if the server's outbound rules are functioning properly, using tools such as nmap, telnet, nc, and others in the network tools portion of this document.




The following tests have been provided by Dr. Tanya Crenshaw from the University of Portland. While these test cases cannot guarantee a perfect firewall, they should help you understand if your firewall is meeting the guidelines.




Firewall Test Cases










c$ indicates tests run from client node and s$ indicates tests run from the server node




The test file “hi.txt” was created on the client using by executing: c$ echo

“hi” hi.txt










#
Rule
Test
Result




















c$ telnet server 22
SUCCESS: A


Allow inbound traffic
Trying 10.1.1.3...


connection on port
1
to the OpenSSH
Connected to server.
22 is established


port.
Escape character is '^]'.




SSH-1.99-OpenSSH_4.2 using the telnet tool.




















See well-formed reply from ssh server
2
Allow outbound ssh
in Test #1:
traffic (established).






‘SSH-1.99-OpenSSH_4.2’







SUCCESS: The ssh server running on the server node replies to telnet’s connection request with the SSH version number.










c$ telnet server 80
SUCCESS: A
3
Allow inbound traffic
Trying 10.1.1.3...
connection on port
to http traffic.
Connected to server.
80 is established






Escape character is '^]'.
using the telnet tool.






















SUCCESS: The




c$ nc




Apache Web Server




server.MyExp.MyClass.isi.deterlab.net
running on the
4
Allow outbound http
80 < hi.txt
server node replies
traffic (established).


to the client’s badly-


...




formed http request






with a well-formed






http reply.




















SUCCESS:




c$ [client]$ telnet server 3306




Connect to the




Trying 10.1.1.3...
MySQL server




Connected to server.
running on the


Allow inbound and
Escape character is '^]'.
server node using
5 outbound mySQL
K#HY000Host 'client-link0' is not
the telnet tool.


traffic
allowed to connect to this MySQL
MySQL server




serverConnection closed by foreign
responds with an




host.
error indicating that






outbound traffic is






allowed.



























c$ ping server


PING server-link0 (10.1.1.3) 56(84)
Allow new inbound
bytes of data.
64 bytes from server-link0
6 ping traffic.
(10.1.1.3): icmp_seq=0 ttl=64


time=0.412 ms











SUCCESS: Ping request from client is replied to by server. Note that request is new traffic, while reply is established traffic.





s$ ping client


PING client-link0 (10.1.1.2) 56(84)
Allow new
bytes of data.
64 bytes from client-link0
7 outbound ping





SUCCESS: Ping request from server is replied to by client. Note that
traffic.
(10.1.1.2): icmp_seq=0 ttl=64
request is new


time=0.302 ms
traffic, while reply is




established traffic.


























s$
nc -u -l 10000
SUCCESS: Traffic
Allow inbound UDP
hello
is allowed into the




server on port
8 traffic on ports
c$
nc -u server 10000
10000. Run the
10000:10005


(type ‘hello’)
same test for










10001:10005.






























Allow outbound




UDP traffic on ports 10006:10010



c$ nc -u -l 10006




hello




s$ nc -u client 10006




(type ‘hello’)




SUCCESS: Traffic




is allowed out of the

server on port

10006. Run the

same test for




10007:10010.






























10
Disallow all other
c$
telnet
server PORT






traffic
s$
telnet
server PORT






















SUCCESS: The full test is to run a bash script on the client-side and server-side which attempts telnet on every other port aside from those not addressed above, and also tests UDP, etc. A good firewall design should ensure that all traffic is dropped except that which is explicitly accepted.






11 Prevent spoofing
Straighforward test unknown
NA

















What can go wrong




1. Your firewall cuts off your access to the node.




If you have misconfigured your firewall, and it "locks you out," you can try to reboot your experimental nodes using the DETER interface. If that does not work, you will need to swap your nodes out and back in again, but beware that swapping your nodes out will destroy any work you have not backed up in your home directory.




Make sure you are using the environment variable to define the interface you are restricting -- this will help
keep you from getting "locked out." See the tips and tricks section for more information.




Submission Instructions




Submit a tarball created by submit.sh to your instructor. You must use a tarball created by this script so that it will correctly save the permissions of the directories.