Weird loopback connection...

Djjules · 07-13-2006, 05:00 AM

Hi!

For starters:

I have a linux server that is running on Fedora Core 4.

I use Firestarter as my GUI firewall.

Recently I've had this weird connection from 127.0.0.1 to 127.0.0.1 and the port is changing about once per day. The port is something between 40000 - 50000 (this information I get from Firestarter). Is this normal?

So, is there some kind of hacker messing with my server or is this just normal to have this connection showing to me like that? I didn't have that connection showing earlier with Core 3.

I guess that Fedora ain't the best kind of server base, but it doesn't matter to me as long as it runs normally

.

Thnx in advance!

blackhole54 · 07-13-2006, 05:26 AM

If this connection is persistent, you can find what process(es) is involved by running the following as root:

Code:

netstat -nap | fgrep 127.0.0.1

Djjules · 07-14-2006, 03:44 AM

Quote:

Originally Posted by blackhole54

If this connection is persistent, you can find what process(es) is involved by running the following as root:

Code:

netstat -nap | fgrep 127.0.0.1

Ok, done that and the output is like:

Code:

tcp        0      0 127.0.0.1:783             0.0.0.0:*               LISTEN    274/spamd.pid      
tcp        0      0 127.0.0.1:631             0.0.0.0:*               LISTEN    4811/cupsd          
tcp        0      0 127.0.0.1:5335            0.0.0.0:*               LISTEN    3109/mDNSResponder  
tcp        0      0 127.0.0.1:41178           127.0.0.1:25            TIME_WAIT -                   
udp        0      0 127.0.0.1:123             0.0.0.0:*                         3192/ntpd

So there, I quess, is showing the "weird" connection on the 4th row. Does it look like normal?

Yep, and few minutes after this output I took another one and it showed everything else but the 4th row. I blocked outbound connections from 127.0.0.1 yesterday (deny connection from LAN host), and it seems the weird connection is gone now from the firestarter lists. Even though it seems that the connection is trying to reconnect since I got it on the above list, am I right?

Am I messing my email server with blocking this connection's outbound traffic?

And for the record, my SMTP port 25 is open for everyone, is that a security risk? How can I disable this port without messing up my email server?

blackhole54 · 07-14-2006, 04:54 AM

Quote:

Originally Posted by Djjules

Code:

tcp        0      0 127.0.0.1:41178           127.0.0.1:25            TIME_WAIT -

Yep, and few minutes after this output I took another one and it showed everything else but the 4th row.[/code]

I think you already know this, but just in case ... The "TIME_WAIT" means you just missed the connection and it is waiting to totally shut the connection down. This is why no process is listed.

It would be nice to actually catch the process doing this. Maybe somebody else reading this thread can help out with this ... If I think of anything I'll post back.

Quote:

I blocked outbound connections from 127.0.0.1 yesterday (deny connection from LAN host), and it seems the weird connection is gone now from the firestarter lists. Even though it seems that the connection is trying to reconnect since I got it on the above list, am I right?

Are you saying the above output from netstat was with 127.0.0.1 blocked on the OUTPUT chain? If so, and if you are comfortable doing so, repeating this test w/o blocking the loopback address might reveal the process doing this. (If you're worried about potential bad things happening while you test, you could briefly block all output from your machine to the outside world during the test.) You could also try to use tcpdump to catch packets going to and from 127.0.0.1:25 to see if you can figure out what is being attempted. If you have the connection blocked you probably won't see much since it can't even complete the handshake.

Quote:

Am I messing my email server with blocking this connection's outbound traffic?

If your routing table is set up properly (check with route -n), anything going out to 127.x.x.x should not leave your machine. I would not think your mail server would need this, but I am not an expert.

blackhole54 · 07-14-2006, 06:34 AM

Could this be the result of an ssh tunnel? Do you allow ssh access on this box?

(BTW, I got this idea googling on "127.0.0.1:25" There are quite a few entries if you want to take a look. Don't know if there is anything useful.)

jschiwal · 07-14-2006, 06:53 AM

For reference, I extracted this from the "Linux Firewalls" book by Novel Press:

LOOPBACK="127.0.0.0/8" # reserved loopback address range.
INTERNET="eth0" # internet-connected interface
IPT="/usr/sbin/iptables"

# Refuse packets claiming to be fromthe loopback interface.
$IPT -A INPUT -I $INTERNET -s $LOOPBACK -j DROP

It drops spoofed packets coming in from the internet facing NIC interface where the address is spoofed to be the loopback address.
Your firewall probably already has something similar. I believe it is always used unless you wrote the rules yourself.

blackhole54 · 07-14-2006, 07:59 AM

jschiwal,

While blocking spoofed packets from the I-net is always a good thing to do, that wouldn't account for the netstat results. A malicious packet can always claim to come from 127.x.x.x, but if its destination is 127.x.x.x, it could never be routed to the machine in the first place. The netstat entry had 127.0.0.1 as both its source and destination address.

CORRECTION: I suppose such a thing could come in from a LAN if a malicous machine obtained the victim's MAC address and sent a packet to it with a loopback destination address. But such a thing could never get past an uncompromised properly functioning router.

Capt_Caveman · 07-14-2006, 08:30 PM

Quote:

Originally Posted by blackhole54

CORRECTION: I suppose such a thing could come in from a LAN if a malicous machine obtained the victim's MAC address and sent a packet to it with a loopback destination address. But such a thing could never get past an uncompromised properly functioning router.

Theoretically that's correct, but in practice many ISPs will fail to filter odd-ball packets like those using IANA reserved addresses, especially in the last mile.

@Djjules: note that an email sent locally would result in a connection such as the one in your logs. May be informative to check your email logs for anything like a system message or log summary being mailed to root around that time.

An SSH tunnel should be readily apparent in the netstat output (assuming that the netstat output is real). Could you post the full netstat output, not just the grepped results.

Djjules · 07-17-2006, 11:34 AM

Quote:

Originally Posted by blackhole54

I think you already know this, but just in case ... The "TIME_WAIT" means you just missed the connection and it is waiting to totally shut the connection down. This is why no process is listed.

Ok, and thnx for the clearance

Quote:

Originally Posted by blackhole54

Are you saying the above output from netstat was with 127.0.0.1 blocked on the OUTPUT chain?

Yep, but somehow the connection is haunting again on Firestarter list even though it should be blocked. And again the port is changed.

Quote:

Originally Posted by blackhole54

If so, and if you are comfortable doing so, repeating this test w/o blocking the loopback address might reveal the process doing this. (If you're worried about potential bad things happening while you test, you could briefly block all output from your machine to the outside world during the test.) You could also try to use tcpdump to catch packets going to and from 127.0.0.1:25 to see if you can figure out what is being attempted. If you have the connection blocked you probably won't see much since it can't even complete the handshake.

If your routing table is set up properly (check with route -n), anything going out to 127.x.x.x should not leave your machine. I would not think your mail server would need this, but I am not an expert.

I did the tcpdump for awhile and didn't get anything else weird but a connecion to port 32772 and I guess that is the domain name server related. I got none 127.0.0.1 traffic.

and my route table is the following:

Code:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
194.x.x.x       0.0.0.0         255.255.255.252 U     0      0        0 eth0
10.0.0.0        0.0.0.0         255.255.255.0   U     0      0        0 eth1
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth1
0.0.0.0         194.x.x.x       0.0.0.0         UG    0      0        0 eth0

so no 127.0.0.1 connections listed here...

Djjules · 07-17-2006, 11:48 AM

Quote:

Originally Posted by Capt_Caveman

@Djjules: note that an email sent locally would result in a connection such as the one in your logs. May be informative to check your email logs for anything like a system message or log summary being mailed to root around that time.

An SSH tunnel should be readily apparent in the netstat output (assuming that the netstat output is real). Could you post the full netstat output, not just the grepped results.

ok,

Code:

Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address               Foreign Address             State       PID/Program name   
tcp        0      0 0.0.0.0:5805                0.0.0.0:*                   LISTEN      3888/Xvnc           
tcp        0      0 127.0.0.1:783               0.0.0.0:*                   LISTEN      3276/spamd.pid      
tcp        0      0 0.0.0.0:111                 0.0.0.0:*                   LISTEN      2812/portmap        
tcp        0      0 0.0.0.0:5905                0.0.0.0:*                   LISTEN      3888/Xvnc           
tcp        0      0 0.0.0.0:21                  0.0.0.0:*                   LISTEN      855/vsftpd          
tcp        0      0 0.0.0.0:6005                0.0.0.0:*                   LISTEN      3888/Xvnc           
tcp        0      0 127.0.0.1:631               0.0.0.0:*                   LISTEN      4812/cupsd          
tcp        0      0 127.0.0.1:5335              0.0.0.0:*                   LISTEN      3111/mDNSResponder  
tcp        0      0 0.0.0.0:25                  0.0.0.0:*                   LISTEN      3258/master         
tcp        0      0 194.x.x.x:21                80.x.x.x:1461         ESTABLISHED 858/vsftpd          
tcp        0      0 194.x.x.x:5905              80.x.x.x:1456         ESTABLISHED 3888/Xvnc           
tcp        0      0 :::993                      :::*                        LISTEN      3202/dovecot        
tcp        0      0 :::995                      :::*                        LISTEN      3202/dovecot        
tcp        0      0 :::110                      :::*                        LISTEN      3202/dovecot        
tcp        0      0 :::143                      :::*                        LISTEN      3202/dovecot        
tcp        0      0 :::80                       :::*                        LISTEN      3294/httpd          
tcp        0      0 :::6005                     :::*                        LISTEN      3888/Xvnc           
tcp        0      0 :::22                       :::*                        LISTEN      3175/sshd           
tcp        0      0 :::443                      :::*                        LISTEN      3294/httpd          
udp        0      0 0.0.0.0:67                  0.0.0.0:*                               660/dhcpd           
udp        0      0 0.0.0.0:5353                0.0.0.0:*                               3111/mDNSResponder  
udp        0      0 0.0.0.0:5353                0.0.0.0:*                               3111/mDNSResponder  
udp        0      0 0.0.0.0:111                 0.0.0.0:*                               2812/portmap        
udp        0      0 0.0.0.0:631                 0.0.0.0:*                               4812/cupsd          
udp        0      0 10.0.0.1:123                0.0.0.0:*                               3194/ntpd           
udp        0      0 194.x.x.x:123          0.0.0.0:*                               3194/ntpd           
udp        0      0 127.0.0.1:123               0.0.0.0:*                               3194/ntpd           
udp        0      0 0.0.0.0:123                 0.0.0.0:*                               3194/ntpd           
udp        0      0 :::123                      :::*                                    3194/ntpd           
raw        0      0 0.0.0.0:1                   0.0.0.0:*                   7           660/dhcpd

I wasn't sure if you wanted the WHOLE output?

I was logged in with VNC and I was running ftp connection myself.

And the 127.0.0.1:58324 connection was present at the time I was posting this (according to Firestarter).

Super7 · 07-17-2006, 12:25 PM

Are you running postfix by change for your email server? If so I think I know what that localhost:25 is, aswell I can tell you how to do an alternative port for email aswell (with postfix)

blackhole54 · 07-17-2006, 08:31 PM

Quote:

Originally Posted by Djjules

my route table is the following:

Code:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
194.x.x.x       0.0.0.0         255.255.255.252 U     0      0        0 eth0
10.0.0.0        0.0.0.0         255.255.255.0   U     0      0        0 eth1
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth1
0.0.0.0         194.x.x.x       0.0.0.0         UG    0      0        0 eth0

so no 127.0.0.1 connections listed here...

The routing table should have the following line:

Code:

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo

Otherwise, anything with a loopback address will get routed out your default route (the one with destination and mask of 0.0.0.0), in your case eth0, instead of to the loopback interface.

It looks to me like something screwy is going on.

Does your gateway machine's (194.x.x.x) firewall show any packets coming in on eth0 with a destination address of 127.0.0.1?

Djjules · 07-18-2006, 01:24 AM

Quote:

Originally Posted by Super7

Are you running postfix by change for your email server? If so I think I know what that localhost:25 is, aswell I can tell you how to do an alternative port for email aswell (with postfix)

Yes, you are correct. I'm running postfix as my email server.

Djjules · 07-18-2006, 01:41 AM

Quote:

Originally Posted by blackhole54

The routing table should have the following line:

Code:

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo

Otherwise, anything with a loopback address will get routed out your default route (the one with destination and mask of 0.0.0.0), in your case eth0, instead of to the loopback interface.

K, done that. Now the route table is:

Code:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
127.0.0.0       0.0.0.0         255.255.255.255 UH    0      0        0 lo
194.x.x.x       0.0.0.0         255.255.255.252 U     0      0        0 eth0
10.0.0.0        0.0.0.0         255.255.255.0   U     0      0        0 eth1
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth1
0.0.0.0         194.x.x.x       0.0.0.0         UG    0      0        0 eth0

I couldn't get the Genmask to 255.0.0.0 but I guess that the above works.

Quote:

Originally Posted by blackhole54

It looks to me like something screwy is going on.

Hope we can fix this

Quote:

Originally Posted by blackhole54

Does your gateway machine's (194.x.x.x) firewall show any packets coming in on eth0 with a destination address of 127.0.0.1?

I didn't catch any packages going to 127.0.0.1, but I did the tcpdump just for a little while. I'll do a longer scan today and check if there is anything 127.0.0.1 related. So at least there is no heavy traffic going on there.

BTW is there a way to exclude the VNC traffic from the tcpdump so I could reduce the list size?

And just for my clearance, there is 6 workstations under the server so the upper 194.x.x.x is for the ADSL router and the other 194.x.x.x is the GW IP for my server.

My server's public IP is not on the route list, is this ok?

blackhole54 · 07-18-2006, 04:50 AM

Quote:

Originally Posted by blackhole54

The routing table should have the following line:

Code:

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo

Otherwise, anything with a loopback address will get routed out your default route (the one with destination and mask of 0.0.0.0), in your case eth0, instead of to the loopback interface.

It looks to me like something screwy is going on.

Does your gateway machine's (194.x.x.x) firewall show any packets coming in on eth0 with a destination address of 127.0.0.1?

Djjules, I am no longer certain about the routing table needing the above entry. The tables I had looked at had always had it. But I just ran an experiment with Damn Small Linux. It had an absolutely empty routing table and it routed loopback just fine. Perhaps the absence of such a line doesn't mean something is amiss after all. Maybe somebody else can enlighten me about this.

In any case, such a line would not hurt. The line you entered is not correct. It will route only packets with exactly the address 127.0.0.0, and no packet should have that address.

You can delete the old entry and add the correct one with the first two lines below.The third line is an alternate form of the second line which I am providing just for your info. (If you use both you will get an error.)

Code:

route del  127.0.0.0 lo
route add -net 127.0.0.0/8 lo
route add -net  127.0.0.0 netmask 255.0.0.0 lo

The "-net" says it is for a range of addresses, and that range is specified with the slash eight. The slash eight means only pay attention to the first eight bits of the address; it is a shorthand for 255.0.0.0. (You might want to do some reading on "dotted decimal notation" for IP addresses.)

Quote:

Originally Posted by Djjules

I didn't catch any packages going to 127.0.0.1, but I did the tcpdump just for a little while. I'll do a longer scan today and check if there is anything 127.0.0.1 related. So at least there is no heavy traffic going on there.

As I suggested before, you will probably not catch more than the first packet (the "syn" packet) if you have 127.0.0.1 blocked on your OUTPUT chain.

Quote:

BTW is there a way to exclude the VNC traffic from the tcpdump so I could reduce the list size?

The following will monitor for all TCP/25 activity on the address range 127.x.x.x which is what you are interested in. VPN activity should not show up. You may add any options you have been using.

Code:

tcpdump net 127.0.0.0/8 and tcp port 25

----

Maybe Super7 can clear up this whole mystery.