Finding internal IP causing block

bmeeks

@nogbadthebad said in Finding internal IP causing block:

I occasionally see this alert only on my WAN interface, never ever see it on my snort enabled LAN interfaces.

In your screenshot it shows 8.8.8.8 using port 53 ( DNS ) talking to the WAN interface, very odd.

Here is a very long thread on this rule going all the way back to 2014 at least. I have not had the chance to read it all yet.

andrewhancock91

@bmeeks
I definitely see what you're saying but I have disabled blocking and set Snort to alert only while trying to troubleshoot this but the states are still not there. I also have Snort running on my LAN interface in alert only with the same ruleset that is applied to the WAN but it doesn't trigger any of these DNS errors, it actually only triggers alerts for internal traffic (I have multiple LAN interfaces)

@NogBadTheBad
Sounds like you've experienced what I'm seeing, it only triggers on the WAN interface. I've tried changing my DNS to different things like 9.9.9.9 or OpenDNS and the alert follows whatever DNS servers I'm currently using so the requests are definitely being triggered from something on the LAN.

bmeeks

@andrewhancock91

Here is the final topic from the thread I linked: It explains why the source address is 8.8.8.8 and port 53. Read the reply from the Anubis guy and then the question from "Leonard" below it.

You can also back up one to a previous message to get a better explanation.

andrewhancock91

Okay so what I get from that thread is that something on my network is connecting to a know bad domain that Anibus has redirected to one of their sinkholes for threat investigation, thats all fine and I can appreciate what they are trying to do. My problem is trying to find out which device or devices are connecting to the domain being sinkholed. I suppose I could do a reverse DNS on all 64 addresses in that block and compile a list of all domains that resolve there then look in my DNS logs for what device is requesting one of those domains?

NogBadTheBad

If you use unbound add "log-queries: yes" as a custom option, you then may be able to tie together the snot alert and host by looking at the timestamps.

This will create a lot of entries, I send my logs via syslog to my Synology NAS.

You'll see entries for queries from the clients like this:-

Feb 17 11:04:06 unbound 9828:3 info: 172.16.2.10 1.0.16.172.in-addr.arpa. PTR IN
Feb 17 11:03:45 unbound 9828:3 info: 2a02:xxxx:xxxx:xxxx::29 gateway.fe.apple-dns.net. A IN
Feb 17 11:03:45 unbound 9828:3 info: 2a02:xxxx:xxxx:xxxx::29 gateway.icloud.com. A IN

NogBadTheBad

(Event)
sensor id: 0 event id: 3572891651 event second: 1550493993 event microsecond: 746171
sig id: 2018455 gen id: 1 revision: 5 classification: 33
priority: 1 ip source: 184.73.137.229 ip destination: XX.XX.XX.XX
src port: 53 dest port: 58142 protocol: 17 impact_flag: 0 blocked: 0
mpls label: 0 vland id: 0 policy id: 0 appid: DNS

Packet
sensor id: 0 event id: 3572891651 event second: 1550493993
packet second: 1550493993 packet microsecond: 746171
linktype: 0 packet_length: 94
[ 0] 02 00 00 00 45 00 00 5A AF F9 40 00 F0 11 36 BD ....E..Z..@...6.
[ 16] B8 49 89 E5 52 45 0F 68 00 35 E3 1E 00 46 62 81 .I..RE.h.5...Fb.
[ 32] 06 B9 84 00 00 01 00 01 00 00 00 01 02 6E 73 07 .............ns.
[ 48] 68 65 74 73 70 74 74 03 6E 65 74 02 63 6E 00 00 hetsptt.net.cn..
[ 64] 01 00 01 C0 0C 00 01 00 01 00 00 00 64 00 04 C3 ............d...
[ 80] 16 1A F8 00 00 29 06 90 00 00 80 00 00 00 .....)........```

Looks like its a dns request to ns.hetsptt.net.cn that's doing it.

Seems to happen when my Nest smoke alarms get a bit chatty.

More investigation needed.

andrewhancock91

I didn't have a chance to work with this any more yesterday but I'm going to turn on the "log-queries: yes" option and see what I can find this morning.

NogBadTheBad

BTW if you set the following in Advanced Configuration Pass-Through in the Advanced Configuration Pass-Through section you can get a packet capture of the packets:-

ruletype pcap
{
type alert
output alert_syslog: LOG_AUTH LOG_ALERT 
output log_tcpdump: pcap.cap
}

The following rule would capture ping out:-

pcap icmp $HOME_NET any -> !$HOME_NET any (msg:“ICMP”; sid:20000002; rev:001;classtype:icmp-event;)

Just need to work out the rule to capture DNS requests that match what I think is causing the block.

NogBadTheBad

Bingo

pcap udp any any ->  any 53 ( msg:"ns.hetsptt.net.cn"; flow:to_server; byte_test:1,!&,0xF8,2; \
content: "|02|ns|07|hetsptt|03|net|02|cn|00|"; nocase; sid:20000010; rev:001;classtype:string-detect; )

https://www.securityartwork.es/2013/02/21/snort-byte_test-for-dummies-2/

NogBadTheBad

0_1551086835401_Screenshot 2019-02-25 at 09.26.25.png

2019-02-25 02:35:58 Information pfsense daemon unbound [40595:3] info: 172.16.2.10 1.0.16.172.in-addr.arpa. PTR IN
2019-02-25 02:35:58 Information pfsense daemon unbound [40595:3] info: 2a02:xxxx:xxxx:2::28 tileservices-prod-events-1233069693.us-east-1.elb.amazonaws.com. A IN
2019-02-25 02:35:58 Information pfsense daemon unbound [40595:3] info: 2a02:xxxx:xxxx:2::28 tileservices-prod-events-1233069693.us-east-1.elb.amazonaws.com. AAAA IN
2019-02-25 02:35:32 Information pfsense daemon unbound [40595:3] info: 127.0.0.1 6.27.176.185.in-addr.arpa. PTR IN
2019-02-25 02:35:25 Information pfsense daemon unbound [40595:3] info: 127.0.0.1 39.26.176.185.in-addr.arpa. PTR IN
2019-02-25 02:35:22 Information pfsense daemon unbound [40595:3] info: 127.0.0.1 208.94.64.125.in-addr.arpa. PTR IN
2019-02-25 02:35:16 Information pfsense daemon unbound [40595:3] info: 172.16.2.10 1.0.16.172.in-addr.arpa. PTR IN
2019-02-25 02:35:16 Information pfsense daemon unbound [40595:3] info: 172.16.4.29 api.darksky.net. AAAA IN
2019-02-25 02:35:16 Information pfsense daemon unbound [40595:3] info: 172.16.4.29 api.darksky.net. A IN
2019-02-25 02:35:06 Information pfsense daemon unbound [40595:3] info: 127.0.0.1 212.179.9.60.in-addr.arpa. PTR IN
2019-02-25 02:35:00 Information pfsense daemon unbound [40595:3] info: 172.16.2.10 1.0.16.172.in-addr.arpa. PTR IN
2019-02-25 02:35:00 Information pfsense daemon unbound [40595:3] info: 172.16.2.10 2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.0.0.0.c.e.0.6.0.1.0.8.2.0.a.2.ip6.arpa. PTR IN
2019-02-25 02:34:59 Information pfsense daemon unbound [40595:3] info: 127.0.0.1 212.179.9.60.in-addr.arpa. PTR IN
2019-02-25 02:34:56 Information pfsense daemon unbound [40595:3] info: 127.0.0.1 api.bgpview.io. AAAA IN
2019-02-25 02:34:56 Information pfsense daemon unbound [40595:3] info: 127.0.0.1 api.bgpview.io. A IN
2019-02-25 02:34:56 Information pfsense daemon unbound [40595:3] info: 172.16.2.10 1.0.16.172.in-addr.arpa. PTR IN
2019-02-25 02:34:36 Information pfsense daemon unbound [40595:3] info: 127.0.0.1 225.250.108.202.in-addr.arpa. PTR IN
2019-02-25 02:34:36 Information pfsense daemon unbound [40595:3] info: 172.16.2.10 1.0.16.172.in-addr.arpa. PTR IN

Hmm its something on the firewall is causing the alert, I can trigger the alert by doing a "host 60.9.179.212"

NogBadTheBad

pfBlocker trying to resolve a host that i've blocked

0_1551087452799_Screenshot 2019-02-25 at 09.37.08.png