PORT 111 pinging from loopback

From: RoscoSTL (theshowmecanuck@123nospamnetscape.net)
Date: 08/05/02 

From: "RoscoSTL" <theshowmecanuck@123nospamnetscape.net>
Date: Mon, 5 Aug 2002 21:10:09 GMT

Hi from a fairly newbie to Linux.

I have set up IPTABLES on a Linux box I set up to learn on. I am doing a
lot of logging in an effort to watch and hopefully learn something
(anything) about the traffic in and out of my machine. Kind of by osmosis
(as well as trying to research). I have a question about what or why my
loopback address should be pinging port 111. A snippet from the syslog is
below, as well as a short explanation.

I forgot to open up the loopback so my machine could talk to itself (like
its owner) and for a short time, I believe I opened the loopback
address/interface to everyone. As soon as I thought about it (about a half
day) I moved these rules below my anti-spoofing rules blocking loopback
addresses from entering via the Internet interface. Since I have done this
I am finding some (I think) strange connections trying to ping or something
my port 111 from the loopback address. I had already shut down all services
that relate to RPC, since I don't know much about PC, and don't want to run
it until I do. I do have Apache running as I am now trying to understand
how it works a bit before allowing connections to it via the net.
Eventually, I would like to play with web programming, and think learning to
do so securely is just maybe a good idea. So you all know, basically I shut
down all connections in, and as I get comfortable with a service, I will
allow connections in to those ports. I also scan and log and drop what I
understand to be dubious connection attempts (new but no syn, external
connection attempts from reserved IPs... including loopback, broadcast
addresses, etc.). I also block most outgoing connection attempts except for
things like 20, 21, 22, 25, 53, 80, 110, 443). I also do not allow anyone
to ping, but allow ping out, etc. I also have ip forwarding that is, or
should be, locked down in and out to stifle a noisy windows machine.

Anyway, is this something to be concerned about, and how do I trace what is
actually trying to make this connection. Here is the snippet. My machine
is not always online. Thought I would mention it in case someone tries to
look.

Thanks for your comments (well, if they are constructive ones anyway).

RoscoSTL
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Aug 5 15:26:43 www kernel: ALL OUTPUT FROM LOOPBACK: IN= OUT=lo
SRC=127.0.0.1 DST=127.0.0.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF
PROTO=UDP SPT=32768 DPT=111 LEN=64

Aug 5 15:26:43 www kernel: ALL INPUT TO LOOPBACK: IN=lo OUT=
MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=127.0.0.1 DST=127.0.0.1
LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=32768 DPT=111 LEN=64

Aug 5 15:26:43 www kernel: ALL OUTPUT FROM LOOPBACK: IN= OUT=lo
SRC=127.0.0.1 DST=127.0.0.1 LEN=112 TOS=0x00 PREC=0xC0 TTL=255 ID=3929
PROTO=ICMP TYPE=3 CODE=3 [SRC=127.0.0.1 DST=127.0.0.1 LEN=84 TOS=0x00
PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=32768 DPT=111 LEN=64 ]

Aug 5 15:26:43 www kernel: ALL INPUT TO LOOPBACK: IN=lo OUT=
MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=127.0.0.1 DST=127.0.0.1
LEN=112 TOS=0x00 PREC=0xC0 TTL=255 ID=3929 PROTO=ICMP TYPE=3 CODE=3
[SRC=127.0.0.1 DST=127.0.0.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF
PROTO=UDP SPT=32768 DPT=111 LEN=64 ]

Aug 5 15:27:00 www kernel: ALL OUTPUT FROM LOOPBACK: IN= OUT=lo
SRC=127.0.0.1 DST=127.0.0.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF
PROTO=UDP SPT=1004 DPT=111 LEN=64

Aug 5 15:27:00 www kernel: ALL INPUT TO LOOPBACK: IN=lo OUT=
MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=127.0.0.1 DST=127.0.0.1
LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=1004 DPT=111 LEN=64

Aug 5 15:27:00 www kernel: ALL OUTPUT FROM LOOPBACK: IN= OUT=lo
SRC=127.0.0.1 DST=127.0.0.1 LEN=112 TOS=0x00 PREC=0xC0 TTL=255 ID=3930
PROTO=ICMP TYPE=3 CODE=3 [SRC=127.0.0.1 DST=127.0.0.1 LEN=84 TOS=0x00
PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=1004 DPT=111 LEN=64 ]

Aug 5 15:27:00 www kernel: ALL INPUT TO LOOPBACK: IN=lo OUT=
MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=127.0.0.1 DST=127.0.0.1
LEN=112 TOS=0x00 PREC=0xC0 TTL=255 ID=3930 PROTO=ICMP TYPE=3 CODE=3
[SRC=127.0.0.1 DST=127.0.0.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF
PROTO=UDP SPT=1004 DPT=111 LEN=64 ]

Relevant Pages

  • Re: Problem on Looback (127.0.0.1)
    ... > I've got a problem with no traffic being allowed on the loopback ... As part of troubleshooting I've installed an Accept-All iptables ... > The interface is defined. ... When the firewall is running all connections are ...
    (comp.os.linux.networking)
  • Re: netfilter -> do you DROP or REJECT ?
    ... If connections are REJECTed the port is ... In both cases connecting to the port is impossible. ... ping of death which was capable of crashing machines. ... benefit in doing ping rather than trying a TCP connection which may take ...
    (comp.os.linux.networking)
  • TCP loopback socket fusing
    ... When a TCP connection via loopback back to localhost is made the whole ... To short-circuit the send and receive sockets on localhost TCP connections ... The connections setup (SYN, SYN-ACK, ... ACK) and shutdown are still handled by normal TCP segments via loopback so ...
    (freebsd-current)
  • TCP loopback socket fusing
    ... When a TCP connection via loopback back to localhost is made the whole ... To short-circuit the send and receive sockets on localhost TCP connections ... The connections setup (SYN, SYN-ACK, ... ACK) and shutdown are still handled by normal TCP segments via loopback so ...
    (freebsd-net)
  • Re: 127.0.0.1
    ... It is not going over the internet, the connections are all within your ... computer (that is what the loopback means). ... attempt to dial out and blocked it so I got the first hint of what is ...
    (microsoft.public.windowsxp.help_and_support)