0

I was just watching as my bandwidth monitor spiked downloading a file. I checked my current netstat and I didn't recognize one of the IPs so I started capturing the data with Wireshark.

The situation:

  • None of my services explain the connection
  • The suspicious IP shows up as malicious Google Search and malc0de database
  • I have no idea where the data which was downloading went.
  • Wireshark shows it as a Bronze 0x20 and src port 80 to dest port 36935

My questions:

  • Where could the data have gone? It was downloading at 2.5MBps for more than a minute!
  • How can I get more specific information from my Wireshark capture?
  • What precautions should I take? Just block that IP? Anything else? Like call the Abuse number for that IP from the WhoIs info?

EDIT... More Info: It appears to be a CacheFly shared server hosted on their CacheNetworks.

AviD
  • 72,138
  • 22
  • 136
  • 218
TryTryAgain
  • 111
  • 5
  • When was your last antivirus scan? – Iszi Mar 22 '12 at 02:23
  • I'm on ubuntu...never really. I do have port 80 open in/out for webstuff. – TryTryAgain Mar 22 '12 at 02:24
  • 1
    Why open in/out? Are you running a web server? – Iszi Mar 22 '12 at 02:25
  • Possibly related, since it was the top result on a Google search for the IP: http://security.stackexchange.com/questions/12242/wireshark-log-analyzing – Iszi Mar 22 '12 at 02:26
  • Yes, and Tomcat on 8080...but this came in and continually tried something from src 80 -> dest 36935 which no service is running/using AFAIK ... and A LOT of data too! – TryTryAgain Mar 22 '12 at 02:27
  • @Iszi that was the wrong IP I had in that link...it had looked the same from when I opened the link from that post. I've updated the link with the IP for this instance. – TryTryAgain Mar 22 '12 at 02:43
  • Well, that's mildly amusing. First result is the IP itself. Apparently, it's a web server that's interested in confirming its own existence. – Iszi Mar 22 '12 at 02:45
  • @Iszi huh, Skynet with existential issues, who would have thought... – AviD Mar 22 '12 at 13:33

2 Answers2

2

From the wireshark perspective, one approach might be to look through the capture for ascii strings (using Follow TCP stream) and then search your hard drive for the same string. If you can find something suitably unique, that might lead you to the downloaded data.

The pair of ports you descibe sounds like a standard web site download (the high port just being randomly assigned to receive the data)

Do you have any automated updating facilities turned on (OS/browser etc)? One potential source of a largish unknown download would be software updating itself.

As you're running externally facing services from the box there is the chance that you've been compromised and that download was someone putting tools onto your system. If that's the case you should do a thorough search of the server (some good information here)

Community
  • 1
Rory McCune
  • 60,923
  • 14
  • 136
  • 217
  • 1) That helps, but if I view the TCP stream of Frames in ASCII, Hex, anything...it always comes out pretty malformed looking. 2) That's good to know. 3) Nothing that I'm not aware of and have truested IPs for those services. 4) Very helpful, I will look into some of those best practices for incident response. – TryTryAgain Mar 22 '12 at 15:03
  • Also, this is scary, the suspicious IP is not in any logs (which is very strange) only trace I can find is my lucky Wireshark capture. – TryTryAgain Mar 22 '12 at 15:25
  • And, my History has what appears to be binary data at the beginning...then towards the bottom are the last commands used. Unfortunately my history size has nothing before the binary blob as I'm sure it ran out of space. I've since increased the History size. – TryTryAgain Mar 22 '12 at 15:39
2

Don't just block one IP -- that's a losing battle - if one IP got in to do nefarious activities others can (or the same person using other IPs).
Also, you say that they connected from src 1.1.1.1:80 (pretending your IP is 1.1.1.1) to dest 205.234.175.175:36935 (port 36935 on their IP) -- this seems normal for an ordinary connection to your webserver on port 80 (try this for yourself). Basically, when a client establish a TCP connection to a webserver on port 80, the client chooses an arbitrary unused port (1024-65535) in this case 36935 for traffic to be sent from/received at on their end.

  • Close ports/services you aren't using. You need to test web stuff? Fine, open port 80 for local IP addresses (e.g., 192.168.0.0/16). In ubuntu with say ufw (uncomplicated firewall - a thin wrapper for iptables rules) this can be done with rules like sudo ufw allow to tcp port 80 from 192.168.0.0/16.

  • Check logs. Your web server logs, firewall logs, auth.log, etc.

  • Set up fail2ban or honeypots to slow down attackers.

  • Make sure you have no default or easy-to-guess/brute force passwords set for any accounts.

dr jimbob
  • 38,768
  • 8
  • 92
  • 161
  • It was actually src 205.234.175.175:80 to localhost:36935 – TryTryAgain Mar 22 '12 at 15:37
  • 2
    @TryTryAgain - Weird. Being on a CDN and not having other info besides the IP; its difficult to figure out who your server was sending data to. http://www.yougetsignal.com/tools/web-sites-on-web-server/ lists 347 domains on that IP at that IP. If it happens again, try running `netstat -n -p` to find the process establishing the connection. Also, since you know roughly what time it was; you could potentially run `find` on your system to find files that were created/modified around then. E.g., `find / -mmin +10 -mmin -20` will find files last modified between 10 and 20 minutes ago. – dr jimbob Mar 22 '12 at 16:21
  • Okay, well, I assume that is a shared IP like I thought initially. I will utilize `find` yougetsignal web-sites-on-server is a great tool, thanks for sharing. `netstat -n -p` is good to know. If I were to report abuse on a shared server with that many possible different users, is there any way for me to provide deeper more direct information for the abuse team to investigate? I had linked this post on G+ and someone I know mentioned their Norton on OSX just blocked that exact IP! I assume I can get past that wall with the right information, no? – TryTryAgain Mar 22 '12 at 16:37