Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
I've set up a firewall on my Fedora Box using IPTables. The script performs various functions such as IPMasq and Port forwarding.
I've edited the /etc/inittab file to boot in a CLI.
However, it seems whenever a bad packet is receieved on eth01 (Internet IP) information is displayed on screen. These messages start with either "INPUT Packet Died" or "Invalid Packet", with more information (ie. source/destination)
How can I stop these messages appearing, as it's preventing me from doing anything.... someone please help!!!!
Check your /etc/syslog.conf file and see where kernel messages are being sent (look for kern.*). You can modify the setting and send them to /var/log/secure or /var/log/messages instead. Just make sure to read through your logs on a regular basis.
It's also a good idea to track down the source of the logged packets. Could you post a few (make sure to remove any public IP addresses). Also what firewall script are you using?
Last edited by Capt_Caveman; 08-02-2005 at 05:44 PM.
The -m switch just allows you to match certain parameters (like "state" matching or "limit" matching) that are included as netfilter extensions/modules. So by invoking -m you can then tell iptables to match packet states like "INVALID" or "ESTABLISHED". Checkout the iptables man pages for more info...
The "INPUT packet died" message is usually due to the "catch-all" rule at the end of the firewall that alerts you that the packet didn't match any rules in the firewall and was about to get dropped. Whether that is a good thing or a bad thing depends what that particular packet was. I can't tell what the packet was without see an example of one that was logged.
The "Invalid packet" message is telling you that a packet was received that had a connection tracking state of "INVALID". Normally connections fall primarily into one of 2 states, either "NEW" if it is just being established (e.g. the first incoming SYN packet of a connection attempt) or "ESTABLISHED" for the remainder of the connection until it's closed. There are other states, but they aren't really important here. However the "INVALID" state is kind of an oddball one in that it refers to packets that don't belong to any known connection. So if I sent an "ICMP host unreachable" message to your system and you didn't have any connection with me in your state table, that would be "INVALID". If you did have a connection with me in your state table then it would have been "RELATED" state. A number of things can generate packets that are "INVALID" and not all of them are malicious in nature. In particular things like NATed FTP connections can create them. So again, I'd need to see a sample message from you logs in order to make a guess.
That packet looks like part of a scan/probe so it's a good thing that it's getting dropped. In general that iptables script generates a lot of log messages. So you can either modify the script so that it's not logging dropped packets or you can send the log messages to a file. Personally I believe logging dropped packets is a good idea, so I would recommend the second option. To do so, edit the syslog.conf file and have the kern.* messages go to a file rather than to /dev/console (just replace the /dev/console with the full path to your destination log file). If you restart syslog (service syslog restart) you should see your log messages appearing there. However you'll still get them sent to the console by klogd as well. So you need to adjust the default klogd logging level using:
echo "3 4 1 7" > /proc/sys/kernel/printk
You can add that to /etc/rc.local to make it persistant over reboots. Make sure to review your logs on a regular basis so that you aren't missing important messages. If you want a more elegant solution, syslog-ng would probably be the way to go.
Also could you post an example of a packet getting logged as "INVALID" as identifying the source of those is a good idea.
Last edited by Capt_Caveman; 08-04-2005 at 10:22 PM.
The kern.* line is currently commented out, so at the moment kernel messages aren't being logged at all... the reason i'm getting these console messages is by klogd?
Yes. However if you simply increase the klogd console level, then you won't receive any log messages at all, which is a bad thing. That's why having syslog send them to a file is necessary.
Are all logs generated by IPTables kernel messages?
If so, how can i filter out IPTABLE log messages. Won't editing the syslog.conf file forward all kernel messages to the kern.* destination.
That's why it isn't a very elegent solution. There are ways around that, such as changing each of the iptables log rules so that they are logging at a specific level like "debug" so that you can simply pull those out by using "kern.debug" instead of kern.* in the /etc/syslog.conf file. Syslog-ng helps here cause it can do string based routing of log messages. You can also use a log parsing tool like swatch.