Adding static routes in Linux can be troublesome, but also absolutely necessary depending on your network configuration. I call static routes troublesome because they can often be the cause of long troubleshooting sessions wondering why one server can't connect to another.
This is especially true when dealing with teams that may not fully understand or know the remote servers IP configuration.
The Default Route Linux, like any other OS has a routing table that determines what is the next hop for every packet.
Recently I was compiling a list of Linux commands that every sysadmin should know. One of the first commands that came to mind was nmap.
nmap is a powerful network scanner used to identify systems and services. nmap was originally developed with network security in mind, it is a tool that was designed to find vulnerabilities within a network. nmap is more than just a simple port scanner though, you can use nmap to find specific versions of services, certain OS types, or even find that pesky printer someone put on your network without telling you.
In a world where the Anonymous group is petitioning the US Government to make DDoS attacks a legal means of protest; For internet facing systems the threat of Denial of Service attacks are very real.
The cold harsh reality of DoS attacks are that there is no way to stop them. While there are services out there that are designed to take the brunt of the attack for you these costs a significant amount of money (update: CloudFlare seems pretty decent).
For today's article I am going to explain how to create a basic firewall allow and deny filter list using the iptables package. We will be focused on creating a filtering rule-set for a basic everyday Linux web server running Web, FTP, SSH, MySQL, and DNS services.
Before we begin lets get an understanding of iptables and firewall filtering in general.
What is iptables? iptables is a package and kernel module for Linux that uses the netfilter hooks within the Linux kernel to provide filtering, network address translation, and packet mangling.
In one of the first posts of this blog I covered some basic SystemTap functionality from an email that I sent to members of my team, but I have always felt that I haven't given SystemTap as thorough of an article as this incredible tool deserves. Today I want to correct that.
For today's article I will show how to compile SystemTap scripts on one server while running the compiled module on a production server without installing debug-info or devel packages in production.
Have you ever said to yourself, “man I really need to slow down my internet”?
Probably not very often, but recently I found myself in a dilemma where I needed to simulate 120ms of network latency in my test environment which consists of servers that are racked right next to each other. That is where the command tc comes in.
Within the current distributions of Linux there is a kernel component called netem, which adds Network Emulation and is used for testing and simulating the same types of issues one would see in a WAN (Wide Area Network).
Whenever I perform any type of activity that requires me to look at historical system statistics such as load average, CPU utilization, I/O wait state, or even memory usage; I usually skip the System Monitoring Applications like Nagios or Zenoss and start running the sar command. While I'm not saying that sar completely replaces those tools, I am saying that sar is quick and dirty and if all you want is some raw numbers from a certain time frame; sar is a great tool.