Problem scenario
You have a Linux server, and you want to install Snort use its basic functionality. How do you do this?
Background
It is advisable to place Snort on every machine (Upguard). This way if one server is compromised, you have Snort's features on all other servers. When alerting but not logging, running Snort usually consumes a negligible amount of resources (RAM, CPU, I/O activity to the hard disk).
Solution
1. If the Linux server is Ubuntu or a Debian distribution, run these two commands:
sudo apt-get -y update
sudo apt -y install snort
If the Linux server is RedHat or a RedHat derivative (such as CentOS or Fedora), see this posting for installing Snort.
2. Identify the internal IP address of the server (e.g., "ip addr show | grep eth0"). As an example for these procedures, let's assume the internal IP address that was returned from the suggested "ip addr show | grep eth0" was 11.22.33.44
3. Back up the Snort configuration file with this command: cp /etc/snort/snort.conf /etc/snort/snort.conf.bak
4. Then modify the original snort.conf file (vi /etc/snort/snort.conf) to change a single line. The "ipvar HOME_NET" stanza should look like this:
ipvar HOME_NET 11.22.33.0/24
# Where 11.22.33 are the first three octets of the internal IP address of the server.
5. Modify the local.rules file (to add one line) by running this command: sudo vi /etc/snort/rules/local.rules
# Add this single line below:
alert icmp any any -> $HOME_NET any (msg:"ICMP test"; sid:1000001; rev:1; classtype:icmp-event;)
6. Have the rule take effect by running this command: sudo snort -T -i eth0 -c /etc/snort/snort.conf
7. Make sure that you see "Snort successfully validated the configuration!" Start Snort's alerting process by running this command: sudo snort -A console -q -c /etc/snort/snort.conf -i eth0
8. Test it by pinging the external IP address of the server. Pinging the loopback address or the internal IP address will NOT generate activity for Snort to capture, monitor, or log. It does not matter from which server you start the pings (e.g., the Snort server itself is fine via a duplicate session), as long as the destination IP address of the pings is the external IP address.*
9. Optional step. For Snort to log to a persistent file, not echoing to the screen (or "walling" to the screen) certain TCP/IP activity, use a rule like this in the local.rules file:
log tcp any any -> $HOME_NET 277:277 (msg:"Special activity"; sid:1000002; rev:1; classtype:attempted-recon;)
# Each sid must be unique. To monitor a range of ports instead of just "277" change the "277" on the left of the pair divided by a colon (277:277) in the above stanza to the lowest port number in the range. Change the "277" on the right of the 277:277 to the highest port number in the range you want to monitor.
The above stanza (that starts with "log") will record activity over port 277 to a binary file (not a regular text file) in /var/log/snort/ (but the location may differ if you changed the default directory of where Snort logs). To view the log, find the name then run a command like this: sudo snort -r nameOflog
The output may be considerable. You may want to redirect the output to another file.
10. You are finished.
* For testing Snort make sure there is no firewall rule protecting the server so that even pings to the external IP address will not work. If the Linux server is in AWS, find the external IP address for the server. Make sure that the Security Group governing this server allows inbound traffic from the external IP address of the server. You may block inbound traffic from the server's external IP address if you do not need to test Snort from the server itself. If the Linux server is in Azure, ensure that the Network Security Group allows connectivity from the IP address.