This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

tcpdump auf Sophos UMT - Linux Shell, How can I find a communication to IP 107.6.74.76. Are there other methods?

Hi all,

Since days we have the following entries in the Advanced Thread Protection





We want to find out which host in our network is communicating to IP 107.6.74.76 over a Unix/Linux shell with 
the command

tcpdump -nei any port 53 dst 107.6.74.76 -n -s0 -w /var/sec/chroot-httpd/var/webadmin/tcpdump.pcap


Is this a way? Are there any other ways?

KR
Olli



This thread was automatically locked due to age.
Parents
  • Hi Oliver,

    the information in the ATP are sometimes misleading. First check the ATP Log (from the webadmin log sections or /var/log/aptp.log).

    I guess your events are from a DNS reverse lookup for the IP 107.6.74.76 to your configured Google-DNS (8.8.8.8). In this case your tcpdump filter will not catch future attempts.

    bye Josef

    BERGMANN engineering & consulting GmbH, Wien/Austria

  • I have the same issue since days, and the log is not showing any valid information:

    2023:07:01-17:07:54 firewall afcd[7105]: id="2022" severity="warn" sys="SecureNet" sub="packetfilter" name="Packet dropped (ATP)" srcip="8.8.8.8" dstip="Firewall External IP Address" fwrule="63001" proto="17" threatname="C2/Generic-A" status="1" host="107.6.74.76" url="-" action="drop"



Reply
  • I have the same issue since days, and the log is not showing any valid information:

    2023:07:01-17:07:54 firewall afcd[7105]: id="2022" severity="warn" sys="SecureNet" sub="packetfilter" name="Packet dropped (ATP)" srcip="8.8.8.8" dstip="Firewall External IP Address" fwrule="63001" proto="17" threatname="C2/Generic-A" status="1" host="107.6.74.76" url="-" action="drop"



Children
  • Your Firewall has dropped an answer from the Google DNS 8.8.8.8 which resolves a DNS-query to the IP 107.6.74.76 which is a known malware/attacking host.

    You probably use the Firewall as recursive DNS resolver and have configured Google DNS 8.8.8.8 as DNS Forwarder (check Network Services->Global and Forwarders). So if one of your internal clients requests a DNS-name wich resolves to a bad IP the ATP in the Firewall gets that bad answer from the Forwarder and blocks it.

    To find the client which originates this bad queries you can assign the Google DNS directly as DNS option in your DHCP server (depends on your setup, maybe only a good option for a guests-network).

    bye Josef

    BERGMANN engineering & consulting GmbH, Wien/Austria

  • Hello Josef
    The problem is that I am trying to reproduce the same event by trying to attempt a domain that point to that bad IP address, and in any case I am able track the source IP. I can find the internal host from my DNS logs on my internal DNS server.
    But when really happened I am not able to find the source.

    I am trying everything since 2 months, but no result. 

  • Hi Petrit,

    do I unterstand you right, you know the internal host with triggered the event, but you don't know which DNS-query or application on that host triggered it?

    I would try to capture the traffic directly on that host with wireshark. In any case check that host with an offline malware tool.

    bye Josef

    BERGMANN engineering & consulting GmbH, Wien/Austria

  • No, I am not able to find the internal host.
    Sophos Firewall is not showing the internall ip, just 8.8.8.8 that is trying to reply to the Firewall with the bad IP address (107.6.74.76)
    I have collected all DNS logs from Domain Controller and there is no dns query that correspond that bad IP address.

    2023:07:01-17:07:54 firewall afcd[7105]: id="2022" severity="warn" sys="SecureNet" sub="packetfilter" name="Packet dropped (ATP)" srcip="8.8.8.8" dstip="Firewall External IP Address" fwrule="63001" proto="17" threatname="C2/Generic-A" status="1" host="107.6.74.76" url="-" action="drop"

    tcpdump is not showing anything when this event is triggered.

  • Does not need to be an internal host. If your firewall exposes services to the outside (say, SMTP Port 25) a reverse lookup is initiated on the firewall itself upon connection requests.

  • Hi Alan,
    It is not SMTP, because when I am trying to reproduce SMTP is showing differently.