Last edited:
I previously posted how to extract event information from the TP event database, so I thought I would filter through the data and see how my customised policies were working. It's only been running for a around a month since last clear out. I have noticed that I was getting multiple events for the same source IP at the same time, so there is clearly some overlap.
Within the Misc Attack signature category I have set quite a few of the groups of signatures to Deny: I expect most Internet inbound connectivity from people and devices I know, so there are a lot of suspect source IP addresses I don't need to serve. So these groups were set to Deny:
But then considering which IP addresses got picked up by which signature group.
So the most events are generated by the ET DROP Dshield Block Listed Source 'group', which only has a single signature rule. This is followed by the may signature rules of the ET CINS Active Threat Intelligence Poor Reputation IP group. Then there are enough hits to the ET 3CORESec Poor Reputation IP group. I will keep these customised to Drop.
I'm not decided on whether I need to block TOR Known Exit Node source IPs, so for now I'll keep this large group as Deny. As for the other groups (COMPROMISED and Spamhaus), these generated five unique IPs from 18 events and I've decided to remove the customised rules and have them revert back to Alert. A final check and I saw no events for Threatview.io's Cobalt Strike signatures, so these also revert to default action.
This is for my setup and the SRM firewall will have blocked other connection attempts before hitting Threat Prevention. It confirms my thought that the single DShield signature was doing a disproportionate amount of work. But also showed that other signature groups cover IP addresses not covered by other groups.
Threat Prevention - Extracting events from TP log
I've been looking at how to extract event data from the Threat Prevention log and had drawn a blank... until now. To do this you have to enable SSH on the router and login as root using the user admin's password. I don't advocate anyone messing with this unless they are very confident in what...
www.synoforum.com
Within the Misc Attack signature category I have set quite a few of the groups of signatures to Deny: I expect most Internet inbound connectivity from people and devices I know, so there are a lot of suspect source IP addresses I don't need to serve. So these groups were set to Deny:
- ET DROP Dshield Block Listed Source
- ET DROP Spamhaus DROP Listed Traffic Inbound
- ET CINS Active Threat Intelligence Poor Reputation IP
- ET 3CORESec Poor Reputation IP
- ET COMPROMISED Known Compromised or Hostile Host Traffic
- ET TOR Known Tor Exit Node Traffic (the 'not exit node' signatures seem to mostly get hit too, so only customised 'exit node' ones)
DShield | Spamhaus | CINS | 3CORESec | Compromised | TOR |
---|---|---|---|---|---|
2898 | 3 | 1153 | 1073 | 13 | 299 |
But then considering which IP addresses got picked up by which signature group.
IP address generated events from... | Number of Unique IPs for signature group(s) |
---|---|
DShield only | 392 |
CINS only | 286 |
DShield + 3CORESec | 222 |
TOR only | 220 |
3CORESec only | 110 |
Dshield + CINSS | 57 |
CINS + 3CORESec | 42 |
DShield + CINS + 3CORESec | 6 |
3CORESec + TOR | 4 |
Dshield + COMPROMISED | 3 |
Spamhaus only | 3 |
3CORESec + COMPROMISED | 2 |
COMPROMISED only | 2 |
DShield + TOR | 1 |
So the most events are generated by the ET DROP Dshield Block Listed Source 'group', which only has a single signature rule. This is followed by the may signature rules of the ET CINS Active Threat Intelligence Poor Reputation IP group. Then there are enough hits to the ET 3CORESec Poor Reputation IP group. I will keep these customised to Drop.
I'm not decided on whether I need to block TOR Known Exit Node source IPs, so for now I'll keep this large group as Deny. As for the other groups (COMPROMISED and Spamhaus), these generated five unique IPs from 18 events and I've decided to remove the customised rules and have them revert back to Alert. A final check and I saw no events for Threatview.io's Cobalt Strike signatures, so these also revert to default action.
This is for my setup and the SRM firewall will have blocked other connection attempts before hitting Threat Prevention. It confirms my thought that the single DShield signature was doing a disproportionate amount of work. But also showed that other signature groups cover IP addresses not covered by other groups.