I'm new to the community and hope to learn a lot from the users here
At the moment, some of our sensors (not all are confirmed to do this yet) are trying to reach 220.127.116.11 and 18.104.22.168 over port 443. Because there's no rule for this in our firewalls, it's being blocked. I see that tunnel.web.trustesource.org resolves to 22.214.171.124, but I'm not sure of the 8.18 address. We run a 7.1 NSM/Sensor software.
Any ideas why our sensors are trying to get out?
I've not seen the 126.96.36.199 address before and I haven't been able to identify any of our known address names that resolve to that.
Are you sure it's coming from a sensor?
We do use akamai to host some services, but that one does not appear to be one. The address does have a McAfee whois result and some data suggests it's in the same location as my office. I checked with the local network guy and he confirmed it's actually in our Miami colocation site, but we're not clear what it is.
A packet capture at a gateway device may give some answers.
188.8.131.52 over port 443
Above is McAfeetrustedsource or GTI server ip. Your GTI is enabled that is why sensor is trying to contect GTi servers to submit suspious packets.
Will you bypass sensor with this command and see
layer2 mode assert
then use inlinepktdropstats to dig into interface counter.
Figured it was a GTI box.
Sorry, was responding to gfergus first. Layer 2 means we would lose our inspection abilities; need to discuss internally. Also, what would the inlinepktdropstats show in regards to GTI?
Also, any response to my post above? Since we have proxies/dns configured to point internally, why are the sensors still going directly out?
Most definitely sure it's a sensor going directly to these IP's.
I believe it to be GTI related, but was under the impression that GTI traffic would go from the sensor, to the NSM. We also have the sensors configured to proxy through our proxies, and use out internal DNS servers. Which doesn't make sense why it would send something directly out to the internet. Can you compare the 8.18 address against all GTI IP's? Any word from the MIA office?
Would love to pcap it for troubleshooting, but the firewall that's blocking it is RIGHT next to it (next hop actually). lol. and pcap's on that firewall are slim to none (locks up most the time )
The sensors do a portion of the query as they need the GTI info if they are configured to augement smartblocking with GTI.
The sensor should be using a dns query, which would go to your configured DNS server and use the dns infrastructure to get out.
The manager then does a lookup to get the data for display in the threat analyzer and other dashboards.
I've checked all the names for GTI and didn't locate that address.
To help yopu out there I 'd need info collector file and I think your sensor deployment is "In line mode"., right?
Please do the following to take info collector file.
To run InfoCollector, take the following steps:
1. Navigate to the InfoCollector subfolder in the NSP installation directory: [Network Security Manager_INSTALL_DIR]\App\diag\InfoCollector
2. Run the InfoCollector batch file: [Network Security Manager_INSTALL_DIR]\App\diag\InfoCollector\InfoCollector.bat
InfoCollector can collect information from the following sources within the NSP system:
•Log Files–Configurable logs containing information from various components of the Manager.
•Configuration backup–A collection of database information containing all Network Security Platform configuration information.
•Audit Log Backup-A file containing various information in relation to user activity.
•Configuration files–XML and property files within the Network Security Platform config directory.
•Faultlogs–A table in the Network Security Platform database that contains generated fault log messages.
•Sensor Trace–A file containing various McAfee® Network Security Sensor (Sensor)-related log files.
•Compiled Signature–A file containing signature information and policy configuration for a given Sensor
gfergus / alexn,
I will break this off and open a case with Support at this point. Hopefully I return with a full solution. Case 3-3105988403 has been opened.
Thank you for the information!
tjaynesMessage was edited by: tjaynes on 5/28/13 5:11:38 PM CDT
I've been able to confirm that both addresses you have listed are tied to tunnel.web.trustedsource.org.
It appears we have changed GTI to include SSL connections from the sensors.
Some addresses I've seen:
These addresses may change over time and there may be additional addresses in your region as the GTI infrastructure is very regionalized so it is recommended to build policy around the DNS name if possible.