• Ok this is my first post here so be gentle. :) Im not new to firewalls or network security, but this one is really weird to me.

    I was doing some analysis with Wireshark on one of my systems and noticed a repeated connection to 64.233.171.125. Every 2 to 5 seconds my system sends out an ~84 byte packet to port 5222 (XMPP) with a 60 byte return. So far I have been able to traceroute in about 12 hops. DNS lookups produce no information, though I have only begun to investigate this IP. I have seen mentions of Google datacenters in the 64.233.171.x range, but nothing for this specific IP.

    My problem is that I cannot seem to block this IP AT ALL. I have tried it both as a floating rule and linked to the interface. I have even put a block on the offending workstation. I can block other Internet traffic on the offending system, But this IP will not be blocked. Has anyone else had trouble with blocking specific IPs from the Internet.

    Thanks!

    EDIT: I found the culprit googledrivesync.exe. So now I know what it is but I still cannot block it with pfSense. Still a mystery.

  • LAYER 8 Netgate

    No opinion on how effective this will be (If you really want to block this stuff, a much better approach is to pass what you want to let through and block everything else.)

    This floating rule will block it.

    Note that if this is a persistent connection it will only block subsequent connections.  You ought to be able to view states, filter on 64.233.171.125, then just clear those to cause immediate effect.

    If you know which LAN interface this traffic is originating on, you could also block it there.  Reject IPv4 TCP/UDP Source LAN net dest 64.233.171.125 dest port 5222.

    ETA: Checked the Apply immediately on match checkbox.  You want that on for this…

    ![Screen Shot 2014-11-29 at 11.32.55 AM.png_thumb](/public/imported_attachments/1/Screen Shot 2014-11-29 at 11.32.55 AM.png_thumb)
    ![Screen Shot 2014-11-29 at 11.32.55 AM.png](/public/imported_attachments/1/Screen Shot 2014-11-29 at 11.32.55 AM.png)


  • Yeah, whitelisting is definitely more secure than blacklisting, but its a bear to maintain.

    I did try to generate new communications using ping with the "any" protocol and "any" port options set. Still got my pings through.

  • LAYER 8 Netgate

    You're going to have to post some screenshots then because things are not how they seem.


  • Delete states for that IP after you add the block rule if you want to kill already-established sessions.

  • LAYER 8 Global Moderator

    I would look to the workstation vs just blocking it, a google for 5222 comes up with google talk..

    I fired up a a old copy and sure enough

    64.233.182.125.5222

    You sure the IP is not changing on you for a reason you can not block it?  The ttl on talk.l.google.com is like 300 seconds, so that IP could change all the time.  Is your issue that there is traffic at all, or that its every few seconds.. If somone is chatting then I would think there would be lots of traffic ;)  Why don't you just go to the machine that is generating the traffic ande look to see what is creating it?

  • LAYER 8 Netgate

    @budsecpro:

    Yeah, whitelisting is definitely more secure than blacklisting, but its a bear to maintain.

    I would argue that the thing that is a bear to maintain are reliable lists of things like google's IP addresses.


  • @johnpoz:

    I would look to the workstation vs just blocking it, a google for 5222 comes up with google talk..

    I fired up a a old copy and sure enough

    64.233.182.125.5222

    You sure the IP is not changing on you for a reason you can not block it?  The ttl on talk.l.google.com is like 300 seconds, so that IP could change all the time.  Is your issue that there is traffic at all, or that its every few seconds.. If somone is chatting then I would think there would be lots of traffic ;)  Why don't you just go to the machine that is generating the traffic ande look to see what is creating it?

    I tracked it down to the google drive sync tool. My issue was that I didnt know what it was and it appeared to be either a beacon or an exfiltration attempt. As it turned out it was a stuck app. Netstat gave me the suspect executable and once I restarted googledrivesync.exe the suspect traffic stopped as well.