TechBait

Have you ever wanted to communicate somewhat securely over a public network, like the Internet, in order to exchange confidential or sensitive information, passwords, or other data?  You need a VPN to connect you from one point to another over the insecure public medium.  This secure connection is the VPN, or Virtual Private Network.  The VPN, whether purely software or by utilizing a VPN appliance device containing it’s own software, uses encryption software to construct a tunnel between the two points, thus allowing the user to exchange confidential information or sensitive login information between two points.  VPN’s can also be useful for simply contacting your private network remotely, since you don’t want unknown entities to see your internal network infrastructure, hosts, or to sniff out your passwords.

On a similarly related line of thought, if you use UNIX or Linux, a good way to access your home network over the Internet from a remote point is to set up an SSH tunnel, where the Secure Shell is used to contruct a tunnel.  You login to the remote UNIX or Linux host via SSH, and then you can launch graphical Xwindows applications using an SSH tunnel.  You can do this from a Windows client by using the Cygwin or other software which allows one to run POSIX, GNU, and UNIX/Linux utilities on a Windows machine.  You can do this from work if your network allows this sort of Internet access.  It is handy to be able to access your home UNIX/Linux server over an SSH tunnel.

$ ssh -X u...@server.homenetwork.com
$ ssh -X user@<public ip address of server>

You can requests compression of all data to improve up user experience (good for a low speed link such as wan link) using -c option:

$ ssh -c -X user@<public ip address of server>

You can then run any Xwindows application on the remote xterm by simply typing the program executable name followed by the ampersand to spin it off into it’s own process ID.  You can also run an entire desktop like KDE, Gnome, or the default Xwindows desktop with the startx command.

The root partition on a Solaris system is defined as Slice 0, and is mounted as root (/).  This is the top level of the filesystem.  In computer parlance root starts at the top, but if you look at it as a biological tree is grown, from the bottom up, it also makes sense as the origin of the filesystem.

Slice 1 is used for swap space, which is virtual memory.  Some operating systems, like Windows, use a swap file, while UNIX and UNIX like filesystems use an entire partition for swap.  The size of swap is reliant on how much physical memory is in the system.  There are various formulas for how large to make the swap area.  Some go for twice to twice plus half of physical memory, and some prefer larger in case physical memory increases.  You can always add extra swap partitions in the future if they are needed.

Slice 2 is representative of the entire disk and is not mounted as anything.

Slice 3 is mounted as /export in the default setting.  Directories exported via NFS, such as user HOME directories, are kept here.

Slice 4 is mounted as /export/swap.  This is meant to provide virtual memory for client computers.  It can also be mounted as /opt for optional software.

Slice 5 is usually mounted as /opt, for optional software that is not critical to the functioning of the system.  If /opt is on Slice 4 then /var is what resides on Slice 5.

Slice 6 is mounted as /usr, which contains libraries and binary files that are used by regular system users.  The /usr partition is shared between systems.

Slice 7 is mounted as /home, /export home, or /export/share.  This holds user home directories or other shared data.

In computer networking parlance, ARP stand for Address Resolution Protocol.  Well, this tells us that computer addresses are being resolved via some sort of lookup table.  The ARP cache is what translates IP (Internet Protocol) addresses to hardware MAC (Media Access Control) addresses within a TCP/IP network.  ARP replies can be spoofed easily if one of your network;s systems are compromised.  The compromised system can spoof other systems on the network.  The spoofing is when the target machine receives faulty information linking an unsafe MAC address to a local IP address.  The preventative measure (UNIX and *NIX) is a list of trusted systems that is hard coded into the /etc/ethers (or equivalent) file where the true MAC addresses are mapped to the true IP address, preventing the ARP protocol from overriding this information.  The file needs to be updated if a network card is changed since every networked device must have a unique MAC address.

I’m happy to see that the Rite Group still has their page up on how to set up a Solaris DHCP client.  This works and it is very useful.  I always would point field engineers who needed to accomplish this task to this page, and I used it myself for any in house Solaris machines that had to be set up as DHCP clients.  Find this useful method HERE.

Solaris is Sun Microsystems’ version of UNIX.  For non NIS/NIS+ Solaris machines, the things necessary to add it to an IP network are:

• The /etc/hosts file must have the hostname and IP address of the machine.
• There must be an /etc/hostname.[interface] file which contains the system hostname.  The [interface] is the designation of the network interface assigned the address, for example, /etc/hostname.eri0 or /etc/hostname.dmfe0
• There must exist an /etc/netmasks file which holds the subnet mask for the machine.
• The /etc/resolv.conf file must contain the DNS server if the host relies on DNS for name to IP address resolution.
• Finally, the /etc/defaultrouter file needs to hold the IP address of the router for the subnet – or in other words the default gateway address.

Once upon a time I was called on by a software developer to assist him in a problem where he had to code a solution to a bug in the enterprise software that our employer was a vendor of, but the client had their network interface cards combined into a single virtual device, also known as link aggregation.  Why would you want to do this?  Aggregating the nics allows the throughput to be higher for the server.  So, aggregating two Gbit nics will essentially create a 2 Gbit connection, although the individual line speeds are still the 1 Gbit speeds.  It also provides failover since the physical connections are aggregated into a virtual connection which uses one IP address, so if one fails the connection is still active.  This is good fault tolerance, to a point.  I had to figure out how to make one of our AIX servers into a machine with an aggregated nic setup.  It wasn’t so hard once I found the documentation on how to do it.  He was able to work on this machine once I combined the two physical network connections into one virtual device using one IP address, and he was able to then verify the issue the customer was having and code a fix.  This is how a sysadmin in a software company assists the software development and fix process.  I did this for years and it was very interesting and rewarding work, although it was only a small portion of my daily repertoire.

I don’t have to explain it here since the good folks at IBM were kind enough to outline how to do this on their documentation site.  Also, a good overview is available on Wikipedia’s link aggregation page.

The order in which Linux starts system services is governed by what runlevel is assigned to the service in question. Some runlevels will boot or halt the system itself, while others control regular system services or even programs that the administrator installs and wants started at a particular time in the boot cycle. These runlevels are controlled with scripts that are defined by runlevel named directories in which they reside. The default runlevel for the system is set in the /etc/inittab file, but it can be overridden from the GRUB boot loader menu. Redhat Enterprise Linux has six runlevels.
Runlevel 0: Halt the system. When the system is sent to this runlevel, everything shuts down and the system is completely halted. If the computer’s BIOS supports it, the machine is powered off at the end of the process.

Runlevel 1: This is single user mode. In single user mode an admininstrator can do all sorts of maintenance, like backups, restores, and repairs. This is useful because no other users can be logged in and the system is not prone to having others change things, which is important when this sort of work is being done. Networking is not enabled so the network interfaces and infrastructure are offline.

Runlevel 2: In this runlevel, multiuser functionality is enabled with only some networking services enabled.

Runlevel3: Multiuser mode is enabled with full networking functionality.

Runlevel 4: This runlevel is currently not used.

Runlevel 5: The X Windows graphical user interface system is enabled and the user is brought to a graphical login screen. After logging in, the user is taken to their graphical desktop as in all of the popular operating systems of today. Networking is fully enabled.

Runlevel 6: This is the reboot runlevel. It does what it says and reboots the system. You should never set the /etc/inittab default runlevel to number 6 for obvious reasons. Your system would be in an endless reboot loop.

Each runlevel has a bunch of scripts associated with it. Runlevel 3 scripts are located in the /etc/rc.d/rc3.d directory. The runlevel directories are rc0.d through rc6.d, and they are all located under the /etc/rc.d directory. Whatever the default runlevel is set to in the /etc/inittab file, the system will look in the appropriate runlevel directory and execute the scripts in numeric order, starting and killing services according to the scripts. The start scripts start with an “S” and the kill scripts with a “K”. The scripts in the runlevel directories are really just symbolic links to the real script files in the /etc/rc.d/init.d directory. The /etc/rc.d/ rc(number).d directory is hard linked to /etc/rc(number).d directory, so you can use the shorter one to get to the same place.

Knowing about Linux runlevels is an important part about knowing how to handle a Linux system, and the knowledge translates to UNIX systems as well. There will be minor and subtle differences, such as varying directory names and different boot loaders, but it is essentially the same framework.

A network DMZ, or demilitarized zone, is a place between the Internet and an entity’s internal network. It is a place where a server can be set up on a different protected network segment. It provides a service to the outside, like FTP file hosting access for customers, a mail server for offsite personnel, webservers, or proxy servers, and shares this data internally through a protected funnel. This is desirable since if the DMZ server is compromised by a malicious person out on the Internet, they won’t have access to the rest of the internal network and it gives the internal IT people time to sever the external connection and fix the problem, clean the system, or rebuild the system without fear that he or she has already moved on to wreak havoc on the rest of the internal network.

You can set this up by using either a single or dual firewall approach. A single firewall approach requires the DMZ host to have at least 3 network cards. One card goes to the Internet Service Provider, the other goes to the DMZ host, and the third to the internal network router. The firewall needs to have enough computing power and memory to be able to handle the traffic and all associated filtering to and from the 2 network cards. A dual firewall approach is more secure and consists of 2 firewall computers or devices. One goes from the ISP to the DMZ machine or segment, while the second is on the back end and sits between the DMZ machine or segment and the internal network router. The IT staff can further mix things up by using different firewall vendors for each firewall so that neither has the same vulnerabilities and it can slow down and hamper attackers which could use the same methods to defeat both firewalls if they are identical.

Buffer overflow attacks are legendary in computer security. Programmers write lots of software which expects some sort of user input. This inputted data needs to be assigned an area of memory, called a buffer. The size of the buffer is assigned in anticipation of how much data will be provided to the input query. If the programmer hasn’t added checks to verify the size of the input data, then an attacker can provide so much data that it causes an overflow. In some cases the program just fails, but in other cases commands can be sent in with the overflow that are executed with the permissions of the host program, which can in many cases be root level access. This is why system services running as root are targeted by this sort of attack.

Code audits can sniff out vulnerabilities that would otherwise make this sort of attack easier. This is a case of an ounce of prevention being worth more than a pound of cure. In reality it is more than an ounce of prevention and is rarely done. The next best course of action is to regularly check system logs for suspicious activity. Filesystem integrity checking tools can assist in identifying if a system has already been breached by showing which files have been modified. The chroot jail could have prevented this because by running the service this way the attacker wouldn’t have had full filesystem access and most of the critical files would have been insulted from the attack. Many server programs now come with native chroot functionality.

Linux contains kernel modules which help to defend against this type of attack.

The chroot command is a shortened form of the two words, “change root”. What this command does is it allowes a sysadmin to rope off a section of the filesystem for users to play in. this is sometimes called a “chroot jail”, and I have heard it referred to as a “sandbox” or “user sandbox”. If a user logs in and it is set up to send them here, this area appears to them as the entire filesystem, but in reality it is really just a branch off the real filesystem. It contains only tose commands are directories that the sysadmin wants them to see and have access to. This allows a prudent and careful sysadmin to allow system access while not relying solely on the UNIX permissions model. It is another level of system defense. Think of it as allowing access in a “ned to know” way. They only see parts of the system that they “need to know”.

System services can be run in chroot mode since if a system service were to be the target of a buffer overflow attack, it could compromise the entire system of the perpetrator of the attack were then able to have access to the entire system sans the security that the attack immobilized. Had the attack succeeded and the service was not restricted to the chroot jail, the attacker would have a shell into the system which inherited the service’s permissions, which in many cases is root level access. If the attacker’s shell were limited to the chroot jail, their access to the system is very limited and the damage they can do is minimized. perhaps if they realized this they would just go away and look for a juicer unprotected target.