Les wrote:
In regards to the statement Les mentioned, unless your ISP is very poorly managed, its routers should drop any and all requests to/from a private RFC1918 subnet right into the bit bucket (or /dev/null, if you prefer). From the looks of it, if that 192.168 address range isn't the one you are using, it looks like something is sending commands via SNMP to your host (if you have an ISP like Cox, Comcast, etc, that uses cable modems, 90% of the time these are managed using SNMP, and you get fuzz that could mess up the system in strange ways if this happens to aggravate something in your system.)If you google RFC 1918, it will show that your system has sent a request for a private subnet out onto the global internet. I am no IP guru, but I suspect that you will find the solution somewhere in the linux responses related to RFC 1918. Regards, Les H On Wed, 2009-01-14 at 14:31 -0200, Leonardo Korndorfer wrote:Hi all! I'm in a situation that is kinda hard to see what's happening. So I'm going straight to the scenario: I have a firewall box that somehow stops responding to all services such as ssh and squid. It does answer ping. Early this morning I was looking to the messages log with tail -f when it just stop and then no responses again.Does anyone have lived this situation?Here goes an example of the normality of logs when it just stops: /* regular log */ Jan 14 13:35:08 mercfw1 snmpd[2040]: Received SNMP packet(s) from UDP: [192.168.0.13]:1660 Jan 14 13:35:08 mercfw1 snmpd[2040]: Connection from UDP: [192.168.0.13]:1661 Jan 14 13:35:08 mercfw1 snmpd[2040]: Received SNMP packet(s) from UDP: [192.168.0.13]:1661 Jan 14 13:35:08 mercfw1 snmpd[2040]: Connection from UDP: [192.168.0.13]:1662 Jan 14 13:35:08 mercfw1 snmpd[2040]: Received SNMP packet(s) from UDP: [192.168.0.13]:1662 Jan 14 13:35:08 mercfw1 snmpd[2040]: Connection from UDP: [192.168.0.13]:1663 Jan 14 13:35:08 mercfw1 snmpd[2040]: Received SNMP packet(s) from UDP: [192.168.0.13]:1663 Jan 14 13:35:08 mercfw1 snmpd[2040]: Connection from UDP: [192.168.0.13]:1664 Jan 14 13:35:08 mercfw1 snmpd[2040]: Received SNMP packet(s) from UDP: [192.168.0.13]:1664 Jan 14 13:35:08 mercfw1 snmpd[2040]: Connection from UDP: [192.168.0.13]:1665 Jan 14 13:35:08 mercfw1 snmpd[2040]: Received SNMP packet(s) from UDP: [192.168.0.13]:1665 Jan 14 13:35:06 mercfw1 named[1731]: client 127.0.0.1#38570: RFC 1918 response from Internet for 11.0.168.192.in-addr.arpa /* forced shutdown and normal start log */ Jan 14 13:49:03 mercfw1 kernel: imklog 3.14.1, log source = /proc/kmsg started. Jan 14 13:49:03 mercfw1 kernel: Inspecting /boot/System.map-2.6.25-14.fc9.i686 Jan 14 13:49:03 mercfw1 kernel: Loaded 28110 symbols from /boot/System.map-2.6.25-14.fc9.i686. Jan 14 13:49:03 mercfw1 kernel: Symbols match kernel version 2.6.25. Jan 14 13:49:03 mercfw1 kernel: No module symbols loaded - kernel modules not enabled. If The seconds before (13:35:06) are analogous. Nothing evil has happened. Leonardo Richter Korndorfer personal @ http://leokorndorfer.no-ip.org http://counter.li.org #384363 ICQ: 102788426 -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
If you are using iptables, try plugging in the ULOG log module for iptables, and set it up to grab a pcap of the logged traffic, and make sure to refresh it every day while you need to research this, and turn it off after. This will give you a better gateway into what/how/why you are seeing this traffic. I am on a current version of fedora for my firewall, and I do see a lot of this type of traffic (10.x.x.x traffic) If this traffic is from your network, I would check to see what is firing off SNMP and find out why.
~Seann
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
-- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
