--kXdP64Ggrk/fb43R Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello everyone, I''m using Shorewall 1.2.12-1 on Debian 3.0, with the 2.4.17 kernel. I am seeing some interesting log entries, and after reading the documentation at Google and netfilter.org I have a couple questions. To begin, here are the entries I am concerned about in my syslog: | Oct 25 11:30:36 fw kernel: Shorewall:rfc1918:DROP:IN=3DSerial0 | OUT=3D MAC=3D SRC=3D10.3.32.1 DST=3Daaa.aaa.aaa.aaa LEN=3D56 TOS=3D0x00 PREC=3D0x00 | TTL=3D241 ID=3D47917 PROTO=3DICMP TYPE=3D3 CODE=3D1 [SRC=3Daaa.aaa.aaa.aaa | DST=3D68.97.0.94 LEN=3D84 TOS=3D0x00 PREC=3D0x00 TTL=3D52 ID=3D0 DF PROTO=3DICMP | TYPE=3D8 CODE=3D0 ID=3D11895 SEQ=3D0 ]=20 |=20 | Oct 25 11:30:36 fw kernel: Shorewall:rfc1918:DROP:IN=3DSerial0 | OUT=3D MAC=3D SRC=3D10.3.32.1 DST=3Daaa.aaa.aaa.aaa LEN=3D56 TOS=3D0x00 PREC=3D0x00 | TTL=3D241 ID=3D59767 PROTO=3DICMP TYPE=3D3 CODE=3D1 [SRC=3Daaa.aaa.aaa.aaa | DST=3D68.97.0.94 LEN=3D84 TOS=3D0x00 PREC=3D0x00 TTL=3D52 ID=3D0 DF PROTO=3DICMP | TYPE=3D8 CODE=3D0 ID=3D11895 SEQ=3D0 ]=20 |=20 | Oct 25 11:30:36 fw kernel: Shorewall:rfc1918:DROP:IN=3DSerial0 | OUT=3D MAC=3D SRC=3D10.3.32.1 DST=3Daaa.aaa.aaa.aaa LEN=3D56 TOS=3D0x00 PREC=3D0x00 | TTL=3D241 ID=3D21933 PROTO=3DICMP TYPE=3D3 CODE=3D1 [SRC=3Daaa.aaa.aaa.aaa | DST=3D68.97.0.94 LEN=3D84 TOS=3D0x00 PREC=3D0x00 TTL=3D52 ID=3D0 DF PROTO=3DICMP | TYPE=3D8 CODE=3D0 ID=3D11895 SEQ=3D0 ]=20 |=20 | Oct 25 11:30:36 fw kernel: Shorewall:rfc1918:DROP:IN=3DSerial0 | OUT=3D MAC=3D SRC=3D10.3.32.1 DST=3Daaa.aaa.aaa.aaa LEN=3D56 TOS=3D0x00 PREC=3D0x00 | TTL=3D241 ID=3D45499 PROTO=3DICMP TYPE=3D3 CODE=3D1 [SRC=3Daaa.aaa.aaa.aaa | DST=3D68.97.0.94 LEN=3D84 TOS=3D0x00 PREC=3D0x00 TTL=3D52 ID=3D0 DF PROTO=3DICMP | TYPE=3D8 CODE=3D0 ID=3D11895 SEQ=3D0 ] These have been occurring more frequently, and I''m interpreting them as this: An interface somewhere on the Internet reporting to be 10.3.32.1 is contacting aaa.aaa.aaa.aaa (the firewall) and saying that the destination host is unreachable. The datagram of the ICMP packet contains information about a ICMP echo which originated from the firewall (MASQ possibly?) and was destined for 68.97.0.94 out in the Internet. Is my view on the information the log presents me sound? The 10.3.32.1 and 68.97.0.94 change, which makes me think the user at this address is scanning networks and getting answers back saying the hosts are unreachable. This makes me believe that this host on the LAN has been compromised (un/knowingly). These may be separate issues, but I thought I would also mention the "kernel: Neighbour table overflow." error I get quite frequently. The research I have done suggests that the lo interface is not enabled. Here are some more details about this machine: | # ip nei | 10.10.10.14 dev eth0 lladdr 00:40:f4:2e:78:ef nud reachable | 10.10.10.39 dev eth0 lladdr 00:10:a4:11:38:2d nud reachable | 10.10.10.250 dev eth0 lladdr 00:04:c1:66:30:c0 nud stale | 10.10.10.251 dev eth0 lladdr 00:06:28:01:bc:80 nud reachable | 10.10.10.34 dev eth0 lladdr 00:10:a4:98:51:2c nud reachable | 10.10.10.196 dev eth0 lladdr 00:10:a4:7b:49:74 nud reachable | 10.10.10.19 dev eth0 lladdr 00:40:f4:1f:93:f5 nud reachable | # ifconfig lo | lo Link encap:Local Loopback =20 | inet addr:127.0.0.1 Mask:255.0.0.0 | UP LOOPBACK RUNNING MTU:16436 Metric:1 | RX packets:31 errors:0 dropped:0 overruns:0 frame:0 | TX packets:31 errors:0 dropped:0 overruns:0 carrier:0 | collisions:0 txqueuelen:0=20 | RX bytes:2324 (2.2 KiB) TX bytes:2324 (2.2 KiB) | # free | total used free shared buffers | cached | Mem: 62772 57068 5704 0 7324 | 15120 | -/+ buffers/cache: 34624 28148 | Swap: 128516 1600 126916 How likely is it that I need more system memory to have an ARP table larger than 7 entries? Thank you for reading until the end =3D) I appreciate all comments. - hank --kXdP64Ggrk/fb43R Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9uXgoNa4s+gkK91QRAtSWAJ9QbdnOoL2Pa94GowOKdv/Pvx5oaQCfXf5w 7OPPlZF6s1PNVtjVO9L5mV0=ZjM9 -----END PGP SIGNATURE----- --kXdP64Ggrk/fb43R--
Adam Henry wrote:> | > | Oct 25 11:30:36 fw kernel: Shorewall:rfc1918:DROP:IN=Serial0 > | OUT= MAC= SRC=10.3.32.1 DST=aaa.aaa.aaa.aaa LEN=56 TOS=0x00 PREC=0x00 > | TTL=241 ID=45499 PROTO=ICMP TYPE=3 CODE=1 [SRC=aaa.aaa.aaa.aaa > | DST=68.97.0.94 LEN=84 TOS=0x00 PREC=0x00 TTL=52 ID=0 DF PROTO=ICMP > | TYPE=8 CODE=0 ID=11895 SEQ=0 ] > > These have been occurring more frequently, and I''m interpreting them > as this: An interface somewhere on the Internet reporting to be > 10.3.32.1 is contacting aaa.aaa.aaa.aaa (the firewall) and saying that > the destination host is unreachable. The datagram of the ICMP packet > contains information about a ICMP echo which originated from the firewall > (MASQ possibly?) and was destined for 68.97.0.94 out in the Internet. > Is my view on the information the log presents me sound? > > The 10.3.32.1 and 68.97.0.94 change, which makes me think the user at > this address is scanning networks and getting answers back saying the > hosts are unreachable. This makes me believe that this host on the LAN > has been compromised (un/knowingly).I refuse to spend any time on an ICMP problem with the IP addresses falsified; they are tricky enough when you have all of the information. You might find my recent response in a thread entitled "Rejected ICMP packets" helpful.> > These may be separate issues, but I thought I would also mention the > "kernel: Neighbour table overflow." error I get quite frequently. > The research I have done suggests that the lo interface is not enabled. > Here are some more details about this machine: > > | # ip nei > | 10.10.10.14 dev eth0 lladdr 00:40:f4:2e:78:ef nud reachable > | 10.10.10.39 dev eth0 lladdr 00:10:a4:11:38:2d nud reachable > | 10.10.10.250 dev eth0 lladdr 00:04:c1:66:30:c0 nud stale > | 10.10.10.251 dev eth0 lladdr 00:06:28:01:bc:80 nud reachable > | 10.10.10.34 dev eth0 lladdr 00:10:a4:98:51:2c nud reachable > | 10.10.10.196 dev eth0 lladdr 00:10:a4:7b:49:74 nud reachable > | 10.10.10.19 dev eth0 lladdr 00:40:f4:1f:93:f5 nud reachable > > | # ifconfig lo > | lo Link encap:Local Loopback > | inet addr:127.0.0.1 Mask:255.0.0.0 > | UP LOOPBACK RUNNING MTU:16436 Metric:1 > | RX packets:31 errors:0 dropped:0 overruns:0 frame:0 > | TX packets:31 errors:0 dropped:0 overruns:0 carrier:0 > | collisions:0 txqueuelen:0 > | RX bytes:2324 (2.2 KiB) TX bytes:2324 (2.2 KiB) > > | # free > | total used free shared buffers > | cached > | Mem: 62772 57068 5704 0 7324 > | 15120 > | -/+ buffers/cache: 34624 28148 > | Swap: 128516 1600 126916 > > How likely is it that I need more system memory to have an ARP table > larger than 7 entries? >I''ve never seen this problem personally (although I see it reported quite a bit on other lists) and I don''t recall anything about it. Sorry, -Tom -- Tom Eastep \ Shorewall - iptables made easy AIM: tmeastep \ http://www.shorewall.net ICQ: #60745924 \ teastep@shorewall.net
--0F1p//8PRICkK4MW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Oct 27, 2002 at 04:20:21PM -0800, Tom Eastep wrote:> >| Oct 25 11:30:36 fw kernel: Shorewall:rfc1918:DROP:IN=3DSerial0 > >| OUT=3D MAC=3D SRC=3D10.3.32.1 DST=3Daaa.aaa.aaa.aaa LEN=3D56 TOS=3D0x00 PREC=3D0x00 > >| TTL=3D241 ID=3D45499 PROTO=3DICMP TYPE=3D3 CODE=3D1 [SRC=3Daaa.aaa.aaa.aaa > >| DST=3D68.97.0.94 LEN=3D84 TOS=3D0x00 PREC=3D0x00 TTL=3D52 ID=3D0 DF PROTO=3DICMP > >| TYPE=3D8 CODE=3D0 ID=3D11895 SEQ=3D0 ] >=20 > I refuse to spend any time on an ICMP problem with the IP addresses=20 > falsified; they are tricky enough when you have all of the information.=20 > You might find my recent response in a thread entitled "Rejected ICMP=20 > packets" helpful.Sorry Tom, if I knew it was so important I wouldn''t have wasted your time. In the log entry quoted above, ''aaa.aaa.aaa.aaa'' is equivalent to ''209.176.91.56''. =20 I''m checking through the archives to see how you interpret a similar problem.> I''ve never seen this problem personally (although I see it reported quite=20 > a bit on other lists) and I don''t recall anything about it.I have noticed quite a bit of activity searching through Groups on Google. The most common fix I have heard suggested was to enable the local loopback interface, which has already been done. I do value your time. If there are any other details you wish to know about my setup, I will get them to you as quickly as I can. hank --0F1p//8PRICkK4MW Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9vW7CNa4s+gkK91QRAgK0AJ9BBNusMXlUmU5lEPfwaAe9Tq7oPwCbBruA OOMfiO8xGmwZhRa4duGtGm4=1BwE -----END PGP SIGNATURE----- --0F1p//8PRICkK4MW--
Adam Henry wrote:> On Sun, Oct 27, 2002 at 04:20:21PM -0800, Tom Eastep wrote: > >>>| Oct 25 11:30:36 fw kernel: Shorewall:rfc1918:DROP:IN=Serial0 >>>| OUT= MAC= SRC=10.3.32.1 DST=209.176.91.56 LEN=56 TOS=0x00 PREC=0x00 >>>| TTL=241 ID=45499 PROTO=ICMP TYPE=3 CODE=1 [SRC=209.176.91.56 >>>| DST=68.97.0.94 LEN=84 TOS=0x00 PREC=0x00 TTL=52 ID=0 DF PROTO=ICMP >>>| TYPE=8 CODE=0 ID=11895 SEQ=0 ]Ok -- the above (with real IP substituted) is very similar to the packet in the other thread. In this case, there was a ping from your firewall (possibly SNAT/MASQUERADED) to 68.97.0.94. That host is behind a NAT gateway so the destination was rewritten to 10.3.32.1. I suspect that system has a rule against passing ping requests so it returned the rather nonsensical response of "port not available" but did not change the source IP back to 68.97.0.94. Your firewall therefore barfed on the returning ICMP because its source address was reserved by RFC 1918 (see http://www.shorewall.net/FAQ.htm#faq17> > >>I''ve never seen this problem personally (although I see it reported quite >>a bit on other lists) and I don''t recall anything about it. > > > I have noticed quite a bit of activity searching through Groups on > Google. The most common fix I have heard suggested was to enable the > local loopback interface, which has already been done. >The only thing I notice that is unusual about your setup is that you seem to have some sort of WAN serial interface (correct?) - that might be relevant. -Tom -- Tom Eastep \ Shorewall - iptables made easy AIM: tmeastep \ http://www.shorewall.net ICQ: #60745924 \ teastep@shorewall.net