π‘
There is also another option called alert_full which logs everything inside the packet. This option has a large issue though, it is super slow. That means if you have any network with more than 1-2 idle machines you will be in for a rough one, because the conversion is so sloooooooooow. DONT USE THIS IN PRODUCTION!
Great, now our snort install is almost ready to throw alerts. The penultimate step is to restart snort.
```bash
sudo systemctl restart snort
```
...and then...
You should be able to see one or two new files inside `/var/log/snort` called `snort.alert.fast` and maybe even `snort.alert.fast.1` - this is good, it is exactly what we want!
The only thing left is to create a simple test rule. Let's do that next.
### Rules and Tests
We will now create a rule that watches for ICMP (ping) traffic and alerts when it finds any. Disclaimer - Since this is a fairly common interaction inside the network you will see a lot of alerts - do not use this in production unless you know what you are doing π€
Rules are stored under `/etc/snort/rules` - the one we are looking for is called `local.rules`.
We need to add the following line:
```bash
alert icmp any any -> any any (msg:"ICMP connection attempt:"; sid:1000010; rev:1;)
```
![](https://cdn.hashnode.com/res/hashnode/image/upload/v1697458652770/49143a23-191c-41ef-805e-4581df0c57a9.png align="center")
This means back to front - we are in `revision:1` , the unique id of our rule is `1000010` and the message we will put into the log is `ICMP connection attempt:` followed by the actual information from the packet.
Save the changes and then we can test the rule.
#### Testing local rules
Lucky for us snort has an integrated feature that allows us to test newly created/changed rules. We can use:
```bash
snort -q -A console -c /etc/snort/rules/local.rules
```
to test the rule we just created - this will run snort and wait for traffic that matches the rule. If you don't see any after a minute or two you can create it yourself.
```bash
ping -c 20