Computer Systems Security: Winter 2018 Assignment 1 - Revision history

Soma: /* Solutions */

2018-02-11T00:03:34Z

Solutions

← Older revision		Revision as of 00:03, 11 February 2018
Line 34:		Line 34:
	# TCP wrappers work inside the application process, in userspace, while host-based firewalls block connections inside the kernel.		# TCP wrappers work inside the application process, in userspace, while host-based firewalls block connections inside the kernel.
	# When a system is connected to a VPN, all of its network traffic is encrypted and sent to the VPN gateway. The gateway decrypts the traffic and sends it on to the intended destination. This also happens in reverse. You can verify this by examining the raw packets being received by and sent from the host's network device (ethernet, WiFi) using a program such as Wireshark and verifying that they are all going to or from the IP address of the VPN gateway and are encrypted.		# When a system is connected to a VPN, all of its network traffic is encrypted and sent to the VPN gateway. The gateway decrypts the traffic and sends it on to the intended destination. This also happens in reverse. You can verify this by examining the raw packets being received by and sent from the host's network device (ethernet, WiFi) using a program such as Wireshark and verifying that they are all going to or from the IP address of the VPN gateway and are encrypted.
	# VPNs can help defend against attackers that are "near" the VPN-connecting host, as such attackers can observe and manipulate network traffic. DNS redirects, IP spoofing, eavesdropping, and other attacks are all defended against by a VPN. The key limitation of VPNs is that they only protect traffic between the host and the VPN gateway; traffic can be intercepted and manipulated anywhere between the VPN gateway and the remote hosts that are being communicated with. To defend against network attacks end-to-end we need end-to-end encryption, authentication, and integrity protection. Such protection is provided by TLS. Note that VPNs provide protection for all traffic, not just TLS-protected - but only to and from the gateway.		# VPNs can help defend against attackers that are "near" the VPN-connecting host, as such attackers can observe and manipulate network traffic. DNS redirects, IP spoofing, eavesdropping, and other attacks are all defended against by a VPN. The key limitation of VPNs is that they only protect traffic between the host and the VPN gateway; traffic can be intercepted and manipulated anywhere between the VPN gateway and the remote hosts that are being communicated with. To defend against network attacks end-to-end we need end-to-end encryption, authentication, and integrity protection. Such protection is provided by TLS. Note that VPNs provide protection for all traffic, not just TLS-protected - but only to and from the gateway. (Note VPNs don't on their own prevent compromised systems from connecting to a corporate network and infecting other systems. However, this challenge is not fundamental as VPNs aren't designed to solve this issue - it isn't part of their threat model. Other mechanisms, such as anti-malware scanners, can help protect against such threats.)
	# Carleton uses Cisco AnyConnect for VPN clients to connect to cuvpn.carleton.ca (which presumably is a Cisco VPN server). If you use this VPN server, you can access many restricted online paper respositories such as IEEE Xplore and ScienceDirect directly; otherwise, to access these you have to go through a web proxy provided by the Carleton Library. Also, you can access the SCS openstack cluster when connected to the campus VPN.		# Carleton uses Cisco AnyConnect for VPN clients to connect to cuvpn.carleton.ca (which presumably is a Cisco VPN server). If you use this VPN server, you can access many restricted online paper respositories such as IEEE Xplore and ScienceDirect directly; otherwise, to access these you have to go through a web proxy provided by the Carleton Library. Also, you can access the SCS openstack cluster when connected to the campus VPN.

Soma: /* Solutions */

2018-02-10T23:56:18Z

Solutions

← Older revision		Revision as of 23:56, 10 February 2018
Line 35:		Line 35:
	# When a system is connected to a VPN, all of its network traffic is encrypted and sent to the VPN gateway. The gateway decrypts the traffic and sends it on to the intended destination. This also happens in reverse. You can verify this by examining the raw packets being received by and sent from the host's network device (ethernet, WiFi) using a program such as Wireshark and verifying that they are all going to or from the IP address of the VPN gateway and are encrypted.		# When a system is connected to a VPN, all of its network traffic is encrypted and sent to the VPN gateway. The gateway decrypts the traffic and sends it on to the intended destination. This also happens in reverse. You can verify this by examining the raw packets being received by and sent from the host's network device (ethernet, WiFi) using a program such as Wireshark and verifying that they are all going to or from the IP address of the VPN gateway and are encrypted.
	# VPNs can help defend against attackers that are "near" the VPN-connecting host, as such attackers can observe and manipulate network traffic. DNS redirects, IP spoofing, eavesdropping, and other attacks are all defended against by a VPN. The key limitation of VPNs is that they only protect traffic between the host and the VPN gateway; traffic can be intercepted and manipulated anywhere between the VPN gateway and the remote hosts that are being communicated with. To defend against network attacks end-to-end we need end-to-end encryption, authentication, and integrity protection. Such protection is provided by TLS. Note that VPNs provide protection for all traffic, not just TLS-protected - but only to and from the gateway.		# VPNs can help defend against attackers that are "near" the VPN-connecting host, as such attackers can observe and manipulate network traffic. DNS redirects, IP spoofing, eavesdropping, and other attacks are all defended against by a VPN. The key limitation of VPNs is that they only protect traffic between the host and the VPN gateway; traffic can be intercepted and manipulated anywhere between the VPN gateway and the remote hosts that are being communicated with. To defend against network attacks end-to-end we need end-to-end encryption, authentication, and integrity protection. Such protection is provided by TLS. Note that VPNs provide protection for all traffic, not just TLS-protected - but only to and from the gateway.
	#		# Carleton uses Cisco AnyConnect for VPN clients to connect to cuvpn.carleton.ca (which presumably is a Cisco VPN server). If you use this VPN server, you can access many restricted online paper respositories such as IEEE Xplore and ScienceDirect directly; otherwise, to access these you have to go through a web proxy provided by the Carleton Library. Also, you can access the SCS openstack cluster when connected to the campus VPN.

Soma: /* Solutions */

2018-02-06T13:44:10Z

Solutions

← Older revision		Revision as of 13:44, 6 February 2018
Line 34:		Line 34:
	# TCP wrappers work inside the application process, in userspace, while host-based firewalls block connections inside the kernel.		# TCP wrappers work inside the application process, in userspace, while host-based firewalls block connections inside the kernel.
	# When a system is connected to a VPN, all of its network traffic is encrypted and sent to the VPN gateway. The gateway decrypts the traffic and sends it on to the intended destination. This also happens in reverse. You can verify this by examining the raw packets being received by and sent from the host's network device (ethernet, WiFi) using a program such as Wireshark and verifying that they are all going to or from the IP address of the VPN gateway and are encrypted.		# When a system is connected to a VPN, all of its network traffic is encrypted and sent to the VPN gateway. The gateway decrypts the traffic and sends it on to the intended destination. This also happens in reverse. You can verify this by examining the raw packets being received by and sent from the host's network device (ethernet, WiFi) using a program such as Wireshark and verifying that they are all going to or from the IP address of the VPN gateway and are encrypted.
	#		# VPNs can help defend against attackers that are "near" the VPN-connecting host, as such attackers can observe and manipulate network traffic. DNS redirects, IP spoofing, eavesdropping, and other attacks are all defended against by a VPN. The key limitation of VPNs is that they only protect traffic between the host and the VPN gateway; traffic can be intercepted and manipulated anywhere between the VPN gateway and the remote hosts that are being communicated with. To defend against network attacks end-to-end we need end-to-end encryption, authentication, and integrity protection. Such protection is provided by TLS. Note that VPNs provide protection for all traffic, not just TLS-protected - but only to and from the gateway.
	#		#

Soma: /* Solutions */

2018-02-06T13:32:56Z

Solutions

← Older revision		Revision as of 13:32, 6 February 2018
Line 33:		Line 33:
	# TCP wrappers and host-based firewalls prevent services from being accessed from arbitrary hosts on the Internet. Thus, services that should only be legitimately used by a relatively small number of hosts do not have to specifically deny access to unauthorized hosts. This sort of restriction helps prevent brute force authentication attacks (e.g. password guessing) and remote code injection exploits from untrusted hosts.		# TCP wrappers and host-based firewalls prevent services from being accessed from arbitrary hosts on the Internet. Thus, services that should only be legitimately used by a relatively small number of hosts do not have to specifically deny access to unauthorized hosts. This sort of restriction helps prevent brute force authentication attacks (e.g. password guessing) and remote code injection exploits from untrusted hosts.
	# TCP wrappers work inside the application process, in userspace, while host-based firewalls block connections inside the kernel.		# TCP wrappers work inside the application process, in userspace, while host-based firewalls block connections inside the kernel.
	#		# When a system is connected to a VPN, all of its network traffic is encrypted and sent to the VPN gateway. The gateway decrypts the traffic and sends it on to the intended destination. This also happens in reverse. You can verify this by examining the raw packets being received by and sent from the host's network device (ethernet, WiFi) using a program such as Wireshark and verifying that they are all going to or from the IP address of the VPN gateway and are encrypted.
	#		#
	#		#

Soma: /* Solutions */

2018-02-06T13:27:13Z

Solutions

← Older revision		Revision as of 13:27, 6 February 2018
Line 32:		Line 32:
	# There are many possible examples. A simple one is a passwd binary that doesn't properly restrict arbitrary password changes to the root user (e.g., there is a logic error in the code restricts arbitrary password changes to root). If this is the case, then any user can change anyone else's password.		# There are many possible examples. A simple one is a passwd binary that doesn't properly restrict arbitrary password changes to the root user (e.g., there is a logic error in the code restricts arbitrary password changes to root). If this is the case, then any user can change anyone else's password.
	# TCP wrappers and host-based firewalls prevent services from being accessed from arbitrary hosts on the Internet. Thus, services that should only be legitimately used by a relatively small number of hosts do not have to specifically deny access to unauthorized hosts. This sort of restriction helps prevent brute force authentication attacks (e.g. password guessing) and remote code injection exploits from untrusted hosts.		# TCP wrappers and host-based firewalls prevent services from being accessed from arbitrary hosts on the Internet. Thus, services that should only be legitimately used by a relatively small number of hosts do not have to specifically deny access to unauthorized hosts. This sort of restriction helps prevent brute force authentication attacks (e.g. password guessing) and remote code injection exploits from untrusted hosts.
	#		# TCP wrappers work inside the application process, in userspace, while host-based firewalls block connections inside the kernel.
	#		#
	#		#
	#		#

Soma: /* Solutions */

2018-02-05T03:59:32Z

Solutions

← Older revision		Revision as of 03:59, 5 February 2018
Line 30:		Line 30:
	# Setuid root binaries are important because they allow unprivileged users to perform privileged operations under controlled circumstances, such as changing their password or mounting a filesystem. Without setuid root binaries, the only way for a unprivileged user to perform a privileged operation on UNIX would be to communicate with a process that already had privileges (e.g., a privileged process listening on a socket).		# Setuid root binaries are important because they allow unprivileged users to perform privileged operations under controlled circumstances, such as changing their password or mounting a filesystem. Without setuid root binaries, the only way for a unprivileged user to perform a privileged operation on UNIX would be to communicate with a process that already had privileges (e.g., a privileged process listening on a socket).
	# The risk of setuid root binaries is that 1) they can be run by unprivileged users and 2) they can perform privileged operations. If there is a flaw in such a binary, then unprivileged users can perform privileged tasks or even obtain full privileges when they shouldn't be able to. Thus, every setuid root binary represents an opportunity for an attacker to subvert the entire UNIX security model.		# The risk of setuid root binaries is that 1) they can be run by unprivileged users and 2) they can perform privileged operations. If there is a flaw in such a binary, then unprivileged users can perform privileged tasks or even obtain full privileges when they shouldn't be able to. Thus, every setuid root binary represents an opportunity for an attacker to subvert the entire UNIX security model.
	#		# There are many possible examples. A simple one is a passwd binary that doesn't properly restrict arbitrary password changes to the root user (e.g., there is a logic error in the code restricts arbitrary password changes to root). If this is the case, then any user can change anyone else's password.
	#		# TCP wrappers and host-based firewalls prevent services from being accessed from arbitrary hosts on the Internet. Thus, services that should only be legitimately used by a relatively small number of hosts do not have to specifically deny access to unauthorized hosts. This sort of restriction helps prevent brute force authentication attacks (e.g. password guessing) and remote code injection exploits from untrusted hosts.
	#		#
	#		#
	#		#
	#		#

Soma: /* Solutions */

2018-02-05T03:50:02Z

Solutions

← Older revision		Revision as of 03:50, 5 February 2018
Line 29:		Line 29:
	# Setuid binaries have the setuid bit set (chmod u+s). This bit instructs the kernel to change the effective uid of the process after an execve to the owner of the exec'd binary. Setuid root binaries are binaries that are owned by root with the setuid bit set; thus, when they are run, they run with full root privileges.		# Setuid binaries have the setuid bit set (chmod u+s). This bit instructs the kernel to change the effective uid of the process after an execve to the owner of the exec'd binary. Setuid root binaries are binaries that are owned by root with the setuid bit set; thus, when they are run, they run with full root privileges.
	# Setuid root binaries are important because they allow unprivileged users to perform privileged operations under controlled circumstances, such as changing their password or mounting a filesystem. Without setuid root binaries, the only way for a unprivileged user to perform a privileged operation on UNIX would be to communicate with a process that already had privileges (e.g., a privileged process listening on a socket).		# Setuid root binaries are important because they allow unprivileged users to perform privileged operations under controlled circumstances, such as changing their password or mounting a filesystem. Without setuid root binaries, the only way for a unprivileged user to perform a privileged operation on UNIX would be to communicate with a process that already had privileges (e.g., a privileged process listening on a socket).
	#		# The risk of setuid root binaries is that 1) they can be run by unprivileged users and 2) they can perform privileged operations. If there is a flaw in such a binary, then unprivileged users can perform privileged tasks or even obtain full privileges when they shouldn't be able to. Thus, every setuid root binary represents an opportunity for an attacker to subvert the entire UNIX security model.
	#		#
	#		#

Soma: /* Solutions */

2018-02-05T03:47:03Z

Solutions

← Older revision		Revision as of 03:47, 5 February 2018
Line 28:		Line 28:
	# Normally anyone who can write to a directory can also remove any file in the directory (as write privileges implies unlink privileges). If the sticky bit is set on such a directory with the command "chmod +t", however, users can only unlink their own files. Thus the sticky bit is normally set on system temporary file directories (e.g., /tmp, /var/tmp) and other world-writable directories.		# Normally anyone who can write to a directory can also remove any file in the directory (as write privileges implies unlink privileges). If the sticky bit is set on such a directory with the command "chmod +t", however, users can only unlink their own files. Thus the sticky bit is normally set on system temporary file directories (e.g., /tmp, /var/tmp) and other world-writable directories.
	# Setuid binaries have the setuid bit set (chmod u+s). This bit instructs the kernel to change the effective uid of the process after an execve to the owner of the exec'd binary. Setuid root binaries are binaries that are owned by root with the setuid bit set; thus, when they are run, they run with full root privileges.		# Setuid binaries have the setuid bit set (chmod u+s). This bit instructs the kernel to change the effective uid of the process after an execve to the owner of the exec'd binary. Setuid root binaries are binaries that are owned by root with the setuid bit set; thus, when they are run, they run with full root privileges.
	#		# Setuid root binaries are important because they allow unprivileged users to perform privileged operations under controlled circumstances, such as changing their password or mounting a filesystem. Without setuid root binaries, the only way for a unprivileged user to perform a privileged operation on UNIX would be to communicate with a process that already had privileges (e.g., a privileged process listening on a socket).
	#		#
	#		#

Soma: /* Solutions */

2018-02-05T03:21:41Z

Solutions

← Older revision		Revision as of 03:21, 5 February 2018
Line 27:		Line 27:
	# Read permission lets you list the files in a directory. Execute permission lets you open or execute a file named in the directory. You can verify this by setting only read or execute permissions with the chmod command (e.g., chmod a-r to remove read permissions, chmod a-x to remove execute permissions) and then seeing what access you have.		# Read permission lets you list the files in a directory. Execute permission lets you open or execute a file named in the directory. You can verify this by setting only read or execute permissions with the chmod command (e.g., chmod a-r to remove read permissions, chmod a-x to remove execute permissions) and then seeing what access you have.
	# Normally anyone who can write to a directory can also remove any file in the directory (as write privileges implies unlink privileges). If the sticky bit is set on such a directory with the command "chmod +t", however, users can only unlink their own files. Thus the sticky bit is normally set on system temporary file directories (e.g., /tmp, /var/tmp) and other world-writable directories.		# Normally anyone who can write to a directory can also remove any file in the directory (as write privileges implies unlink privileges). If the sticky bit is set on such a directory with the command "chmod +t", however, users can only unlink their own files. Thus the sticky bit is normally set on system temporary file directories (e.g., /tmp, /var/tmp) and other world-writable directories.
	#		# Setuid binaries have the setuid bit set (chmod u+s). This bit instructs the kernel to change the effective uid of the process after an execve to the owner of the exec'd binary. Setuid root binaries are binaries that are owned by root with the setuid bit set; thus, when they are run, they run with full root privileges.
	#		#
	#		#
	#		#

Soma: /* Solutions */

2018-02-04T03:15:45Z

Solutions

← Older revision		Revision as of 03:15, 4 February 2018
Line 26:		Line 26:
	# Yes, it is possible. For example, if we set the permissions of foo.txt to 066, then everyone except for the file owner will be able to read and write the file. (Of course, the owner can change these permissions at any time.)		# Yes, it is possible. For example, if we set the permissions of foo.txt to 066, then everyone except for the file owner will be able to read and write the file. (Of course, the owner can change these permissions at any time.)
	# Read permission lets you list the files in a directory. Execute permission lets you open or execute a file named in the directory. You can verify this by setting only read or execute permissions with the chmod command (e.g., chmod a-r to remove read permissions, chmod a-x to remove execute permissions) and then seeing what access you have.		# Read permission lets you list the files in a directory. Execute permission lets you open or execute a file named in the directory. You can verify this by setting only read or execute permissions with the chmod command (e.g., chmod a-r to remove read permissions, chmod a-x to remove execute permissions) and then seeing what access you have.
	#		# Normally anyone who can write to a directory can also remove any file in the directory (as write privileges implies unlink privileges). If the sticky bit is set on such a directory with the command "chmod +t", however, users can only unlink their own files. Thus the sticky bit is normally set on system temporary file directories (e.g., /tmp, /var/tmp) and other world-writable directories.
	#		#
	#		#