Weird loopback connection... IS GONE!!
 

Hi!

For starters: :newbie: :p

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 :rolleyes:.

Thnx in advance!

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

Ok, done that and the output is like:

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? :scratch:

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.

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.

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.

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.)

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.

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.

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.

Ok, and thnx for the clearance :study:

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

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:

so no 127.0.0.1 connections listed here...

ok,

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).

Email Server
 

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)

The routing table should have the following line:

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?

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

K, done that. Now the route table is:

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

:confused: :confused: :confused:

Hope we can fix this :rolleyes:

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. :scratch:

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

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.)

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.)

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.

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.

----

Maybe Super7 can clear up this whole mystery. :)