Re: System randomly not logging complete bi-directional traffic.

看板FB_questions作者時間14年前 (2011/10/24 14:01), 編輯推噓0(0推 0噓 0→)
留言0則, 0人參與, 最新討論串1/1
Thanks for everyone's patients. In reply to Michael asking about the rule set used; the issue happens without ipfw. We temporarily employed ipfw to help and confirm whether traffic was in fact coming into port 80 and while randomly not being logged or seen by FreeBSD's syslogd, or by the web server. It became more of a concern when both tshark and tcpdump are seen capturing the traffic in both directions, yet the web server nor syslogd (before using ipfw), were found to randomly not log certain incoming traffic to port 80; as can be seen by the sample provided in the beginning of this thread. So, to be perfectly clear, with or without ipfw this logging issue remains. > Sorry to have missed your prior post - please include the entire > ruleset. Thanks. > > On Sun, Oct 9, 2011 at 10:28 AM, <freebsd_user@guice.ath.cx> wrote: >> freebsd-questions@freebsd.org >> # >> # >> # FreeBSD_7-4 RELEASE >> # Our hardware is pristine >> # >> # What is described herein are regular, yet random occurrences; we need >> help. >> >> We have already performed a reinstall of FreeBSD_7-4 RELEASE (and the >> daemons in question); the issue remains. Below, is part of a >> conversation >> with an httpd whereby the packets (entire conversations) are randomly >> 'not' being logged and/or seen by either the httpd nor ipfw (logging >> enabled), yet both tshark and tcpdump are capturing everything. >> >> To be perfectly clear, httpd and ipfw (randomly) will not see/log >> anything >> of an 'entire conversation'. 啱t is not like it drops certain packets of >> a >> conversation; they (httpd/ipfw) either see and log everything during a >> conversation, or, 'do not see' and 'do not log' any packet associated >> with >> a given conversation; all the while tshark and tcpdump are capturing >> everything (bidirectional); hence the connection is real. >> >> The capture below was witnessed by both tshark and tcpdump, but not >> logged >> via the httpd or the following ipfw rule: >> >> $cmd 00029 deny log logamount 0 ip from "table(1)" to me 80 >> >> The above ipfw rule functions properly from "table(1)" which contains -- >> ip.ip.ip.ip/32 -- one (1) ip per line. >> >> The names (below) were changed to protect the innocent; yeah right. >> >> Internet Protocol Version 4, Src: ex.ter.nal.ip (ex.ter.nal.ip), Dst: >> in.ter.nal.ip (in.ter.nal.ip) >> ꀠ吓ersion: 4 >> ꀠ㗎eader length: 20 bytes >> ꀠ餸ifferentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: >> Not-ECT (Not ECN-Capable Transport)) >> ꀠꀠꀠꀰ000 00.. = Differentiated Services Codepoint: Default (0x00) >> .... >> ..00 = Explicit Congestion Notification: Not-ECT (Not >> ECN-Capable Transport) (0x00) >> ꀠ糍otal Length: 60 >> ꀠ啱dentification: 0x8ce5 (36069) >> ꀠ啫lags: 0x02 (Don't Fragment) >> ꀠꀠꀠꀰ... .... = Reserved bit: Not set >> ꀠꀠꀠꀮ1.. .... = Don't fragment: Set >> ꀠꀠꀠꀮ.0. .... = More fragments: Not set >> ꀠ啫ragment offset: 0 >> ꀠ糍ime to live: 251 >> ꀠ嘭rotocol: TCP (6) >> ꀠ㗎eader checksum: 0x9102 [correct] >> ꀠꀠꀠ嚤Good: True] >> ꀠꀠꀠ嚤Bad: False] >> ꀠ嚒ource: ex.ter.nal.ip (ex.ter.nal.ip) >> ꀠ餸estination: in.ter.nal.ip (in.ter.nal.ip) >> Transmission Control Protocol, Src Port: 46463 (46463), Dst Port: http >> (80), Seq: 0, Len: 0 >> ꀠ嚒ource port: 46463 (46463) >> ꀠ餸estination port: http (80) >> ꀠ嚤Stream index: 19] >> ꀠ嚒equence number: 0 ꀠꀨrelative sequence number) >> ꀠ㗎eader length: 40 bytes >> ꀠ啫lags: 0x02 (SYN) >> ꀠꀠꀠꀰ00. .... .... = Reserved: Not set >> ꀠꀠꀠꀮ..0 .... .... = Nonce: Not set >> ꀠꀠꀠꀮ... 0... .... = Congestion Window Reduced (CWR): Not set >> ꀠꀠꀠꀮ... .0.. .... = ECN-Echo: Not set >> ꀠꀠꀠꀮ... ..0. .... = Urgent: Not set >> ꀠꀠꀠꀮ... ...0 .... = Acknowledgement: Not set >> ꀠꀠꀠꀮ... .... 0... = Push: Not set >> ꀠꀠꀠꀮ... .... .0.. = Reset: Not set >> ꀠꀠꀠꀮ... .... ..1. = Syn: Set >> ꀠꀠꀠꀠꀠ嚤Expert Info (Chat/Sequence): Connection establish request >> (SYN): server port http] >> ꀠꀠꀠꀠꀠꀠꀠ嚤Message: Connection establish request (SYN): server port >> http] >> ꀠꀠꀠꀠꀠꀠꀠ嚤Severity level: Chat] >> ꀠꀠꀠꀠꀠꀠꀠ嚤Group: Sequence] >> ꀠꀠꀠꀮ... .... ...0 = Fin: Not set >> ꀠ咗indow size value: 5840 >> ꀠ嚤Calculated window size: 5840] >> ꀠhecksum: 0xe7f8 [validation disabled] >> ꀠꀠꀠ嚤Good Checksum: False] >> ꀠꀠꀠ嚤Bad Checksum: False] >> ꀠ嘢ptions: (20 bytes) >> ꀠꀠꀠ嗰aximum segment size: 1460 bytes >> ꀠꀠꀠ糍CP SACK Permitted Option: True >> ꀠꀠꀠ糍imestamps: TSval 309029146, TSecr 0 >> ꀠꀠꀠꀠꀠ嗱ind: Timestamp (8) >> ꀠꀠꀠꀠꀠ㗒ength: 10 >> ꀠꀠꀠꀠꀠ糍imestamp value: 309029146 >> ꀠꀠꀠꀠꀠ糍imestamp echo reply: 0 >> ꀠꀠꀠ嘅o-Operation (NOP) >> ꀠꀠꀠ咗indow scale: 7 (multiply by 128) >> ꀠꀠꀠꀠꀠ嗱ind: Window Scale (3) >> ꀠꀠꀠꀠꀠ㗒ength: 3 >> ꀠꀠꀠꀠꀠ嚒hift count: 7 >> ꀠꀠꀠꀠꀠ嚤Multiplier: 128] >> ꀠ啫rame Number: 51 >> ꀠ啫rame Length: 74 bytes (592 bits) >> ꀠapture Length: 74 bytes (592 bits) >> ꀠ嚤Frame is marked: False] >> ꀠ嚤Frame is ignored: False] >> ꀠ嚤Protocols in frame: eth:ip:tcp] >> Ethernet II, Src: Router_cf:gr:f0 (11:52:c3:fd:dd:f0), Dst: Goe_40:84:21 >> (00:15:18:40:28:41) >> ꀠ餸estination: Goe_40:84:21 (00:15:18:40:28:41) >> ꀠꀠꀠ孭ddress: Goe_40:84:21 (00:15:18:40:28:41) >> ꀠꀠꀠꀮ... ...0 .... .... .... .... = IG bit: Individual address >> (unicast) >> ꀠꀠꀠꀮ... ..0. .... .... .... .... = LG bit: Globally unique address >> (factory default) >> ꀠ嚒ource: Router_cf:gr:f0 (11:52:c3:fd:dd:f0) >> ꀠꀠꀠ孭ddress: Router_cf:gr:f0 (11:52:c3:fd:dd:f0) >> ꀠꀠꀠꀮ... ...0 .... .... .... .... = IG bit: Individual address >> (unicast) >> ꀠꀠꀠꀮ... ..0. .... .... .... .... = LG bit: Globally unique address >> (factory default) >> ꀠ糍ype: IP (0x0800) >> Internet Protocol Version 4, Src: ex.ter.nal.ip (ex.ter.nal.ip), Dst: >> in.ter.nal.ip (in.ter.nal.ip) >> ꀠ吓ersion: 4 >> ꀠ㗎eader length: 20 bytes >> ꀠ餸ifferentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: >> Not-ECT (Not ECN-Capable Transport)) >> ꀠꀠꀠꀰ000 00.. = Differentiated Services Codepoint: Default (0x00) >> .... >> ..00 = Explicit Congestion Notification: Not-ECT (Not >> ECN-Capable Transport) (0x00) >> ꀠ糍otal Length: 60 >> ꀠ啱dentification: 0x8ce5 (36069) >> ꀠ啫lags: 0x02 (Don't Fragment) >> ꀠꀠꀠꀰ... .... = Reserved bit: Not set >> ꀠꀠꀠꀮ1.. .... = Don't fragment: Set >> ꀠꀠꀠꀮ.0. .... = More fragments: Not set >> ꀠ啫ragment offset: 0 >> ꀠ糍ime to live: 251 >> ꀠ嘭rotocol: TCP (6) >> ꀠ㗎eader checksum: 0x9102 [correct] >> ꀠꀠꀠ嚤Good: True] >> ꀠꀠꀠ嚤Bad: False] >> ꀠ嚒ource: ex.ter.nal.ip (ex.ter.nal.ip) >> ꀠ餸estination: in.ter.nal.ip (in.ter.nal.ip) >> Transmission Control Protocol, Src Port: 46463 (46463), Dst Port: http >> (80), Seq: 0, Len: 0 >> ꀠ嚒ource port: 46463 (46463) >> ꀠ餸estination port: http (80) >> ꀠ嚤Stream index: 19] >> ꀠ嚒equence number: 0 ꀠꀨrelative sequence number) >> ꀠ㗎eader length: 40 bytes >> ꀠ啫lags: 0x02 (SYN) >> ꀠꀠꀠꀰ00. .... .... = Reserved: Not set >> ꀠꀠꀠꀮ..0 .... .... = Nonce: Not set >> ꀠꀠꀠꀮ... 0... .... = Congestion Window Reduced (CWR): Not set >> ꀠꀠꀠꀮ... .0.. .... = ECN-Echo: Not set >> ꀠꀠꀠꀮ... ..0. .... = Urgent: Not set >> ꀠꀠꀠꀮ... ...0 .... = Acknowledgement: Not set >> ꀠꀠꀠꀮ... .... 0... = Push: Not set >> ꀠꀠꀠꀮ... .... .0.. = Reset: Not set >> ꀠꀠꀠꀮ... .... ..1. = Syn: Set >> ꀠꀠꀠꀠꀠ嚤Expert Info (Chat/Sequence): Connection establish request >> (SYN): server port http] >> ꀠꀠꀠꀠꀠꀠꀠ嚤Message: Connection establish request (SYN): server port >> http] >> ꀠꀠꀠꀠꀠꀠꀠ嚤Severity level: Chat] >> ꀠꀠꀠꀠꀠꀠꀠ嚤Group: Sequence] >> ꀠꀠꀠꀮ... .... ...0 = Fin: Not set >> ꀠ咗indow size value: 5840 >> ꀠ嚤Calculated window size: 5840] >> ꀠhecksum: 0xe7f8 [validation disabled] >> ꀠꀠꀠ嚤Good Checksum: False] >> ꀠꀠꀠ嚤Bad Checksum: False] >> ꀠ嘢ptions: (20 bytes) >> ꀠꀠꀠ嗰aximum segment size: 1460 bytes >> ꀠꀠꀠ糍CP SACK Permitted Option: True >> ꀠꀠꀠ糍imestamps: TSval 309029146, TSecr 0 >> ꀠꀠꀠꀠꀠ嗱ind: Timestamp (8) >> ꀠꀠꀠꀠꀠ㗒ength: 10 >> ꀠꀠꀠꀠꀠ糍imestamp value: 309029146 >> ꀠꀠꀠꀠꀠ糍imestamp echo reply: 0 >> ꀠꀠꀠ嘅o-Operation (NOP) >> ꀠꀠꀠ咗indow scale: 7 (multiply by 128) >> ꀠꀠꀠꀠꀠ嗱ind: Window Scale (3) >> ꀠꀠꀠꀠꀠ㗒ength: 3 >> ꀠꀠꀠꀠꀠ嚒hift count: 7 >> ꀠꀠꀠꀠꀠ嚤Multiplier: 128] >> ================================ >> >> We first noticed this logging issue with Apache22 and thought httpd was >> the culprit; we installed another httpd and the problem remained. 孭t >> that >> point, with two (2) httpds' seemingly offering the same results we >> decided >> to enable ipfw and its logging feature. Shortly thereafter we notice >> ipfw >> was also randomly 'not seeing' the exact same traffic, destined for port >> 80, that neither httpd's were also 'not seeing', yet Tshark and tcpdump >> are in fact, capturing these packets. >> >> We would like help to troubleshoot this concern rather than blindly >> replacing things such as syslogd. >> >> _______________________________________________ >> freebsd-questions@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-questions >> To unsubscribe, send any mail to >> "freebsd-questions-unsubscribe@freebsd.org" >> > > _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org"
‣ 更多 freebsd_use. 的文章
文章代碼(AID): #1EfFyVc2 (FB_questions)