Weird loopback connection...

Djjules · 07-18-2006, 05:18 AM

Quote:

Originally Posted by blackhole54

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

Jeez my noobiness

But ok, I made the above changes and now the line is exactly as you allready mentioned.

Quote:

Originally Posted by blackhole54

(You might want to do some reading on "dotted decimal notation" for IP addresses.)

Gotta take a look at this.

Quote:

Originally Posted by blackhole54

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.

Code:

tcpdump net 127.0.0.0/8 and tcp port 25

Great, I'll put it up and running as soon as possible.

And I really appreciate everyones help about this matter.

Super7 · 07-18-2006, 07:16 AM

I think this is your postfix sitting there on 127.0.0.1, if you refer to your master.cf you will notice that postfix smtpd content filter runs on 127.0.0.1 it transmits to itself.

Code:

127.0.0.1:10026	inet	n	-	y	-	-	smtpd
  -o content_filter=
  -o smtpd_restriction_classes=
  -o smtpd_client_restrictions=
  -o smtpd_helo_restrictions=
  -o smtpd_sender_restrictions=
  -o smtpd_recipient_restrictions=permit_mynetworks,reject
  -o mynetworks=127.0.0.0/8
  -o mynetworks_style=host
  -o strict_rfc821_envelopes=yes
  -o receive_override_options=no_unknown_recipient_checks,no_header_body_checks
  -o smtpd_client_connection_limit_exceptions=127.0.0.0/8

Once again maybe I might be wrong :P

blackhole54 · 07-18-2006, 10:15 PM

Quote:

Originally Posted by blackhole54

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.

I need to modify this statement slightly also. If you have the block on the OUTPUT chain you won't see any packets, because they will be blocked by netfilter before they even get to the interface. (Yeah, ran another experiment on DSL!

) If you block on the INPUT chain instead, you will see the "syn" packet exit through loopback and re-enter through loopback, but it can't get any further. It may try this several times before it gives up.

Djjules · 07-20-2006, 03:51 AM

Quote:

Originally Posted by Super7

I think this is your postfix sitting there on 127.0.0.1, if you refer to your master.cf you will notice that postfix smtpd content filter runs on 127.0.0.1 it transmits to itself.

Code:

127.0.0.1:10026	inet	n	-	y	-	-	smtpd
  -o content_filter=
  -o smtpd_restriction_classes=
  -o smtpd_client_restrictions=
  -o smtpd_helo_restrictions=
  -o smtpd_sender_restrictions=
  -o smtpd_recipient_restrictions=permit_mynetworks,reject
  -o mynetworks=127.0.0.0/8
  -o mynetworks_style=host
  -o strict_rfc821_envelopes=yes
  -o receive_override_options=no_unknown_recipient_checks,no_header_body_checks
  -o smtpd_client_connection_limit_exceptions=127.0.0.0/8

Once again maybe I might be wrong :P

Well my master.cf looks like this:

Code:

#
# Postfix master process configuration file.  For details on the format
# of the file, see the Postfix master(5) manual page.
#
# ==========================================================================
# service type  private unpriv  chroot  wakeup  maxproc command + args
#               (yes)   (yes)   (yes)   (never) (100)
# ==========================================================================
smtp      inet  n       -       n       -       -       smtpd
#submission inet n      -       n       -       -       smtpd
#	-o smtpd_etrn_restrictions=reject
#	-o smtpd_client_restrictions=permit_sasl_authenticated,reject
#smtps    inet  n       -       n       -       -       smtpd
#  -o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes
#submission   inet    n       -       n       -       -       smtpd
#  -o smtpd_etrn_restrictions=reject
#  -o smtpd_enforce_tls=yes -o smtpd_sasl_auth_enable=yes
#628      inet  n       -       n       -       -       qmqpd
pickup    fifo  n       -       n       60      1       pickup
cleanup   unix  n       -       n       -       0       cleanup
qmgr      fifo  n       -       n       300     1       qmgr
#qmgr     fifo  n       -       n       300     1       oqmgr
tlsmgr    unix  -       -       n       1000?   1       tlsmgr
rewrite   unix  -       -       n       -       -       trivial-rewrite
bounce    unix  -       -       n       -       0       bounce
defer     unix  -       -       n       -       0       bounce
trace     unix  -       -       n       -       0       bounce
verify    unix  -       -       n       -       1       verify
flush     unix  n       -       n       1000?   0       flush
proxymap  unix  -       -       n       -       -       proxymap
smtp      unix  -       -       n       -       -       smtp
# When relaying mail as backup MX, disable fallback_relay to avoid MX loops
relay     unix  -       -       n       -       -       smtp
	-o fallback_relay=
#       -o smtp_helo_timeout=5 -o smtp_connect_timeout=5
showq     unix  n       -       n       -       -       showq
error     unix  -       -       n       -       -       error
discard   unix  -       -       n       -       -       discard
local     unix  -       n       n       -       -       local
virtual   unix  -       n       n       -       -       virtual
lmtp      unix  -       -       n       -       -       lmtp
anvil     unix  -       -       n       -       1       anvil
scache	  unix	-	-	n	-	1	scache
#
# ====================================================================
# Interfaces to non-Postfix software. Be sure to examine the manual
# pages of the non-Postfix software to find out what options it wants.
#
# Many of the following services use the Postfix pipe(8) delivery
# agent.  See the pipe(8) man page for information about ${recipient}
# and other message envelope options.
# ====================================================================
#
# maildrop. See the Postfix MAILDROP_README file for details.
# Also specify in main.cf: maildrop_destination_recipient_limit=1
#
maildrop  unix  -       n       n       -       -       pipe
  flags=DRhu user=vmail argv=/usr/local/bin/maildrop -d ${recipient}
#
# The Cyrus deliver program has changed incompatibly, multiple times.
#
old-cyrus unix  -       n       n       -       -       pipe
  flags=R user=cyrus argv=/usr/lib/cyrus-imapd/deliver -e -m ${extension} ${user}
# Cyrus 2.1.5 (Amos Gouaux)
# Also specify in main.cf: cyrus_destination_recipient_limit=1
cyrus     unix  -       n       n       -       -       pipe
  user=cyrus argv=/usr/lib/cyrus-imapd/deliver -e -r ${sender} -m ${extension} ${user}
#
# See the Postfix UUCP_README file for configuration details.
#
uucp      unix  -       n       n       -       -       pipe
  flags=Fqhu user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail ($recipient)
#
# Other external delivery methods.
#
ifmail    unix  -       n       n       -       -       pipe
  flags=F user=ftn argv=/usr/lib/ifmail/ifmail -r $nexthop ($recipient)
bsmtp     unix  -       n       n       -       -       pipe
  flags=Fq. user=foo argv=/usr/local/sbin/bsmtp -f $sender $nexthop $recipient

Does this help?

Djjules · 07-20-2006, 03:55 AM

Quote:

Originally Posted by blackhole54

I need to modify this statement slightly also. If you have the block on the OUTPUT chain you won't see any packets, because they will be blocked by netfilter before they even get to the interface. (Yeah, ran another experiment on DSL!

) If you block on the INPUT chain instead, you will see the "syn" packet exit through loopback and re-enter through loopback, but it can't get any further. It may try this several times before it gives up.

Ok, I took the restriction away from the Firestarter. So now it is not blocking the outbound nor inbound traffic on 127.0.0.1. I'll try the tcpdump once again...

Djjules · 07-20-2006, 04:14 AM

I don't get this for real.

To my knowledge, to see a connection on Firestarter there should be traffic through that connection, otherwise it should disappear from FS list.

And with tcpdump, I get nothing.

This is just me thinking aloud, but is it possible that this connection is masquerated somehow to look like 127.0.0.1 connection on FS??

Additional info: There was this little weird thing little while before this loopback strated to haunt:

On my dhcpd.conf I have a static IP for my laptop, in case I connect it to the network. One day I took a look at the FS lists and even though my laptop wasn't even near the network, FS list showed an active connection with that IP. At the time I panicked and rebooted the server and the connection was lost. But then this 127.0.0.1 started to show up, and it wouldn't go away even after a reboot.

Is it possible that one of my workstations somehow got that IP and I didn't notice. All the networked workstations should have a static IP from DCHP (at least I have made the rules). Or was there someone else messing around. I guess that is hard to tell with this info.

Oh, and I'm thinking of installing the Core 5 to a new HD so I could get rid of this confusing situation.

I just hate the idea of doing this installation process again from a scratch for such a reason.

blackhole54 · 07-20-2006, 06:31 AM

Quote:

Originally Posted by Djjules

Is it possible that one of my workstations somehow got that IP and I didn't notice. All the networked workstations should have a static IP from DCHP (at least I have made the rules). Or was there someone else messing around. I guess that is hard to tell with this info.

If you're using the Internet Software Consortium DHCP Server, dhcpd (check your man page), it maintains a file called dhcpd.leases that shows the current leases (assigned IP addresses). On my machine this file is in /var/lib/dhcp. I have never assigned static addresses, so I don't know if those are recorded there, but you might check into what info it does have. It will certainly have any dynamically assigned address. dhcpd.leases has its own man page which explains its format. Be aware that times are in UTC, not local time.

I will cogitate on the rest of your post and report back if I come up with anything. I have never used Firestarter. What is this FS list? If tcpdump isn't it picking up anything, then this wouldn't appear to be a list of actual packets. (This is assuming that neither you nor I have made a mistake with tcpdump and that this tool is not compromised.)

There is another way to check if these packets are traversing your system. I don't know if adding this iptables rule manually will confuse or get Firestarter upset. (Do your research and make your own judgement.)

Code:

iptables -I OUTPUT -s 127.0.0.0/8 -p tcp --dport 25

You can instead or in addition put the same rule on the INPUT chain. These will become the first rule of the chain. They will not block (or ACCEPT) any packets (which is why there is no "-j" option), but will count any packets matching the criterium that traverse the chain. If you want to be really paranoid, you can also put such a rule on the FORWARD chain, but as we've discussed before, packets with loopback addresses should never end up there.

To check the number of packets which have matched:

Code:

iptables -nvL OUTPUT | head

Check the iptables man page for interpretation. The counts are cummulative since you created the rule unless you manually clear them.

If you think something on your machine may have been compromised and these tools are not telling us the truth, you can look into tools for checking for rootkits. The one I am somewhat familiar with is chkrootkit, but there are others. None of these are foolproof, but they will try to check for certain known rootkits. Be aware they can also give false positives.

ADDITION: You should also have DHCP transactions recorded in /var/log/messages.

Djjules · 07-21-2006, 03:52 AM

Quote:

Originally Posted by blackhole54

What is this FS list?

Sorry, I made a fast abbreviation of "Firestarter". So when I wrote FS, I ment Firestarter...

blackhole54 · 07-21-2006, 07:38 AM

Quote:

Originally Posted by Djjules

Sorry, I made a fast abbreviation of "Firestarter". So when I wrote FS, I ment Firestarter...

I knew FS was Firestarter.

But not being familiar with Firestarter, I don't know what FS list is. In other words, please explain your application to me briefly. What is the info that is contained in this list?

Djjules · 07-24-2006, 03:30 PM

Quote:

Originally Posted by blackhole54

I knew FS was Firestarter.

But not being familiar with Firestarter, I don't know what FS list is. In other words, please explain your application to me briefly. What is the info that is contained in this list?

With Firestarter list I mean the list that appears on Firestarter GUI "frontpage". There is this list that shows active connections at the time. For example, if I go browsing internet with one of the workstations, a connection appears on the list that shows the IP of the workstation, the port it is connected to and the IP of the remote host that it is connected to.

If I stay on one webpage and do nothing (and the webpage is not refreshing itself or keeping the connection open) the connection on the list will go grey and after a short moment, disappear.

deerrunner · 07-25-2006, 08:19 AM

It is odd that the loopback address would be going out to a broadcast address using an IP header. Do you have some sort of managment tool running?

Djjules · 07-26-2006, 04:00 AM

Quote:

Originally Posted by deerrunner

It is odd that the loopback address would be going out to a broadcast address using an IP header. Do you have some sort of managment tool running?

Not that I know. What do you mean by management tool?

Oh, and yesterday the loopback was connected to xwindows port 6009 so I figured that's not normal, is it? I rebooted the server and after that the connection was again on some port near 45000.

I'm really considerating on installing totally fresh Core 5. I'm really getting spooky with this connection. I'm starting to believe that the server is compromised!!

And finally, one of our running workstation's firewalls log is showing that there has been some traffic from 127.0.0.1 to our workstation?!? How the heck that's possible?!?

EDIT: Correction: ALL of our workstations's logs are showing incoming connections from 127.0.0.1 :S

blackhole54 · 07-26-2006, 04:36 AM

Quote:

Originally Posted by deerrunner

It is odd that the loopback address would be going out to a broadcast address using an IP header. Do you have some sort of managment tool running?

Am I missing something? Where did a broadcast address get into this?

blackhole54 · 07-26-2006, 04:55 AM

Quote:

Originally Posted by Djjules

I'm really considerating on installing totally fresh Core 5. I'm really getting spooky with this connection. I'm starting to believe that the server is compromised!!

And finally, one of our running workstation's firewalls log is showing that there has been some traffic from 127.0.0.1 to our workstation?!? How the heck that's possible?!?

EDIT: Correction: ALL of our workstations's logs are showing incoming connections from 127.0.0.1 :S

Reinstallation might be a good idea. If you do so I would use different (and strong!) passwords.

You never answered my question on post #5 about whether you allow ssh access on your server. If you don't need it I would turn it off completely. (This is generally a good security rule; disable any unneeded service. Each service is a potential security hole.) If you do need ssh, read up on how to offer it in the most secure way that meets your needs. There are a number of articles on the internet about this.

Are the 127.0.0.1 connections on the workstations coming from their loopback interface, or are they coming in on ethernet? Am I correct that the workstations' only access to the Internet is through this server?

Capt_Caveman · 07-26-2006, 10:56 PM

IMO, I have yet to see anything indicative of a compromise. You can easily replicate the connection to 127.0.0.1 in the TIME_WAIT state by sending an email locally:

Code:

[root@localhost root]# netstat -nap
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         
State       PID/Program name  
tcp        0      0 :::22                   0.0.0.0:*               LISTEN      1640/sshd            
tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN      1683/sendmail: acce           

[root@localhost root]# mail root@localhost
Subject: test
test
Cc: 
[root@localhost root]# netstat -nap
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 :::22                   0.0.0.0:*               LISTEN      1640/sshd                
tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN      1683/sendmail: acce   
tcp        0      0 127.0.0.1:1444          127.0.0.1:25            TIME_WAIT   -

Try sending an email locally to see if you can replicate the FS log and netstat output. Also you've never mentioned whether or not you looked at the mail logs. If you have some type of local mail problem, you could easily have connections sit there in TIME_WAIT. It's also entirely normal to see connections from loopback-to-loopback as well as from loopback to the machines external IP. Unless you are seeing connections to unknown IP addresses, then the traffic is not leaving your box.