4

Folks, have a weird one, need your expert help. For one of our heavily used external facing server which came up in an audit, nmap -Pn scan shows the following:

    Starting Nmap 5.51 ...
    Host pub.ip is up (0.0032s latency).
    Not shown: 993 filtered ports
    PORT     STATE  SERVICE
    21/tcp   open   ftp
    22/tcp   open   ssh
    80/tcp   open   http
    113/tcp  closed auth
    119/tcp  open   nntp
    8008/tcp open   http
    8010/tcp open   xmpp

Now this is a public FTP/SFTP server and netstat /lsof on the physical host confirms that only port 21 (ftp), 22 (ssh) and 25 (internal smtp) are listening.

ASA FW config shows that it only allows NAT from pub ip to the internal IP on ftp / ssh:

 static (dmz3,pub1) pub.ip internalftp.ip netmask 255.255.255.255
 access-list pub1_access_in extended permit tcp any host pub.ip eq ftp
 access-list pub1_access_in extended permit tcp any host pub.ip eq ssh

Thats it. No entries for 8010 or port 8008 in the entire FW config.

But here is the confusing part:

When I try to open a socket (using telnet) on port 8008, I do get a socket and when I type HEAD / or GET /, I get the following redirect to secure port 8010:

HTTP/1.1 302 Found
Location: https://:8010
Connection: close

Connection to host lost.

I am able to open a socket on port 8010 as well but yields nothing, nothing thru the browser or wireshark.

Gets interesting, on the physical ftp/sftp server, a quick 

#tcpdump -nni eth0 port 80 or port 8008 or port 8010

yields no traffic when I get a socket on my client. So def. the connection is being established somewhere else.

So here comes - What is list on the socket / est the connection on the server side !?

One forum/thread suggested a possible smart router/fw in the mix trying to spoof/mislead a hacker. True !?

Either way, how to go about finding exactly where the connection is getting established.

ps: I only have read priv on the ASA side. So will not be able to run any troubleshooting there. Will have to pass it on ASA/NW admin.

Thank you in advance for your time and valued help.

Output of "netstat -taulpn | grep LISTEN" as requested :

tcp        0      0 10.x.x.x:427            0.0.0.0:*               LISTEN      3779/slpd
tcp        0      0 127.0.0.1:427           0.0.0.0:*               LISTEN      3779/slpd
tcp        0      0 0.0.0.0:111             0.0.0.0:*               LISTEN      3843/portmap
tcp        0      0 127.0.0.1:2544          0.0.0.0:*               LISTEN      4081/zmd
tcp        0      0 0.0.0.0:21              0.0.0.0:*               LISTEN      4042/xinetd
tcp        0      0 10.x.x.x:22             0.0.0.0:*               LISTEN      4190/sshd
tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN      4282/master
tcp        0      0 ::1:25                  :::*                    LISTEN      4282/master

Update: Sorry folks, further troubleshooting each of the hops, the above is only true when we scan the external IP from our internal n/w. So we were not truly going out. On my way out the internal interface of our edge router routes it directly to the ASA. And turns out this internal interface is listening on these ports, which we are not sure why. Nothing in its config and we have raised the question with the provider. Maybe a default Cisco 7200 behavior.

So the real test using a DSL line reveals only port 21/22 open on the outside. And doing a scan on the edge router (external interface) shows no ports open.

So we are ok for now. Still need to figure out "why" from inside. Will post one last update after we find out.

Thanks every one. Value your time and help.

user3196304
  • 41
  • 1
  • 4
  • 1
    Without knowing architecture, I would guess that either 1.) that ports are open on the firewall appliance itself or 2.) there's some virtual IP or port/IP translation (meaning port 8008/8010 are open on some other host than your FTP box, and the firewall is sending the traffic there) – jlehtinen Apr 16 '15 at 14:07
  • Thx. Arch in this case is very simple: Cloud --> Edge Router -> ASA (NAT) port 21/22 --> Internal Server. Nothing else in between as far as I know. On the ASA config, like I said nothing in the FW config for port 8008/8010 so no translations at the port level. – user3196304 Apr 16 '15 at 23:41
  • If you have limited privs for the networking devices, it's possible that the entire config or the section that is doing this is masked or hidden for your user. I would ask the admins with full access to check into this, I think it's a very legit question. – jlehtinen Apr 17 '15 at 01:20
  • "*the above is only true when we scan the external IP from our internal n/w.*" and "*the real test using a DSL line reveals only port 21/22 open on the outside*" show that there's some kind of NAT and/or DNS rewrite or something on the ASA that is responding to the connection attempts. – Todd Wilcox Nov 29 '17 at 21:12

1 Answers1

1

I would check the output of

netstat -an

to see which interface the listeners are on for 8008 and 8080. It is possible they are only listening on the loopback interface, in which case the traffic would have to be initiated from localhost.

Chad Smith
  • 1,389
  • 7
  • 8
  • thx, I did mention netstat / lsof shows server listening on ports 21,22 & 25 incl loopback. – user3196304 Apr 16 '15 at 05:13
  • what is the output of netstat -taulpn? – Chad Smith Apr 16 '15 at 05:18
  • Chad, added to the main section. – user3196304 Apr 16 '15 at 23:51
  • xmpp is a strange protocol type to show up on this server, and it is also strange that netstat doesn't show the ports open. Have you considered the possibility that this server has been compromised, but they didn't fully cover their tracks? – Chad Smith Apr 17 '15 at 00:01
  • I've seen rootkit exploits that replace all the various libraries that reference a particular service, but there is always a trail if you're stubborn enough to find it. I'm not leaning toward a break-in as the cause of this, but its worth checking, just in case. – Chad Smith Apr 17 '15 at 00:35
  • As mentioned tcpdump on the server does not log any packets when I open a socket on port 8008 from outside. So if compromised, they would have replaced tcpdump along with netstat and other utils as well. They would have required a root shell and root access is pretty tight, unless they exploited a vulnerability. Let me follow-up on that – user3196304 Apr 17 '15 at 01:35
  • Ok, tried non-altered tcpdump and netstat binary from another server - freshly spun SLES11 SP3. (left libpcap the same). Verified checksum on most of my SLES11 servers to be the same. The server in question is the only SLES10 box in our setup, so could not verify checksum. But anyway tcpdump and netstat using the copied binaries show the same results. Would not mean much if libpcap was alerted. Since it is a prod box, did not want to compile in a new libpcap not knowing what could be affected. Anything else I can look at to see if box has been altered. We do have a FIM in place, so I doubt it. – user3196304 Apr 17 '15 at 01:50