LinuxQuestions.org
Help answer threads with 0 replies.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Security
User Name
Password
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.

Notices

Reply
 
Search this Thread
Old 10-18-2011, 03:59 PM   #1
fruittool
LQ Newbie
 
Registered: Oct 2011
Location: Stoke on Trent, UK
Distribution: Debian
Posts: 6

Rep: Reputation: Disabled
Netfilter - analyse dropped packets


Hi all.
I have a headless box as the gateway to my network.
I have a bunch of specific netfilter rules with a default drop in my input chain.
I have used the log rule at the end of the chain to log packets before they are dropped.
But,
What i really want to do is capture the entire raw packets before dropping and analyse them remotely.

Is there anyway to do something like this?
 
Old 10-18-2011, 05:42 PM   #2
kbp
Senior Member
 
Registered: Aug 2009
Posts: 3,758

Rep: Reputation: 644Reputation: 644Reputation: 644Reputation: 644Reputation: 644Reputation: 644
Sounds like you want an IDS...
 
Old 10-18-2011, 06:24 PM   #3
unixfool
Member
 
Registered: May 2005
Location: Northern VA
Distribution: Slackware, Ubuntu, FreeBSD, OpenBSD, OS X
Posts: 781
Blog Entries: 8

Rep: Reputation: 157Reputation: 157
Quote:
Originally Posted by kbp View Post
Sounds like you want an IDS...
Yep, what kbp said. You won't be able to have netfilter do this. And while you can log with Snort/tcpdump, correlating the snort/tcpdump (ascii, not pcap) logs with the firewall logs can be a rather tedious process (you might be able to script that process).
 
Old 10-18-2011, 06:50 PM   #4
unSpawn
Moderator
 
Registered: May 2001
Posts: 27,671
Blog Entries: 54

Rep: Reputation: 2953Reputation: 2953Reputation: 2953Reputation: 2953Reputation: 2953Reputation: 2953Reputation: 2953Reputation: 2953Reputation: 2953Reputation: 2953Reputation: 2953
A pcap app sees packets before Netfilter does. That shouldn't matter if you can create a BPF filter to compensate for accepted traffic or if you use Snort DAQ which uses NFQUEUE. Netfilter itself provides targets like ULOG / NFLOG and (NF)QUEUE to copy packets which userland apps can read or store and decide routing.

Last edited by unSpawn; 11-06-2011 at 10:05 AM. Reason: //Typo
 
1 members found this post helpful.
Old 10-18-2011, 07:24 PM   #5
unixfool
Member
 
Registered: May 2005
Location: Northern VA
Distribution: Slackware, Ubuntu, FreeBSD, OpenBSD, OS X
Posts: 781
Blog Entries: 8

Rep: Reputation: 157Reputation: 157
Quote:
Originally Posted by unSpawn View Post
An pcap app sees packets before Netfilter does. That shouldn't matter if you can create a BPF filter to compensate for accepted traffic or if you use Snort DAQ which uses NFQUEUE. Netfilter itself provides targets like ULOG / NFLOG and (NF)QUEUE to copy packets which userland apps can read or store and decide routing.
This is already going on a tangent, here, but let me explain.

I'm well aware of the BPF option/capability. And also, if there's a firewall in front of the sniffer/IDS, that sniffer/IDS will see nothing. If you're talking about running a sniffer/IDS on the same box/interface as the firewall, yeah, of course, the IDS will see what the firewall dropped. I didn't remember saying that it couldn't be done. I was just suggesting to the OP of the complications he/she may face. Correlating FW and snort logs may be easy to us folk that can use such tools in their sleep, but there are some people that will have difficulty.

IMO, ASCII files are easier to search, because you can grep the file...they're just flat files. You can't grep a pcap (well, you might be able to, but it won't look pretty and you're not going to see what you think you're gonna see). Sure, you can use Wireshark or any other pcap reader (I mentioned snort and tcpdump in my previous post), but IMO, nothing beats grep for quick-fast glimpses of files. I guess I prefer being able to view the capture with the least amount of limitation or complication. I can take an ASCII dump and view it on a system I don't own, even if that system doesn't have a pcap reader....can't do the same thing with a pcap file, though. This comes from me time-sharing computer systems at work the last 10 years (without having admin/root access to those machines). On some of my servers, I configure my snort process to do both pcap and ASCII, in case my ASCII capture is lacking. I acknowledge that in some cases, BPF is better, but again, I don't like to be stuck with a file I can't view when supporting a client on a machine I don't have control over.

Last edited by unixfool; 10-19-2011 at 08:08 AM.
 
1 members found this post helpful.
Old 10-18-2011, 07:49 PM   #6
OlRoy
Member
 
Registered: Dec 2002
Posts: 304

Rep: Reputation: 86
I'm not entirely sure the reason for analyzing the packets. Whether it's for some kind of audit of the firewall, or to detect incidents. If it's the latter, you should understand that traffic that is blocked, probably isn't going to hurt you. It's the traffic you allow that you really need to inspect with an IDS.
 
Old 10-18-2011, 09:07 PM   #7
unSpawn
Moderator
 
Registered: May 2001
Posts: 27,671
Blog Entries: 54

Rep: Reputation: 2953Reputation: 2953Reputation: 2953Reputation: 2953Reputation: 2953Reputation: 2953Reputation: 2953Reputation: 2953Reputation: 2953Reputation: 2953Reputation: 2953
Uh. I was just informing the OP wrt your "You won't be able to have netfilter do this" but thanks for the explanation.
 
Old 10-18-2011, 09:38 PM   #8
fruittool
LQ Newbie
 
Registered: Oct 2011
Location: Stoke on Trent, UK
Distribution: Debian
Posts: 6

Original Poster
Rep: Reputation: Disabled
Thanks for the suggestions,
I'm going to have a read up on bpf and Snort DAQ.
My first idea was to use wireshark remote capture and filter out packets according to the accept rules i had but, i cant get the remote capture daemon to work. It just keeps kicking the connection.

The reason i want to do this is because my filter rules are pessimistic and restrictive. Every now and then something wont work because packets are being dropped, so it would help in separating what i do want from what i don't want. Also, i'd like to be able to see in depth, what 'crap' is being fired at me from the wan side and, on the lan side, what some other os'es like to scream down the pipes for no apparent reason.

It's nothing mission critical, just a pet project at home.

Last edited by fruittool; 10-18-2011 at 09:47 PM.
 
Old 10-19-2011, 08:16 AM   #9
unixfool
Member
 
Registered: May 2005
Location: Northern VA
Distribution: Slackware, Ubuntu, FreeBSD, OpenBSD, OS X
Posts: 781
Blog Entries: 8

Rep: Reputation: 157Reputation: 157
Quote:
Originally Posted by OlRoy View Post
I'm not entirely sure the reason for analyzing the packets. Whether it's for some kind of audit of the firewall, or to detect incidents. If it's the latter, you should understand that traffic that is blocked, probably isn't going to hurt you. It's the traffic you allow that you really need to inspect with an IDS.
Sometimes it pays to know what's being dropped. This is especially true when you've found yourself compromised. And outbound blocks are especially crucial to understand. A firewall is not the end-all security solution...it's efficient but also rather 'dumb'. You'll never be able to perform analysis of a security issue with firewall logs alone. When I see something questionable within my firewall logs, I immediately go to my IDS to gain further insight. If the IDS didn't record anything (remember, it will only alert on known badness that you've configured to alert on), that's when I'll run an adhoc pcap, hoping to record traffic from a specific host, set of hosts, or protocol(s).
 
Old 10-19-2011, 08:26 AM   #10
unixfool
Member
 
Registered: May 2005
Location: Northern VA
Distribution: Slackware, Ubuntu, FreeBSD, OpenBSD, OS X
Posts: 781
Blog Entries: 8

Rep: Reputation: 157Reputation: 157
Quote:
Originally Posted by unSpawn View Post
Uh. I was just informing the OP wrt your "You won't be able to have netfilter do this" but thanks for the explanation.
In re-reading your post, I see now what you meant. I did mistakenly think your post was meant for me and not the OP (quoting might've helped in discerning who you were directing your post toward).

While I've not tried Snort DAQ, ULOG/NFLOG, or (NF)QUEUE, a simple tcpdump might be quicker (unless the OP is intending this as a long term or never-ending project). I can see the value in gathering packets only on dropped FW traffic, though...that should be much more efficient than running a full-blown instance of Snort. Would also be nice to know the performance impact of using such aforementioned tools.
 
Old 10-19-2011, 09:38 AM   #11
OlRoy
Member
 
Registered: Dec 2002
Posts: 304

Rep: Reputation: 86
Quote:
Originally Posted by unixfool View Post
Sometimes it pays to know what's being dropped. This is especially true when you've found yourself compromised. And outbound blocks are especially crucial to understand. A firewall is not the end-all security solution...it's efficient but also rather 'dumb'. You'll never be able to perform analysis of a security issue with firewall logs alone. When I see something questionable within my firewall logs, I immediately go to my IDS to gain further insight. If the IDS didn't record anything (remember, it will only alert on known badness that you've configured to alert on), that's when I'll run an adhoc pcap, hoping to record traffic from a specific host, set of hosts, or protocol(s).
Yup, I agree 100%. The OP was kind of unclear and people were talking about running an IDS... I was just saying if the OP was asking about analyzing blocked traffic, running an IDS like Snort would be more useful on the allowed traffic.
 
Old 10-19-2011, 09:43 AM   #12
unixfool
Member
 
Registered: May 2005
Location: Northern VA
Distribution: Slackware, Ubuntu, FreeBSD, OpenBSD, OS X
Posts: 781
Blog Entries: 8

Rep: Reputation: 157Reputation: 157
Quote:
Originally Posted by OlRoy View Post
I was just saying if the OP was asking about analyzing blocked traffic, running an IDS like Snort would be more useful on the allowed traffic.
Yeah, there's that, too! In the past, I've seen the source of blocked traffic also being passed on other allowed protocols. Might be worth looking at ALL traffic, in cases like that.
 
Old 10-19-2011, 08:19 PM   #13
fruittool
LQ Newbie
 
Registered: Oct 2011
Location: Stoke on Trent, UK
Distribution: Debian
Posts: 6

Original Poster
Rep: Reputation: Disabled
Thanks for pointing me in the direction of snort. I know it's supposed to be an IDS but in this case it still helped. I put the queue filter before drop and used 'snort_inline -QXv' to dump the whole packet data to stdout which is then piped over to the remote host with netcat. It's not the most elegant solution but it is pretty much what i wanted. I don't think performance would be up to much done this way but it is only for dropped packets and i have no intention of returning them to the filter anyway.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Cannot analyse normalised routing load as RTR packets show as dropped in trace file Cataj Linux - Networking 12 08-25-2009 12:23 PM
Dropped packets Doolspin Linux - Software 1 10-22-2006 02:22 PM
too much dropped packets...Hi.. alaios Linux - Networking 2 02-10-2005 05:49 AM
dropped packets... sohmc Linux - Software 3 05-29-2003 10:26 AM


All times are GMT -5. The time now is 09:03 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration