Hi, this question maybe is somewhat off-topic, but also Shorewall-related (currently using 2.4.6-1 on FC4 but soon to upgrade to 3.x). I have a server in housing with accounting based on the traffic done, and the ISP housing it offers a graphical monitoring system with both bit/s and packet/s monitoring (MRTG-like, 5min avg). My server is currently close to zero traffic (only low-volume sites so far). Nevertheless I see random traffic bursts that are apparently unrelated to any system log (no trace in mail, ftp or web logs). Sometimes the traffic is very low for several days, sometimes I see peaks with a duration of around one hour, often repeated for some days (as an example, I had a peak yesterday around 2pm and one today around 1:30pm. The out/in ratio is low (around 20k/s in, 40-70k/s out) so I can probably exclude web traffic, and the packet rate is the same in and out, around 30-50 packets/s during the burst. To try to understand the problem I modified the rules file by adding :info to any ACCEPT rule active: smtp, www, ftp, pop3, domain (both UDP and TCP, since the server acts as secondary DNS for some domains). The traffic is actually logged, but the mysterious bursts are still not logged (I find no place in the log with more than one or two packets per second or repeated packets). My questions are: - are there packet types that are not logged (e.g. SYN) and are there ways to log them? - can the RELATED / ESTABLISHED distinction in 3.x help to track the problem (I''ve read http://shorewall.net/shorewall_logging.html)? - any other idea to log the traffic outside Shorewall (to install an IDS like Snort)? Thanks for any help Elio ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
The only thing I can think of is a rather ''gritty'' solution: use tcpdump to make a huge big log file. Ie: tcpdump -i eth0 >> tcp_dump.txt At least you won''t need to run it for very long (overnight at most) so it shouldn''t get too big. Best of luck! Jan On 01/02/06, Elio Tondo <elio@tondo.it> wrote:> > Hi, > > this question maybe is somewhat off-topic, but also Shorewall-related > (currently using 2.4.6-1 on FC4 but soon to upgrade to 3.x). > > I have a server in housing with accounting based on the traffic done, > and the ISP housing it offers a graphical monitoring system with both > bit/s and packet/s monitoring (MRTG-like, 5min avg). My server is > currently close to zero traffic (only low-volume sites so far). > Nevertheless > I see random traffic bursts that are apparently unrelated to any system > log (no trace in mail, ftp or web logs). Sometimes the traffic is very low > for several days, sometimes I see peaks with a duration of around one > hour, often repeated for some days (as an example, I had a peak > yesterday around 2pm and one today around 1:30pm. The out/in ratio > is low (around 20k/s in, 40-70k/s out) so I can probably exclude web > traffic, and the packet rate is the same in and out, around 30-50 > packets/s during the burst. > > To try to understand the problem I modified the rules file by adding > :info to any ACCEPT rule active: smtp, www, ftp, pop3, domain (both > UDP and TCP, since the server acts as secondary DNS for some > domains). The traffic is actually logged, but the mysterious bursts > are still not logged (I find no place in the log with more than one or > two packets per second or repeated packets). > > My questions are: > > - are there packet types that are not logged (e.g. SYN) and are there > ways to log them? > - can the RELATED / ESTABLISHED distinction in 3.x help to track > the problem (I''ve read http://shorewall.net/shorewall_logging.html)? > - any other idea to log the traffic outside Shorewall (to install an > IDS like Snort)? > > Thanks for any help > Elio > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users >
From: Jan Mulders> The only thing I can think of is a rather ''gritty'' solution: > use tcpdump to make a huge big log file. > > Ie: > tcpdump -i eth0 >> tcp_dump.txt > > At least you won''t need to run it for very long (overnight > at most) so it shouldn''t get too big.The problem is that sometimes it takes several days to see a new burst...> Best of luck!Thanks! Elio ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
Elio Tondo wrote:> ... > My questions are: > > - are there packet types that are not logged (e.g. SYN) and are there > ways to log them?There are lots of packets that are not logged under normal circumstances. RELATED and ESTABLISHED are some of them. Broadcasts are others. Just run ''shorewall show'' to view the iptables and you''ll see all of the rules which do not have logging associated.> - can the RELATED / ESTABLISHED distinction in 3.x help to track > the problem (I''ve read http://shorewall.net/shorewall_logging.html)?Possibly, but tcpdump is much more likely to yield what you''re looking for.> - any other idea to log the traffic outside Shorewall (to install an > IDS like Snort)?Regardless of any other advice about this problem, you *should* run Snort if you''re running a publicly-accessible server. (And run something like logwatch or the Debian snort package which regularly summarises the results and sends them to you.) Paul ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642