Stay Ahead With Linux Security Features
security advisory important The compromise of Nx Console shows how much infrastructure now sits behind a single developer account. GitHub repositories, CI/CD pipelines, container build systems, Terraform projects, Kubernetes deployments. None of those systems was the initial target. The workstation was. . Attackers did not need a Linux privilege escalation bug or a remote code execution chain. They needed developers to trust a tool they were already using. For many organizations, that was enough. What Happened? Federal...
Jun 03, 2026
security advisory open-source You remove the malware. You rotate the compromised credentials. You patch the original vulnerability and close the ticket. Two weeks later, the attacker is back. . What happened? You didn't lose the battle at the exploit; you lost it at the cleanup. In many modern Linux intrusions, the malware you found wasn't the main problem—it was the fallback mechanisms left behind. These hooks quietly restore attacker access the moment you look away. If you clean a host but miss these persistence layers,...
Jun 02, 2026
security advisory Red Hat Researchers investigating a campaign now tracked as Miasma found that more than 30 packages in Red Hat's @redhat-cloud-services npm namespace had been altered to deliver credential-stealing malware. . The packages weren't being used to deploy ransomware or sabotage systems. From what has been reported so far, the objective appears to have been much simpler: collect credentials from developer environments and use that access elsewhere. GitHub tokens, cloud credentials, SSH keys, and other...
Jun 02, 2026
cloud security security monitoring Linux rootkits are old, but they never really disappeared. They just stopped attracting the same attention. . Most malware wants to execute and spread. A rootkit wants to stay invisible long enough that nobody notices the compromise until the damage is already done, and on Linux systems, that still works more often than many teams are comfortable admitting. That difference matters because modern infrastructure runs heavily on Linux underneath. Cloud workloads, ESXi hosts, telecom appliances,...
Jun 01, 2026
access control open-source A production Linux server gets rebuilt from an old image. A contractor leaves. A CI/CD job is retired. Months later, the same SSH public keys are still sitting in authorized_keys, silently trusted by root or a service account nobody owns anymore. . That is how SSH key sprawl usually happens. It rarely stems from one obvious failure. Instead, it accumulates through years of small access decisions that never expire. For attackers, those forgotten keys are not clutter; they represent silent SSH...
May 27, 2026
Refine features
X Clear Filters
Get the latest News and Insights
Get the latest Linux and open source security news straight to your inbox.
Community Poll
What got you started with Linux?
Loading...
Explore Latest Linux Security features
We found 2 articles for you...
102
network securityfirewalliptablesHow to Configure Firewall-cmd for Enhanced Linux Network Security
Linux is more secure than other operating systems. But that's not the only reason why you might not need an antivirus or firewall while using Linux. . Linux isn't invulnerable . In fact, that's one of the most common cybersecurity myths that gets Linux users into trouble. This belief makes it easy to put your guard down, and when your guard is down, you're most likely to get sucker punched. But just because Linux has security holes doesn't mean you need antivirus or firewall software. Your choice of security settings will have been discussed in detail during the installation of your Linux system but you may not remember them by now. In this article, we will talk about configuring the firewall with the firewall-cmd command. What Is a Firewall? Firewalls are a key aspect of network security, thus a sysadmin should understand how they function. If you understand firewalls, you can keep your network safe by making informed decisions about which traffic to let in and out. A firewall is simply a filter that determines which network packets can come into your computer from the internet and which can leave your computer to the internet. It's mainly used to allow and/or disallow incoming connections. Outgoing connections are rarely filtered. In simple words, it is a sort of wall between your computer and the outside world. Does Linux Need a Firewall? This is nearly always a question. 99% of Linux users believe that Linux is secure by default. By default, almost all Linux distributions do not have a firewall. To be more precise, they have a dormant firewall. Because the Linux kernel includes a built-in firewall, and theoretically all Linux distributions include one, but it is not configured or active. But don't worry, even without an active firewall, your Linux is still safe. Most distributions, including Ubuntu and Linux Mint, have no open ports by default, ensuring that outsiders cannot access your machine. Nonetheless, I urge that you enable a firewall. It is preferable to be safe than sorry. We willfurther discuss how to configure the linux firewall using firewall-cmd. What Is Iptables? Iptables is a command-line firewall tool that allows or blocks traffic using policy chains. When a connection attempts to establish itself on your system, iptables searches its rule list for a match. If it cannot discover one, it falls back on the default action. iptables is nearly usually included with each Linux distribution. Iptables tends to use 3 different chains: input, forward, and output. With this, you can create different rulesets for different machines on the network, however, why not make it easier by using firewall-cmd! What Is firewall-cmd & firewalld? Firewall-cmd is a command-line interface for the firewalld daemon, which communicates with the Linux kernel's netfilter framework. This stack is unlikely to be found on the embedded modems commonly found in small and medium-sized enterprises, but it is present on or available for any Linux distribution that supports systemd. Firewalld is a dynamically controlled firewall that supports network/firewall zones, which specify the level of trust for network connections or interfaces. It supports IPv4 and IPv6 firewall settings, as well as ethernet bridges and IP sets. Runtime and permanent configuration choices are separated. It also provides an interface via which services or programs may easily add firewall rules. Configuring the Firewall with firewall-cmd Depending on your linux distribution, you may or may not have the firewall-cmd command already installed. Without an operational firewall, firewall-cmd has nothing to control, thus the first step is to check that firewalld is running: $ sudo systemctl enable --now firewalld Zones are used as presets in Firewall-cmd, offering you reasonable options to pick from. This saves you from having to design a firewall from the ground up. Zones are assigned to network interfaces. Run the command below to check your zones: $ firewall-cmd --list-all-zones If I wanted to create a new zone, I would use the command: $ sudo firewall-cmd --new-zone [zonename] --permanent Additionally, I can use the following commands to check which ports and services are allowed: $ firewall-cmd --list-services $ firewall-cmd --list-ports To check which zones are active, run the command: $ sudo firewall-cmd --get-active-zones To add a service and allow connections for that service, you use the –add-service argument as shown below: $ sudo firewall-cmd --add-service http --permanent The command above allows the http services to run in the default zone. If you want to specify the zone, you can run: $ sudo firewall-cmd --zone=public --add-service http --permanent The command above allows http traffic for the zone “public”. To remove a service and block the connection, just remove it like below: $ sudo firewall-cmd --remove-service http --permanent $ sudo firewall-cmd --reload Any time you make a change to the firewall using firewall-cmd, make sure to reload all the settings or else the change will not take effect. To check for additional arguments, you can run the command firewall-cmd –help. Why firewalld & firewall-cmd? You can do a lot more with firewall-cmd, such as define your own services, ICMP blocking, and designating sources of allowable incoming traffic. Although not overly suggested for enterprise-level security, firewall-cmd is still an excellent and viable solution for daily users and corporations alike that require a rapid degree of security. If you're new to Linux security, firewall-cmd is a wonderful way to get started with ipchains and iptables. Firewall-cmd allows you to quickly set up a basic firewall if you already know ipchains. Additionally, the runtime environment is readily modifiable. There is no requirement torestart the daemon or service. It is straightforward for services, programs, and users to modify firewall settings thanks to the firewalld D-Bus interface. This is useful for administrators since it allows for runtime testing and evaluation due to the separation of the runtime and permanent configuration. Final Thoughts The only time you'd need a firewall is if you're running some kind of server application on your system most of the time. In this case, a firewall will restrict incoming connections to certain ports, making sure that they can only interact with the proper server application. Again, there is no harm in not having a firewall activated on your Linux machine. All we are saying is that you should think about implementing a firewall using firewall-cmd for increased security! . Discover whether Linux requires a firewall and how to set it up with firewall-cmd for enhanced protection and effective network control.. Linux Firewall Management, Network Protection, Configure Firewalld, System Security. . Brian Gomez
Sep 19, 2022
•
102
security issuefirewallcyber attackDDoS Threats: Understanding the Limitations of Your Linux Firewall
Nowadays, Linux systems are considered fairly secure, as people think that Linux rarely gets infected with malware such as viruses, rootkits, worms, etc. You might also see that we hardly ever come across Antivirus software being sold for Linux, giving the illusion that Linux is an ultimately secure Operating System.. Given that roughly 75 percent of the world's servers run on Linux, we can’t truly believe that Linux is as secure as we think it is. Linux is only as secure as the person controlling and configuring it. Essentially, if a user has bad security practices, e.g. opening unauthorized emails or downloading potentially malicious links, then there is a very high chance that their Linux system will be compromised. A Linux firewall is defined as a solution or service that regulates, protects, and blocks network traffic as it passes to and from a Linux-based environment. Ultimately, it keeps your Linux systems secure by filtering certain network traffic that can be sent and received by the system itself. By default, Linux uses nftables, the successor of iptables, as a firewall and it does a fairly good job of keeping Linux Systems secure and mitigating potential attacks, especially if you have a good Security Engineer within your organization who is quite proficient with the tool. However, it does raise a very valid question: What attacks can’t this Linux firewall protect against? Whether you are using a paid firewall service or whether you are using the built-in iptables tool, there are just some attacks that the Linux firewall cannot protect against! Follow along with us as we go through what these attacks are and how they can affect your system. Nearly Impossible Attacks to Stop DDoS Attacks Like most cyberattacks, the deadliest ones come from within. Now with a normal DoS attack or DDoS attack, it can be managed and certain measures can be set in place to mitigate these attacks. The DDoS attack we will be talking about is a little more aggressive in terms of the methods it uses tosuccessfully execute the attack. We will be speaking on Reflection Attacks, specifically, reflected DoS and DDoS amplification attacks. I know you may be wondering what exactly is a Reflected Amplification attack but do not fear! Keep following along as we discover more about what they are. Reflected Amplification Attacks Reflection Amplification, simply put, is a combination of two techniques that allows cybercriminals to magnify the amount of malicious traffic they can generate and obscure the sources of the attack traffic. Let's split these two words to kind of get a better understanding. Reflection Attacks Simply put, reflection attacks are attacks that use the same protocol in both directions. The attacker spoofs the victim’s IP address and sends a request for information via UDP to servers known to respond to that type of request. The server answers the request and sends the response to the victim’s IP address. From the servers’ perspective, it was the victim who sent the original request. All the data from those servers pile up, congesting the target’s Internet connectivity. With the maximized bandwidth, normal traffic cannot be serviced and clients cannot connect. Any server open to the Internet and running UDP-based services can be used as a reflector. Amplification Attacks Amplification attacks increase the amount of data passing around. Essentially, an attacker uses a modest number of machines with little bandwidth to send fairly substantial attacks. Reflection /Amplification Attacks Together These two attacks alone can be fairly managed but when put together, not even the bests of firewalls can stop this, especially with a seasoned attacker behind the controls. They send a tremendous amount of spoofed packets causing systems to freeze, crash, or even reboot. The way an attacker carries on with this type of attack is actually through misconfiguration of the firewall in place. Almost all change and error is caused by human fault and in this instance, misconfigurationsof firewalls are the main culprit and reason for these types of attacks. Even then, if properly configured, you might still find yourself in the midst of a DDoS attack. Other Types of DoS/DDoS Attacks Buffer Overflow: Buffer Overflow attacks, as listed above, are a common type of DoS attack. It relies on sending an amount of traffi c to a network resource that exceeds the default processing capacity of the system. Ping of Death: Attackers send spoofed packets that ping every computer on the targeted network. The target responds and becomes flooded with responses from the malicious packet. It is also known as Internet Control Message Protocol (ICMP) Flood and Smurf Attack. SYN Flood: A SYN Flood attack exploits the TCP handshake – a method used for the TCP network to create a connection with a local host/client/server. Unfortunately, the handshake is left incomplete, leaving the connected host in an occupied status and unavailable to take further requests. Attackers will increase the number of requests, saturating all open ports and preventing anyone from connecting to the network. Teardrop: In a teardrop attack, IP data packet fragments are sent to the target network. The network then reassembles the fragments into the original packet. The process of reassembling these fragments exhausts the system and it ends up crashing. It crashes because the fragments are designed to confuse the system so it can never be put back together. If any of these other DoS/DDoS methods are used within a Reflection/Amplification attack, there is a good chance your Linux systems cannot withstand an attack of his magnitude. Misconfigurations in Web Applications Everyone that uses a web application has one thing in common, they are (mostly) all protected by a firewall. However, having a firewall doesn’t necessarily mean your system is secure. A firewall may be secure to the naked eye, but if it’s protecting a web application that has existing vulnerabilities, a Cyber Criminal can easilybypass it. There are countless examples of software vulnerabilities that hackers can exploit to bypass the firewall. Firewalls themselves also have vulnerabilities, normally caused by misconfiguration. Misconfigurations at the application layer, such as an error in configuring a WAF, can lead to a series of different attacks, such as SQL injections, CSRF, or even XSS. Furthermore, once the application vulnerability is exploited, it can lead to the Cyber Criminal gaining elevated access to the database, host server, and possibly more systems within a company. This is why it’s important to ensure to install the latest updates and patches and also, continually monitor events and logs. On top of staying up to date with updates and patches, as well as monitoring logs, you can invest in a good WAF. Malicious Scripts If an attacker manages to find their way onto your system, you would think your firewall or Intrusion Detection System would pick it up! Unfortunately, attackers have even managed to make their way around that. Nowadays, there are scripts that are meant to bypass firewalls and intrusion detection systems. Most Linux systems and servers deploy firewalls as a defense mechanism. In some malicious scripts, attackers try to disable the firewall (ufw) as a defense evasive tactic. Along with that, attackers also remove iptables rules (using iptables -F) because it is widely used for managing the firewall rules on Linux systems and servers. Another possible shell script would be one that disables certain Linux security modules such as SElinux, Apparmor, and other applications alike. These modules can be configured to grant users certain privileges and a seasoned attacker can create a script to manipulate these modules and grant themselves access as well. What Can YOU Do? I know we just went over nearly impossible attacks to defend against, so you must be thinking what can you possibly do?! Well, there are actually quite a few things we can do to mitigate these attacks. Follow along with the listbelow: Use up-to-date code dependencies, and third-party components, and update your web server/server Make sure you have recent security updates and patches installed for all software and hardware Properly configure any security tools and configuration files, such as PHP.ini and iptables, in your Linux environment Make sure that you have installed and properly configured an Intrusion Detection System Make sure to properly monitor any traffic that might seem suspicious Use vulnerability scanners to fully assess your web applications and your servers Limit any traffic to and from your server to malicious and black-listed IP addresses Properly educate yourself/your team on security protocols and stay up to date with recent malware/ransomware so you don't find yourself in a Zero-day attack If you follow along with this checklist and continually educate yourself on the possible vulnerabilities that are out there and that could potentially be in your system, you can properly mitigate most of these attacks. Our Thoughts As Cyber Criminals are using more sophisticated methods for attacks, it becomes increasingly important to monitor and record the activities happening on your system. It is important to have properly configured systems, firewalls, and all security features & patches updated to be able to properly defend against these types of attacks. It is a scary world out there and as everything becomes more digitized, we need to do our best efforts in keeping the systems that hold all our sensitive information safe. Make sure to check out our vulnerability basics (insert link here) article to further understand what vulnerabilities you might be encountering and make sure to check our WAF article to see how to keep your Web Applications secure! . As Linux systems gain traction globally, it's crucial to understand which threats can evade your firewall defenses and how to safeguard against these vulnerabilities.. Linux Firewall Attacks,DDoS Prevention,Security Best Practices.. Brian Gomez
Jul 27, 2022
•
102
network securityfirewallopen sourceFirestarter Firewall Installation Guide for Ubuntu Security
When I typed on Google . Introduction If I have an option of giving a brief description about firewall I would say . Discover methods to boost Ubuntu protection by implementing the Firestarter firewall along with essential configuration advice.. Firestarter Setup, Ubuntu Firewall, Network Management, Security Tips. . Brittany Day
Sep 25, 2008
•
102
security advisoryfirewallSELinuxEnGarde Community V3.0 Offers Major Security Enhancements
Guardian Digital is pleased to announce the release of EnGarde Community v3.0. This release represents the most significant number of improvements since the first version released more than four years ago. If you haven't tried EnGarde recently, then I'm certain you'll be equally as excited about this release as we are. Completely redesigned web interface, firewall functionality, integrated Security-Enhanced Linux protection, and completely free updates are just a few of the outstanding new benefits. . With EnGarde, you can build a complete and secure Internet presence featuring all standard Internet functions (web, DNS, email, etc) within minutes using one of the available Wizards.Interested in taking it for a spin? Download the ISO and use the "LiveCD" mode to test it alongside your current operating system to compare. No other Linux platform provides the security and ease-of-management available with EnGarde. Engineered from the ground up with security as a primary focus, EnGarde is protected from unauthorized access using multiple open source techniques. Here's a shortlist of features: Linux 2.6 kernel featuring SELinux Mandatory Access Control Guardian Digital Secure Network features free access to all system and security updates Support for new hardware, including 64-bit AMD architecture Web-based management of all functions, including the ability to build a complete web presence with FTP, DNS, HTTP, SMTP and more Apache v2.0, BIND v9.3, MySQL v5.0(beta) Completely new WebTool, featuring easier navigation and greater ability to manage the complete system Integrated firewall with ability to manage individual firewall rules, control port forwarding, and creation of IP blacklists Built-in UPS configuration provides ability to manage an entire network of battery-backup devices RSS feed provides ability to display current news and immediate access to system and security updates Real-time access to system and service loginformation For information on downloading EnGarde, please visit the community site: Guardian Digital Makes Email Safe For Business - Microsoft 365, Goo.... . Establish and protect your online identity effortlessly using EnGarde v3. Discover enhanced functionalities and upgraded safety measures.. EnGarde Community, Firewall Management, Security Features, Linux Distribution. . Benjamin D. Thomas
Sep 28, 2005
•
102
intrusion preventionsecurity measuresfirewallEnhancing Network Security With Netfilter's Content-Based Filtering
This article will discuss a very useful but seemingly overlooked functionality of Netfilter, a firewall code widely used in Linux, that provides content matching and filtering capabilities. . This feature is offered as patch to Netfilter kernel-space code (Linux kernel) and user-space code (iptables) Since version 1.2.7a, it's been made available as a separate package called patch-o-matic. Traditional network-level firewall can inspect packets based on IP addresses, ports, TCP/IP flags completely ignoring the content in the payload. Imagine, what you can do with a firewall that can inspect more than just headers but the content in payload of every packet. With that type of firewall, you can easily block malicious worms and viruses that , I believe, are still hiting your machine every minute of the day. More interestingly, there are tools that will convert snort signatures into iptables-aware format (even with hex string support), enabling intrusion prevention at the kernel space and stopping the attacks before they occur. Having said all that, I shall show you how to put things together: First thing you need to do is to grab all the required packages: Kernel source code which has Netfilter kernel-space code integrated and compatible with the latest Netfilter user-space code (version 2.4.18+) . The latest stable version can be downloaded at ( https://mirrors.edge.kernel.org/pub/linux/kernel/v2.4/linux-2.4.21.tar.bz2 ) Netfilter user-space code which is now iptables, (latest version is 1.2.8) but currently only version 1.2.7a supports hex string patch ( https://netfilter.org/projects/iptables/files/iptables-1.2.7a.tar.bz2 ) and the corresponding patch-o-matic package ( https://netfilter.org/projects/patch-o-matic-ng/files/patch-o-matic-20030107.tar.bz2 ) FWSnort, a perl script that will convert most snort rules into iptables rules. Don't forget to grab a hex string support patch that adds a hex-string capability to libipt_string.c to iptables source also. All these stuff areavailable at ( www.cipherdyne.com/fwsnort/ ) Unpacking them in appropriate directory: [tony@0x90 src]$ tar -jxf linux.2.4.21.tar.bz2 [tony@0x90 src]$ tar -jxf iptables-1.2.8.tar.bz2 [tony@0x90 src]$ tar -jxf patch-o-matic-20030107.tar.bz2 Apply libipt_string patch to iptables source and build iptables kernel and user spaces code: [tony@0x90 src]$ cd iptables-1.2.7a/extensions [tony@0x90 extensions]$ patch -p1 < libipt_string.c.patch [tony@0x90 iptables-1.2.7a]$ make KERNEL_DIR=../linux-2.4.21 [tony@0x90 iptables-1.2.7a]$ sudo make install KERNEL_DIR=../linux-2.4.21 Next step is to apply a string match support from a patch-o-matic package. A patch-o-matic is a series of Netfilter add-ons that provides extra functionality to original Netfilter. It has a nice automated script that will allow you to choose which patches you want integrated and checks their dependencies. You should be aware that,some patches might not work with one another, so carefully read the comments before you apply any patches. In this case, we will apply only string-match support patch: [tony@0x90 src]$ cd patch-o-matic-20030107 [tony@0x90 patch-o-matic-20030107]$ KERNEL_DIR=../linux-2.4.21 ./runme extra Welcome to Rusty's Patch-o-matic! Each patch is a new feature: many have minimal impact, some do not. Almost every one has bugs, so I don't recommend applying them all! ------------------------------------------------------- Testing... fuzzy.patch NOT APPLIED ( 2 missing files) The base/fuzzy patch: Author: Hime Aguiar e Oliveira Jr. Status: Under development , but works . This option adds CONFIG_IP_NF_MATCH_FUZZY, which allows you to match packets according to adynamic profile implemented by means of a simple Fuzzy Logic Controller (FLC) . Suppported options are: --upper-limit => Desired upper bound for traffic rate --lower-limit => Lower bound over which the FLC starts to limit traffic ----------------------------------------------------------------- Do you want to apply this patch [N/y/t/f/a/r/b/w/v/q/?] N This patch is not of our interest, so answer no (N) to go to the next one. Keep going until you find our string-match (-m string -string) patch and answer yes (y) to apply it: Testing... string.patch NOT APPLIED ( 2 missing files) The extra/string patch: Author: Emmanuel Roger Status: Working, not with kernel 2.4.9 This patch adds CONFIG_IP_NF_MATCH_STRING which allows you to match a string in a whole packet. THIS PATCH DOES NOT WORK WITH KERNEL 2.4.9 !!! ----------------------------------------------------------------- Do you want to apply this patch [N/y/t/f/a/r/b/w/v/q/?] y Testing patch extra/string.patch... Placed new Config.in line Placed new Configure.help entry Placed new Makefile line Patch extra/string.patch applied cleanly. Applying patch extra/string.patch... Patch extra/string.patch applied cleanly. Placed new Config.in line Placed new Configure.help entry Placed new Makefile line [Press enter to continue] Now, go back to the directory where you unpacked the kernel source and proceed with the compilation. (If you have compiled your own kernel before, you can just skip reading this section), Instructions on how to compileand customize your kernel can be read at (https://tldp.org/HOWTO/Kernel-HOWTO.html) [tony@0x90 linux-2.4.21]$ make mrproper && make menuconfig [tony@0x90 linux-2.4.21]$ make menuconfig [tony@0x90 linux-2.4.21]$ make dep && make bzImage [tony@0x90 linux-2.4.21]$ sudo make modules && make modules_install [tony@0x90 linux-2.4.21]$ sudo cp arch/i386/boot/bzImage /boot/vmlinuz-2.4.21 [tony@0x90 linux-2.4.21]$ sudo mkinitrd -f -v /boot/initrd-2.4.21.img 2.4.21 Finally, we are done with building all the components, reboot the system and enjoy your new toy. Now let's test this new functionality and use it as an active defense system: # This rule rejects all incoming mails with a string of "Buy Now" which many people consider it #as spam iptables -A INPUT -p tcp -dport 25 -m string --string "Buy Now" -j REJECT --reject-with tcp-reset # Blocks superscan ping but allows other types ping iptables -A INPUT -p icmp -icmp-type 8 -m string -string "|0000000000000000|" -j DROP # This will reset any connection that attempts to access a shell, in which you will find in most exploit codes iptables -A INPUT -p tcp -m string --string "/bin/sh" -j REJECT --reject-with tcp-reset Let's see if it works, on the server side execute nc -vv -l -p 23, on the remote host execute: telnet 10.0.0.1 23 Trying 10.0.0.1 Connected to 10.0.0.1 Escape character is '^]'. hello /bin/sh Connection closed by foreign host. # Thanks to hex string support, now we can easily block x86 NOOP sleds used in most buffer overflow exploits (use this with care, since it is possible that binary files transfer in e-mail may contain these strings and will get dropped!) iptables -A INPUT -p tcp -dport 22 -m string --hex-string "|90 90 90 90 90 90|" -j DROP iptables -A INPUT -p tcp -dport 80 -m string --hex-string "|90 90 90 90 90 90|" -j DROP You can try any buffer overflow exploits and will find that most of them get silently dropped! Now, you begin to have some idea on how to use this new feature as a content-based firewall system either for your local host or internal network. The FWSnort script that you have downloaded in the beginning will come into play as we will use it to convert some snort signatures into iptables rules. First unpack the source and install it: [tony@0x90 fwsnort-0.1]$ sudo perl install.pl Edit the configuration /etc/fwsnort/fwsnort.conf file to suit your needs and start the conversion: [tony@0x90 fwsnort-0.1]$ sudo fwsnort -c /etc/fwsnort/fwsnort.conf --ipt-drop A converted set of snort rules will be written to /etc/fwsnort/fwsnort.sh in a form of a shell script. Modify it again to suit your need , and merge it with your existing firewall rule. One thing you should keep in mind when working with a large iptables rules is that, everytime you perform an APPEND or INSERT, iptables will allocate a memory and invoke this function every time , resulting in a very slow performance. Iptables has a solution to this problem byproviding you scripts that will load a large rule set into the kernel very quickly or dump the current rule set from the kernel into iptables configuration file. So I suggest you first run your firewall script and then save it as iptables format using the command: iptables-save > /etc/syconfig/iptables Then whenever you need to reload the firewall rule-set you simply issue the command iptables-restore , and all rules will be reloaded in a much faster manner. Up to this point, you may think that if this functionality is so powerful, why doesn't anyone use it in replacement for snort? Although, Netfilter can perform a stateful inspection of content in a packet at the network level, it still lacks advanced capabilities in handling fragmented packets, polymorphic shell codes, traffic normalization, etc. Snort, on the other hands, can perform a pattern matching using a much faster algorithm called Boyer-Moore, supports a stateful packet analysis and stream reassembly. If you are interested in using snort as defense system, there is an ongoing honeypot project ( ) that uses a modified version of snort called snort_inline and a special set of firewall rules to achieve a hybrid firewall system. In conclusion, I would like to comment that intrusion prevention is still at its early stage and there is no out-of-the-box product that will perfectly fits your requirements. Every network has its own culture and usage behavior thus needs a distinctly unique tuning. Don't simply rely on a single tool but do correlate data from various sources and use them to understand your network and improve your security infrastructure. Nawapong Nakjang has been working in the areas of information security, network security and cryptography for several years. Hisinterests include intrusion detection, honeypots, incident investigation, malicious code analysis, computer forensics and penetration testing. Occasionally, he writes security-related article and answers security questions in mailing lists. He plans to pursue his second degree in Information Security and publishes more papers to the security community. . Network security is crucial as new threats emerge. Netfilter, a robust Linux firewall, enhances security with advanced content filtering and intrusion prevention. Netfilter Content Filtering, Intrusion Prevention System, iptables Configuration. . Brittany Day
Aug 04, 2003
•
102
network securityfirewallsecurity best practicesIptables Tutorial Insights From Oskar Andreasson on Linux Security
Oskar Andreasson speaks with LinuxSecurity.com about his comprehensive IP Tables tutorial and how this document can be used to build a robust firewall for your organization. . R ecently I had an opportunity to speak with Oskar Andreasson, author of the Linux IP Tables Tutorial Oskar announces his documents after spending the last several months writing and researching the information necessary to provide a Linux administrator with the information necessary to secure his Linux box. In his document, he discusses such topics the basics of configuring the kernel, configuring Red Hat to prepare for using IP Tables, a basic description of the iptables command, a number of great firewall examples, and more. LinuxSecurity.com: Why did you decide to write the iptables reference? Oskar Andreasson: When I started using Linux 2.4 I noticed a huge black hole in the documentation for the netfilter code and how to use it. Sure, there was the howtos written by Rusty Russell and the man page. There was no documentation at all describing how to get started, nor was there any examples available. During the time, I was also doing a lot of "work" for our site writing news and so on. I have always been proposing more material of our own on the BoingWorld site and since I found an area that I thought needed more/better documentation, I started writing. After some 1-2 months I had the first version of the tutorial published. It was quite small, only 20-30 pages or so, and didn't cover all the intricacies of iptables and the more I used iptables and tested it; the more things I found that needed documentation. In other words, I continued writing on the tutorial, and today it is much larger and contains much more information, to say the least. LinuxSecurity.com: Who are your target audience and why? Oskar Andreasson: Tricky question, I don't know really. At the beginning it was mainly aimed at the beginners and novices of iptables and who had a little bitof experience with TCP/IP networking as well as Linux basics. I still think the tutorial is aimed at those, but it contains more information today about the advanced functions of netfilter and iptables so it might be fairly well suited for the advanced users as well who might find some interesting reads in the tutorial. Of course, the tutorial also aims at the security interested people out there and anyone who might be interested in setting up a local network with Internet access. LinuxSecurity.com: How did you get started with Linux and security? Oskar Andreasson: Computer security has always intrigued me ever since I started using a PC for the first time around 1992 or so. Previously, I had used Amigas since I was 7-8 years old. In those days (Amiga days), it was mainly viruses I found interest in. Later on I got an Internet connection and got more and more interested in network security and, to be honest, different kinds of exploits, DoS attacks and spoofing. However, I was locked to a 486 50 MHz jar with 8 Megs of ram at the time and had no other OS than Windows 3.11 and MS-DOS 6.2. It was not until 93-94 or so that I started seeing Linux around and tested it. At the beginning, I can't say I liked it. The first time around I never got it to install at all. The second time around, "it" crashed my monitor (OK, I had to blame something, didn't I) and I had to get another monitor out on the warranty. After that it took a year or so until I tried getting Linux to run again, and by that time it had evolved incredibly (I could get it to install, isn't that evolution?). By that time, I went up to the second or third step on the ladder to becoming a "Linux Guru" (I got saved from the Windows hell and started preaching), and I think I'm still stuck somewhere around there. LinuxSecurity.com: What are your future plans for the iptables reference? Oskar Andreasson: Currently there are quite a lot of plans. As I said before, the moreI write, the more I find that I want to write about. This constitutes a small problem since I only have so many hours to write. As it looks now, I want to finish the chapter about how a rule is written, and then I want to add a chapter about the state machine. After this I need to go through the explanation of the rc.firewall.txt script again since the actual script has changed quite a lot but I haven't had the time to update the text describing the script. Then there is a request by some people that want to know how to make a transparent http proxy with iptables and squid. I know the last has already been described by the squid documentation, so it is not high priority right now, however I feel that it should at least be mentioned. One of the long-term goals of this project is actually to print a book of the whole tutorial and sell to the readers who liked the tutorial. This would not change the fact that the tutorial will be available on the Internet, it will always be. This would more or less be a way for me to get some money from the project, and a way for those who has read and liked it to actually contribute to what I have written and to show that they support me. Of course, I would have to see what kind of support I have among the readers/visitors for doing this before actually printing it. I hope that there will be at least a 200 persons or so willing to buy the printed version for a reasonable price. If so, I think it's worth printing a series. If not, well, it would be sad if not even 200 persons liked it enough to actually buy it. LinuxSecurity.com: What are some of the major pitfalls Linux Administrators fall into? How can your iptables reference help to avoid these problems? Oskar Andreasson: One of the main problems of Linux today is in my way of seeing things, that there is a huge lack of documentation, especially when you start digging into the deeper aspects of Linux. Also, some commands and functions are clearly not documentedenough. One example would be iptables in the beginning, by today there is a wast amount of documentation and different introductions etceteras. Another example that I have noticed is the iproute2 package, which in my way of seeing things is one of the most complex and hardest to understand packages for Linux that is available today. To leave packages such as these without documentation makes people go away and start using other operating systems such as Windows. To leave these extremely powerful parts of Linux undocumented should almost be criminal, it is horrendous to see these parts undocumented. Sure, there are a lot of pieces of information available out there, but a lot of it raises more questions than they answer. My answer to the first question would, hence, be that they might do errors due to a lack of documentation. These errors might be unknown to the Linux administrator for a long time and, in the long run they may notice the error to late. For example, after the hacker/cracker found the erroneous set-up and exploited it. What I hope that this tutorial do, is that it gives people new knowledge about the Linux firewalling possibilities, how they work, and a general knowledge of how to set it up properly. I hope that the iptables-tutorial give Linux administrators the possibility to easily learn about netfilter and iptables and in an as complete document as possible. LinuxSecurity.com: What do you feel is the most common Linux system vulnerability? What can be done to prevent this? Oskar Andreasson: I don't think there is a single most common Linux system vulnerability, and it will definitely not stop a determined attacker. If you have fixed the most common vulnerability and someone is determined to get into your host, then you can be certain that the attacker will leave the second most common vulnerability out, or the third for that matter. However, good security practices on a server includes installing only the absolutely necessarypackages. For example, if a box is supposed to run as only an DNS and HTTP server, well keep it to the A, N and D Slackware packages, and do the expert installation and select which packages you want exactly. For Red Hat, do the same thing select the installed packages. When finally installed, erase everything not needed, including the man reader. All you really should need is a text editor, HTTP, SSH server, DNS, login programs and all the standard ls, cd commands etc. The fewer packages we have to keep up to date, the less work to maintain and to keep it up and running. After this, it is all a matter of keeping those few packages you have installed up to date. Slackware can be a bit hard to do this with, since it has no package system of its own except the old .tgz packages and installer, and there is no real "errata" site for it to my knowledge. Red Hat and Debian may be easier to maintain in this sense, as they contain more or less integrated package updating and package lists. On the other side, this may be a bad thing for the really hard working administrator who wants to keep his packages up to date by hand, and who does it faster than Red Hat and Debian, for example, updates their packages. Also, a nice firewall will always be handy when it comes to security. Iptables is an excellent choice when it comes to this, though it takes a lot of work to get it up and running in comparison to some Windows firewalls (BlackIce Defender, etc.), it is extremely versatile and can do pretty much whatever you want to. However, a firewall is never near good enough based on only a packet filtering mechanism. I would suggest at least installing a NIDS (i.e., snort) and an IDS (i.e., tripwire) on the same box. At the top of that, if you're really security conscious, I'd suggest using kernel security patches and such. LinuxSecurity.com: Do you believe the open source nature of Linux provides a superior vehicle to making security vulnerabilities easier to spot and fix? Oskar Andreasson: I most definitely think so. Open source gives everyone the chance to look at the source code, and it becomes easier to spot errors for a third party, and hence report to the producer. A person using an open source product is more likely to actually look at the code and to try and fix the problem, and then send the bug over to the developer, in my own experience. Of course, there are those who don't report the bugs, and instead start using it to their own advantage (for example, hack sites with the bug and so on). However, the percentage of users doing the latter is a dwindling small amount of people, I think. Closed source on the other hand is harder to debug for a third party, and if you really do find a bug, you are more likely to just throw the bug on the crap pile and hope for it to be fixed in the next release, they don't feel anything in common for the actual development of the product nor do they actually have a good reason for telling the developers about the bug. In open source, you can have the problem fixed within 3 minutes by yourself and have a bug report sent away and how to fix it, in closed source, you find a bug, send a bug report and then sit down and wait for 2-6 weeks before anything happens. Finally, you get a reply that this is not a bug; this is a feature(TM) (strangely enough removed in the next version of the program). LinuxSecurity.com: Are there other documents you have written that you think might be beneficial to the Linux and open source security communities? Oskar Andreasson: Yes, I think there is. I have currently written an online course about Linux and Unix for a company called Libendo. This is about the same size as the iptables tutorial, but is elementary and guides a total new user to Linux through their first experience. This is one of the more peculiar basic documents written about Linux, I believe since it is 100% based on the shell, and there is more or less no graphical user interfaceused throughout the whole course. I believe that this course may actually hold a lot of interest even for the Linux zealots out there who may not have a lot of experience with the console of Linux. If there is any Swedish speaking people, I suggest them to check out in a couple of months when this course goes online. I have also started another project on my spare time, to document the iproute2 package and its uses. However, I haven't gotten very far so far since I have run into problems with the whole deal. Anyway, my aims with this documentation is to get more people to understand the extremely advanced routing functionalities that really are part of Linux. Some good examples of what this document will contain is explanations on how the ip command works and the syntax, how all the different options and flags to the command is used and information on how each "subcommand" works. I haven't put a lot of time into this project so far, mainly because I want to finish up a lot of loose ends with the iptables tutorial before walking into another huge project. I think that this project will look a lot like the iptables tutorial when it gets going, especially in writing style and how it will be built up with a lot of examples among other things. However, I don't plan to get this project really moving until the iptables tutorial has stabilized, in perhaps 2-3 months. LinuxSecurity.com: Is there something the community can do to assist you with writing and maintaining your security research? Oskar Andreasson: There is actually something people could do to contribute to this tutorial. I am in an extreme need for a lab network at the moment since I lost the main part of it when I moved 5-6 months ago. At the moment of writing this, I have only two computers available, one Pentium 200 MHz MMX and one Pentium 120 MHz laptop. If anyone living in Sweden (Stockholm) knows about a party of 4-5 computers of any type that some company or private person is willing to giveaway, either as junk, or just as a contribution, I will owe them extremely much. Any kind of computer would suffice, even Pentiums at the moment, as long as I can have a few network cards with them (9 or so, but less would suffice too). My private budget would not in any way make this possible at this stage, and to be able to finish both the iptables tutorial, and the iproute2 tutorial this would be more or less necessary. LinuxSecurity.com: Oskar, thanks much for your time, and we look forward to reading your future Linux security documents. . Explore Oskar Andreasson's teachings on the critical need for thorough iptables documentation to enhance security on Linux firewalls, emphasizing organized rules and clarity.. iptables Tutorial, Firewall Security, Linux Network Administration. . Brittany Day
Nov 27, 2001
•
102
firewallsecurity featurepacket filteringLinux Kernel 2.4 Netfilter Enhancements: Secure Packet Filtering Features
In yet another set of advancements to the kernel IP packet filtering code, netfilter allows users to set up, maintain, and inspect the packet filtering rules in the new 2.4 kernel. This document explains those changes and tips on how to get started. . The netfilter subsystem is a complete rewrite of previous packet filtering implementations including ipchains and ipfwadm. Netfilter provides a large number of improvements, and it has now become an even more mature and robust solution for protecting corporate networks. Netfilter provides a raw framework for manipulating packets as they traverse through various parts of the kernel. Part of this framework includes support for masquerading, standard packet filtering, and now more complete network address translation. It even includes improved support for load balancing requests for a particular service among a group of servers behind the firewall. The stateful inspection features are especially powerful. Stateful inspection provides the ability to track and control the flow of communication passing through the filter. The ability to keep track of state and context information about a session makes rules simpler and tries to interpret higher-level protocols. Additionally, small modules can be developed to perform additional specific functions, such as passing packets to programs in userspace for processing then reinjecting back into the normal packet flow. The ability to develop these programs in userspace reduces the level of complexity that was previously associated with having to make changes directly at the kernel level. Packet Filtering Intro: Packet filtering, sometimes called filtering gateways or screening routers, is a component of a firewall system that either permits or denies packets from passing through it based on a pre-defined policy. It examines the packet for source and destination information, as well as ports, such as telnet or ftp, and either permits it to pass or otherwise rejects it. For example, a firewall policy (typically called "rules") may be defined to permit incoming http access to a particular host, but deny access from other hosts. The packet simply traverses the list of rules until it matches a pattern -- one that either permits it or rejects it. The advantages of packet filtering are that they are fast, flexible, and inexpensive. A 486 with 16 megabytes of RAM and two ethernet cards can be converted into a packet filtering firewall that can protect a large number of hosts behind it. They also typically provide a good deal of logging information which can be crucial to tracking a potential intruder. The advantage of packet filtering is also one of its disadvantages. The packet filter does nothing to analyize the contents of the packet to determine if there is any malicious content within it. It simply routes based on a predefined set of rules. Another disadvantage is that it operates based on the information contained in the packet header, and can make no decisions based on the user accessing the remote resource. There is no built-in authorization mechanism. The final disadvantage is that while it's flexible, it's also difficult to maintain. Often times on networks with many hosts to protect, the set of rules become unwieldy and difficult to manage. An intimate knowledge of the underlying IP protocols must be understood in order for the firewall to be effective. A misunderstanding of how one of the protocols work, or even an inadvertant configuration change can lead to undesired consequences. This is obviously an issue with any security system, but a misconfiguration could easily go unnoticed. As mentioned in the initial sentence, packet filtering is a component of a firewall system. For a more robust solution, combine packet filtering with an application level gateway program such as squid . Basic Packet Filtering: It's now possible to match on owner, group, system ID, or process ID of a connection, allowing you to matchlocally-generated packets based on who created them. This would be great for restricting outgoing connections on an ISP machine, for example. The packet filtering in 2.2 kernels provided the ability to limit spoofed packets from entering the network. Packets originating on the internal network should not appear to be entering the external firewall interface. The 2.4 kernel expands on this support by providing an 'unclean' extension that checks for such suspicious packets, as well as other types of malformed or non-standard packets, and sends them to the bit bucket. In previous versions of the packet filtering code, it was only possible to determine whether the SYN flag was set, indicating whether or not the packet was an established connection or the beginning of a new connection. The new packet filtering code allows you to filter on specific TCP flags, not just the SYN flag. This permits a much greater level of control over the packets that can enter or leave your network. For example, to examine all six TCP flags, checking specifically for the SYN and ACK flags to be set: # iptables -A INPUT -p tcp --tcp-flags ALL SYN,ACK -j DROP Additionally, it is also possible to filter on MAC address. This is used for matching incoming packet's source Ethernet (MAC) address. The ability to match TCP or UDP packets based on a series of source or destination ports is also now available. Previously, a rule could only match a single range of ports. This might be used to set up a filter to block telnet, ftp, and finger, for example: # iptables -A input -t DENY -p tcp --destport telnet,ftp,finger Finally, no longer do return packets appear to be destined for the server itself on input filtering and appear to be originating from the server itself on output filtering. Filtering Modules: Netfilter includes several shared library add-on modules that provide additional functionality not found in previous packet filtering versions. Eachrule target is a separate module, allowing for easy expansion. In addition to the standard REJECT, DENY and ACCEPT, there are several other targets including: TOS: This option adds a "TOS" target, which allows you to create rules in the "mangle" table which alter the Type Of Service field of an IP packet prior to routing. MIRROR: Reverse source and dest and send back out to the sender. MARK: This target allows you to create rules in the "mangle" table which alter the netfilter mark field associated with the packet prior to routing. This can change the routing method and can also be used by other subsystems to change their behavior. MASQUERADE: Masquerading is a special type of NAT and the one most of us are familar with from ipchains. All outgoing connections are changed to seem to come from a particular interface's address, and if the interface goes down, those connections are lost. DNAT: This target specifies that the destination address of the packet should be modified. SNAT: This target specifies that the source address of the packet should be modified, including all future packets in this connection. REDIRECT: Redirect is another special type of NAT. All incoming connections are mapped onto the incoming interface's address, causing the packets to come to the local machine instead of passing through. This is useful for transparent proxies. For example, to redirect traffic originating from the 192.168.1.0 network destined for the 192.168.1.1 web server to the 192.168.1.100 server, we might run the following command: # iptables -t nat -A POSTROUTING -s 192.168.1.0/24 \ -d 192.168.1.1 -p tcp --dport 80 -j DNAT \ --to 192.168.1.100 The iptables extended packet matching modules supply additional capabilities in the form of shared library add-ons and small kernel modules that provide additional functionality. Stateful Inspection: Thenetfilter framework now includes stateful inspection, also referred to as stateful filtering or sometimes dynamic filtering. This connection tracking mechanism provides the ability to associate all the packets of a particular connection with each other. Stateful inspection attempts to interpret the higher level protocols such as NFS, http and ftp. The behavior of the firewall changes based on the information contained in the packet. If the packet contains information in the header that indicates it is part of an existing connection, and it matches a rule that states it's a permissable service, then it is permitted to pass through the firewall. Previous implementations had no way of knowing if a particular connection to one of those ports were associated with a legitimate connection or was an arbitrary connection, as would be the case with a port scan or malicious hack attempt. Many protocols attempt to allocate arbitrary ports for their data to be passed through. Previously there was no alternative but to poke holes in the firewall to allow these arbitrary ports access should there be a connection that requires it at some point during a connection. The new firewalling code allows the firewall to open ports only long enough for that particular packet on an arbitrary port to pass through it. This greatly increases the overall security of the hosts behind it and is a component of nearly every major commercial firewall implementation. At the same time, it also greatly reduces the window of opportunity for blackhats to attempt to pass malicious packets through the firewall, despite the source and destination ports and addresses being known. This allows only packets that are recognised as being part of an established connection to pass, instead of previously only depending on destination address and port. This also helps to thwart an attacker's attempt at using packets with modified headers that would have previously subverted astateless packet filtering firewall. Rules can now be created to base their routing decision on one of the following states: NEW: This packet is trying to create a new connection RELATED: This packet is related to the existing connection, and is passing in the original direction INVALID: This packet doesn't match any connection ESTABLISHED: This packet is part of an existing connection RELATED+REPLY: This packet is not part of an existing connection, but is related to one, such as an ftp-data transfer when there is already an ftp-control session to that host As a simple example, to forward across the firewall interfaces packets that are part of a pre-existing connection might look like this: # iptables -A FORWARD -j ACCEPT -m state \ -state ESTABLISHED,RELATED While stateful inspection provides much better performance than an application gateway such as squid, and also increases the level of protection over a simple packet filter, they can be as deceptively difficult to set up and maintain. It also may potentially require more memory to store the state information than a standard packet filter. Also, unlike application gateways such as squid, a direct connection is still made with the internal hosts which are being protected, exposing them to the exploitable weaknesses present on that host. Address Translation: Network Address Translation (NAT) is the process of converting one or more IP addresses into another IP address. This is most commonly seen through the use of "IP Masquerading" where a home or internal network is translated into an IP address that is routable on the Internet. The new packet filtering code in the 2.4 kernels include a much more robust form of address translation. The 2.4 kernel packet filtering now supports a one-to-one, many-to-one and even many-to-many IP address and port translation. In the simplest case, an internal address may be translated into one that is addressable on the Internet. Previously, this may have been done using something of the form: # ipchains -A forward -j MASQ -s 192.168.1.0/24 -d 0/0 This will convert all IP addresses from the 192.168.1.0 network into the address of the external interface of the box it is running on. From there, an entry is made in the internal kernel data structures that tracks the connection and associates it with the particular host from which it originated. This form of proxying is very easy to set up and provides a great solution for internal users with a limited number of Internet-routable IP addresses. While the masquerading support is still functionally equivalent to its predecessors, additional forms of address translation are now available. The new packet mangling code provides additional forms of translation including the ability to translate the source or destination addresses of a packet, the ports associated with the connection, port forwarding and transparent proxying. Suddenly, with the addition of this improved NAT, load-balancing, fault-tolerance and even high-availability become obtainable. Specifically, the following new NAT options are available: DNAT: This target specifies that the destination address of the packet should be modified. This is a great way to load-balance a connection request amongst several destination servers. SNAT: This target specifies that the source address of the packet should be modified, including all future packets in this connection. REDIRECT: This is a specialized case of DNAT that alters the destination IP address to send the packet to the machine itself. This is useful in circumstances where one wishes to redirect web traffic to a local proxy server, such as squid. Packets that have had either their source or destination addresses translated will then be retranslated on their return trip, so they are sure to be delivered back to the host with the real IP address. So, to develop asimple and inexpensive load balanacing solution, you might use the following to have your firewall redirect some of the traffic to each of the web servers at 192.168.1.100, 192.168.1.101 and 192.168.1.102, as follows: # # Modify destination addresses to 192.168.1.100, # 192.168.1.101, or 192.168.1.102 # iptables -t nat -A POSTROUTING -i eth1 -j DNAT \ --to 192.168.1.100-192.168.1.102 Other modules exist to do application-specific address translation and extensive documentation exists on how to write these modules. Packet Mangling: Packet mangling is the ability to change or modify packets both before they are routed and after routing has been decided, specifically, the PREROUTING and POSTROUTING subtables. Type of Service One example of packet mangling is the ability to prioritize traffic from separate queues, changing the "Type of Service" value in the packet before it is routed on to its final destination. The Type of Service values can be one of the following: Minimize-Delay Maximize-Throughput Maximize-Reliability Minimize-Cost Normal-Service For example, to provide interactive performance to telnet while using ftp at the same time: # iptables -A PREROUTING -t mangle -p tcp --sport telnet \ -j TOS --set-tos Minimize-Delay # iptables -A PREROUTING -t mangle -p tcp --sport ftp \ -j TOS --set-tos Minimize-Delay # iptables -A PREROUTING -t mangle -p tcp --sport ftp-data \ -j TOS --set-tos Maximize-Throughput Logging: Netfilter improves on previous versions by providing the ability to restrict the rate of matches, such as for suppressing extensive log messages, for example when a host makes a number of connections in a predefined interval. This can help to prevent some types of denial of service attacks. The detailed logging that netfilter provides enables a firewall administrator to not only troubleshoot potential system problems, but also to tracka potential intrusion, and correlate it with other systems and events. The example below shows how to reduce the number of packets originating from the 192.168.1.1 host that are logged: # iptables -A INPUT -s 192.168.1.1 -m limit --limit 1/second -j LOG It is also possible to log messages at different log levels and with different prefix notes: # iptables -A INPUT -s 192.168.1.1 -j LOG --log-prefix ' ##Router## ' This will log all traffic originating from the 192.168.1.1 host and prepend the string " ##Router## " to each entry. It produces the following log output: Jan 28 23:18:42 magneto kernel: ##Router## IN=eth0 OUT= MAC=00:60:67:36:9b:c8:00:60:67:30:ac:e5:08:00 SRC=192.168.1.1 DST=192.168.1.206 LEN=312 TOS=0x10 PREC=0x00 TTL=64 ID=9189 DF PROTO=TCP SPT=22 DPT=1023 WINDOW=32120 RES=0x00 ACK PSH URGP=0 Additionally, it also provides the ability to log packets based on many other criteria. More information in logging in general (MAC address, etc). A rule such as the following: # iptables -I INPUT -m mac --mac-source 00:60:67:30:AC:E5 -j LOG produces log output similar to the following: Jan 28 23:15:19 magneto kernel: IN=eth0 OUT= MAC=00:60:67:36:9b:c8:00:60:67:30:ac:e5:08:00 SRC=192.168.1.1 DST=192.168.1.206 LEN=528 TOS=0x10 PREC=0x00 TTL=64 ID=7738 DF PROTO=TCP SPT=22 DPT=1023 WINDOW=32120 RES=0x00 ACK PSH URGP=0 Jan 28 23:15:19 magneto kernel: IN=eth0 OUT= MAC=00:60:67:36:9b:c8:00:60:67:30:ac:e5:08:00 SRC=192.168.1.1 DST=192.168.1.206 LEN=528 TOS=0x10 PREC=0x00 TTL=64 ID=7738 DF PROTO=TCP SPT=22 DPT=1023 WINDOW=32120 RES=0x00 ACK PSH URGP=0 Final Notes: In this article we've covered a majority of the new features available in the new filtering code available in the 2.4 kernel. There are a number of other changes that make using the packet mangling code easier than previous versions. Previously, the forward chain only had information on the outgoing interface, making it more difficult todetermine where the packet came from. It's now possible to create packet filter rules independant of interface address. It's no longer necessary to bind a rule with an interface. It's now possible to specify the "in" interface or the "out" interface for basing filtering decisions. Ipchains and ipfwadm modules exist for backward compatibility with the old systems. Note that you can only have one loaded at a time. You can't have ipchains and some new iptables rules. Acknowledgements: I'd like to express thanks to Kevin Fenzi, my Security HOWTO co-author, and Harald Welte, author of much of the documentation we have today on netfilter, for accuracy-checking my document. Thanks to Benjamin Thomas for proofreading. Any errors are either due to transmission problems or fault of my own, though ;) Related Resources: Netfilter Mailing list: Send a message to
Feb 14, 2001
•
Get the latest News and Insights
Get the latest Linux and open source security news straight to your inbox.
Community Poll
What got you started with Linux?
Search Topics
Powered By
Linux Security - Your source for Top Linux News, Advisories, HOWTOs and Feature Releases
QUICK LINKS
subscribe to newsletters!
Like staying secure? So do we.
Sign up for updates, tips, and alerts!
Explore top 10 tips to secure your open-source projects now. Read More