Workflow: Palo Alto Wildfire positive on incoming SMTP => Check Ironport for delivery status => ? => Profit.
Palo Alto Wildfire positive alert on incoming SMTP.
Message tracking by source server IP (provided within Wildfire positive alert) = delivery status?
If delivered, trigger email alert to user and to admins with Email subject. Possibly move email to different store with EWS.
Thanks guy who wrote that.
Needs some work
After having a conversation with Carter Bullard of argus fame about six months ago, two points stuck with me (loosely quoted):
- “You throttle ICMP?! Why?! ICMP has a lot of useful data for everyone!”
- “Why are you so focused on using argus data for security? Focus on using it to monitor performance. It’ll give you something to deliver to your manager so they don’t think you’re wasting your time and their money. Then focus on security.”
But how? Well, quite easily. At boundaries, use an argus probe to:
- watch for ICMP status that isn’t a successful ECHO-ECHO REPLY:
ra -S 127.0.0.1:561 -s ltime saddr daddr smac dmac spkts dpkts flgs state inode - "icmp and (dst pkts eq 0 or not echo)"
- watch for no “heartbeat” (needs tuning):
rabins -S 127.0.0.1:561 -B 15s -M 5m - src bytes lt 1 or dst bytes lt 1 or src rate lt 1 or dst rate lt 1
- watch for `loss`:
rabins -S 127.0.0.1:561 -B 15s -M 5s - ploss gt 0
- watch for protocol indicated problems:
rabins -S 127.0.0.1:561 -B 15s -M 5s - frag or retrans or outoforder or winshut
- watch for performance degradation below a threshold:
#requires at least argus-clients-184.108.40.206 rabins -S 127.0.0.1:561 -B 15s -M 5s - src jit gt N or dst jit gt N or src intpkt gt N or dst intpkt gt N
If you want to filter in certain addresses to use a pipeline:
ra -S 127.0.0.1:561 -w - - icmp | rafilteraddr -r - -f raaddrfilter.txt -s ltime saddr daddr sbytes dbytes flgs state
Nagios et al are useful to get resource statistics via snmp for sure. It is also better at managing alerts than logstash (specifically schedules!).
nagios output from logstash is already coded.
Icinga et al. should still be used to send pings to devices, but no NOTICEs should be sent on these unreachable events, as the argus probe should be taking care of reachability monitoring.
I believe the bulk of the challenge will take place with processing argus data, but I believe it is quite doable. See: Using elasticsearch for logs (will probably run logstash or logstash-forwarder (aka lumberjack) on the local argus box for caching).
This consolidates performance monitoring into a single dashboard, who’s backend can be utilized for SIEM when the time comes. Producing reports should be very easy, and a ton of work has already been done as related to layman statistics on elasticsearch data, so this is great.
Processing icinga service and host check_results into elasticsearch should be very easy. Look at:
- service_perfdata_file_template (very important for your logstash grok definition)
while true ; do echo $(date '+%H:%M:%S'): $(ps -o rss $(pgrep rasqlinsert) | grep -v RSS) ; sleep 2 ; done > ~/test.log &
use the following to obtain the process ID of the backgrounded job:
To kill the background job:
kill -9 [pid]
Standard Format Specifiers
Netways’ inGraph views are accessible at the path:
I have a lot of trouble dealing with the UI when cloning a graph, and modify a hostname, since this is not how the perfdata is stored to be pivoted in the ingraph DB.
Instead, what I do is make one graph, then edit the json files located within ./views/ adding the additional hosts by copy and pasting the necessary json.
In this example, I am using the event source/input module im_mseventlog. You could use another input module and the process would be relatively the same.
Carter has considered a few methods for dealing with IP location information. If you are looking for simply the country of origin where the IP is allocated, you can use the ARIN database lookup method. If you require more granular information about addresses, including city/region/lat/long info, you must rely on MaxMind’s GeoIP databases (as the ARIN database does not contain this information).
I will cover both of these methods.
I suggest you review Configuring argus clients with .conf and .rarc before continuing…