Stay Ahead With Linux Security Features
threat detection scalability Building a SIEM is easier than scaling one. Most open-source deployments start as a simple "all-in-one" server. It is easy to set up, but that design rarely survives the transition from a lab to a production workload. . A SIEM watching 20 endpoints is not doing the same job as one watching 500. More endpoints mean more logs; more logs require more storage; more storage makes search heavier. Eventually, the very architecture that made your lab easy to deploy becomes the reason your production...
Jun 04, 2026
security advisory apache A newly disclosed attack technique called HTTP/2 Bomb is drawing attention because it targets the software that sits at the front of much of the Linux internet. Apache HTTP Server, NGINX, Envoy, and the ingress layers that many Kubernetes environments depend on can be forced into consuming disproportionate amounts of memory using relatively small amounts of attacker traffic. . For Linux administrators, the concern is not the HTTP/2 protocol itself. It is the possibility that a single...
Jun 04, 2026
security advisory important The compromise of Nx Console shows how much infrastructure now sits behind a single developer account. GitHub repositories, CI/CD pipelines, container build systems, Terraform projects, Kubernetes deployments. None of those systems was the initial target. The workstation was. . Attackers did not need a Linux privilege escalation bug or a remote code execution chain. They needed developers to trust a tool they were already using. For many organizations, that was enough. What Happened? Federal...
Jun 03, 2026
security advisory open-source You remove the malware. You rotate the compromised credentials. You patch the original vulnerability and close the ticket. Two weeks later, the attacker is back. . What happened? You didn't lose the battle at the exploit; you lost it at the cleanup. In many modern Linux intrusions, the malware you found wasn't the main problem—it was the fallback mechanisms left behind. These hooks quietly restore attacker access the moment you look away. If you clean a host but miss these persistence layers,...
Jun 02, 2026
security advisory Red Hat Researchers investigating a campaign now tracked as Miasma found that more than 30 packages in Red Hat's @redhat-cloud-services npm namespace had been altered to deliver credential-stealing malware. . The packages weren't being used to deploy ransomware or sabotage systems. From what has been reported so far, the objective appears to have been much simpler: collect credentials from developer environments and use that access elsewhere. GitHub tokens, cloud credentials, SSH keys, and other...
Jun 02, 2026
Refine features
X Clear Filters
Get the latest News and Insights
Get the latest Linux and open source security news straight to your inbox.
Community Poll
What got you started with Linux?
Loading...
Explore Latest Linux Security features
We found -3 articles for you...
102
network securityincident managementsyslog-ngConfiguring Snort for Real-Time Alerts and Effective Incident Response
Real-time alerting is a feature of an IDS or any other monitoring application that notifies a person of an event in an acceptably short amount of time. The amount of time that is acceptable is different for every person. . Snort is built to perform one task and perform it very well. It does a magnificent job of detecting intrusions. Anything beyond intrusion detection is left up to the IDS analyst to handle. It is expected that you will add the features that make the IDS a truly pragmatic application. You have traveled down this road already, with the creation of an intrusion database to store alerting information and the installation of ACID to manage the collected data. Another powerful feature that should be added to Snort is real-time alerting. Real-time alerting is a feature of an IDS or any other monitoring application that notifies a person of an event in an acceptably short amount of time. The amount of time that is acceptable is different for every person. Factors from the importance of the monitored system to the job duties of the responsible person can influence what is considered "real time". For some IDS analysts, checking ACID a few times each day will suffice. Other IDS analysts require real-time alerting that notifies them of a critical security event within seconds. It is this type of real-time alerting that is covered in this chapter. Even if you do not plan to make use of real-time alerting at this point, you may want to deploy the capability for real-time alerting. If a critical situation presents itself, it is beneficial to be able to notify the right person. Although you may not want to be notified for each critical alert, there will likely be a point where a unique circumstance presents itself. When a vulnerability is released and an exploit is in use in the wild before a vendor has released a patch, you would probably want to be notified of suspicious activity on hosts that are known to be affected. Real-time alerting can be useful in incident response because you would want to benotified of possible new security breaches during the course of an incident. Installing the capability for real-time alerting assures you that you can deploy real-time alerting quickly in an emergency situation. An Overview of Real-Time Alerting with Snort Real-time alerting with Snort is highly customizable. You can pick and choose which alerts to be notified of in real time. Assigning a priority to each rule or classification of rule enables you to do this. Each rule can have an individual priority attached to it, and every rule can be included in a classification of rules that has a priority attached to it. Rules can be prioritized so that one priority of rule can be sent to one person while a different priority is sent to another. You can set up a thirdparty Snort application to notify yourself of malicious remote buffer overflow activity, while alerting an entirely different person to inappropriate Internet activity. With the customizable prioritization of alerts, you can notify yourself of different rules in different manners. One priority of rules can be sent to an email address that notifies you via pager while another can simply send you an email. The most popular method of deploying real-time alerting capability on a Snort IDS is with swatch (Simple Watcher)or syslog-ng (syslog-next generation). Swatch and syslog ng monitor Snort syslog output for a predetermined string. When they find the string, they execute a command. The command can be any available command on the system. Typically, a command is executed that sends an email. Other popular options include pager applications and audible alerts. Using swatch and syslog for real-time alerting is an ideal solution for a hybrid server/sensor installation. The syslog daemon is probably installed by default on the hybrid, meaning you merely have to set up swatch, configure Snort or Barnyard to log to syslog, and install an application for mailing alerts. syslog-ng is the better choice for the distributed threetier Snort setup. If you haveSnort installed in a distributed threetier setup, you will want to collect syslog alerts in a central location. Logically, the Snort server is the ideal location for collecting alerts from the sensors. The server then monitors for critical alerts and emails them to the appropriate person. Installing a mailing application and swatch on each sensor creates a lot of unnecessary work, so syslog-ng is used to collect alerts. The syslog-ng client accepts alerting data from Snort and passes it to a centralized syslog-ng logging server. Stunnel is used to encrypt the clienttoserver syslog-ng sessions. From the logging server, syslog ng calls a simple shell script that passes alerts on to the mailing application. Prioritization of Alerts Before getting into the details of deploying real-time alerting capability for Snort, you must decide which alerts are critical enough for you to be notified of. Snort is versatile in the prioritization of alerts;you can select individual rule categories for which you want to be notified. You can also select individual rules to be notified of as well. A prior ity specified in a rule overrides any specified in the rule's category. The alerting application, be it syslog-ng or swatch, monitors the log for a specific string. When this string is found, it executes the mailing application and sends an email with data from the actual alert. The string for which you should set these applications to search is the priority level of the alert. You can configure what action to take based on the priority of alert. For example, alerts with a priority of 1 could execute a paging program. Alerts with a priority of 2 could be sent to an email account that is checked frequently. A subsequent priority level of 3 could be sent to a network abuse admin. The exact rule classifications and rules to be alerted of in real time are different for each Snort installation. You, the IDS Analyst, should make the decision concerning what is important enough to be notified of in real time. That being said,there are some general guidelines that you can use to determine what type of alerts you should be notified of in real time. Incidents Alerts deserving of a high priority and real-time alerting are usually those that are likely to indicate a security incident. If a rule triggers on remote control Trojan traffic, it is likely that a host has been compromised and requires immediate attention. Attack response traffic, such as pages or commands that are commonly called when a black hat successfully tests for an exposure, is a prime candidate for real-time alert. Any type of rule that is likely to result in a compromised host, such as an attack that is perpetrated against a known unpatched host, should generate immediate notification. Targeted Attacks Other possible categories of alerts to be notified of in real time are those that signify an attack is underway that could compromise a host. If a hacker is attempting specific attacks against certain versions of software residing on hosts that exist at your organization, you may want to include these rules in a real-time alerting strategy. This follows the logic that an attacker may have developed some prior knowledge of your network to determine the correct hosts to attack. Although the hacker could simply be guessing, it is likely that the hacker is determined to penetrate your network and is worthy of action. These attacks have a greater chance of success. In these cases you should identify rules that match existing hosts, services, and software versions and assign them a high priority. Custom Rules Other custom rules you have developed for your local environment, such as suspicious TFTP sessions from an external host, should be configured for real-time alerting. Custom rules are often created to bring greater monitoring coverage to a particular host, which implies that alerts generated are of a high priority. Custom rules created for these situations are ideal for real-time alerting. After you have decided on what rules to alert, you needto make a decision on who to alert and which types of alerts the appropriate persons should receive. If you are going to notify a single person or group of persons to security events, set all the rules and rule categories that require real-time alerting to the same priority level. If you have more than one group or person to notify, you should assign a priority level to each person or group. Alerting a Group When a group of people is on the distribution list for Snort alerts, you must be careful to spell out responsibilities ahead of time. A clear alerting strategy can prevent numerous problems when alerting to a group. All too often a group of people receives an alert, and then one person acts on it without notifying others. The first analyst to act on the alert could take corrective action that would confuse and frustrate the other analysts. I have been witness to an analyst on the third shift who deleted alerts before others could react, totally confusing the rest of the IDS team. The IDS team suspected for a time that a Snort server had been compromised. Another, far worse, scenario is that members of a group receiving real-time alerts will assume that another member has already taken action and will ignore a critical alert. It is important to establish these job responsibilities ahead of time to avoid this type of confusion. If you are planning on installing more than one real-time alerting method, such as via email and pager, you need to further divvy up the rules between the different alerting methods. After you have this squared away, you can move on to implementing your alerting strategy in Snort. Prioritizing with classification.config You can edit the priority levels for rule categories in the classification. config file. Open the file, located at /etc/snort/conf/, and examine the different categories of rules. In the following examples, real-time notification is set for any rule with a priority level of 1. Change any of the classifications that you want to be notified of inthis file to a priority of 1. For example, if you want to be notified of all successful DoS attacks, change the following line: config classification: successfuldos, Denial of Service, 2 To: config classification: successfuldos, Denial of Service, 1 If the classifications are not granular enough, you can create your own. Simply create the rule classification in classification. config and assign it a priority like so: config classification: attackresponse, Successful Attack Response, 1 Note Notice the classification keyword contains no spaces, and there are no spaces between the delimiting commas. Next you need to insert the new classification keyword into the rules that correspond to your new category. In this example the classtype option is changed in the following two rules: alert tcp $HTTP_SERVERS $HTTP_PORTS > $EXTERNAL_NET any (msg:"ATTACK RESPONSES http dir listing ";content:"Volume Serial Number "; flow:from_server, established;classtype:attackresponse;) alert tcp $HTTP_SERVERS $HTTP_PORTS > $EXTERNAL_NET any (msg:"ATTACK RESPONSES command completed ";content:"Command completed "; nocase;flow:from_server, established;classtype:attackresponse;) You would now be alerted to these types of successful attack responses in real time. The priority Option You can also change the classification for individual rules. Assigning a priority option to the rule changes the priority for the specified rule. If you assign a priority to a rule and the rule has a classtype option with a different priority assigned to it, the priority option takes precedence. If you wanted to assign a different priority for the previous HTTP directory listing rule, you could make the following change: alert tcp $HTTP_SERVERS $HTTP_PORTS > $EXTERNAL_NET any (msg:"ATTACK RESPONSES command completed ";content:"Command completed "; nocase;flow:from_server, established;classtype:attackresponse;priority:2 ) This would set the priority level to 2. Using the priority option method is useful inidentifying rules that are critically important to your environment. Alerting with the Hybrid Deploying real-time alerting with the hybrid server/sensor is relatively easy. You need to install a mailing application, such as sendmail, to use real-time alerting via email. If you want to install another application, such as a pager or SMS gateway, you should do so. There are numerous resources online and in print for installing and configuring send mail. The documentation included with the source distribution is fairly detailed and should get you up and running. You can get the sendmail application and associated documentation at: https://www.proofpoint.com/us/products/email-protection/open-source-email-solution After you have deployed sendmail, you should take care to secure it. Sendmail has a relatively miserable history of security exposures and should be properly hardened. After sendmail is secure, you need to configure Snort to send alerts to syslog. Sending alerts to syslog is accomplished via the output plugin, alert_syslog. Open up snort.conf or barnyard.conf and enable the alert_syslog output plugin by uncomenting the configuration line. If you have Barnyard installed, you should make the changes to Barnyard rather than Snort. Your configuration line should read as follows: output alert_syslog: LOG_AUTH LOG_ALERT Now you should generate some suspicious traffic either manually or with NMAP. Check to make sure Snort is logging to syslog by opening the following file: /var/log/snort/alert You should see a list of alerts with a priority assigned to each one.You should see alerts similar to the following: [1:1704:1 ] WEBCGI cal_make.pl directory traversal attempt [Classification: Web Application Attack ] [Priority:1 ] 09/1610:04:15.816116 192.168.1.1:3140 > 192.168.1.2:80 TCP TTL:128 TOS:0x0 ID:12817 IpLen:20 DgmLen:131 DF ***AP***Seq:0xDEFC8E6D Ack:0x1A519F30 Win:0x4470 TcpLen:20 [Xref => ] [Xref => ] [1:1122:2 ] WEBMISC /etc/passwd [Classification: Attempted InformationLeak ] [Priority:2 ] 09/1610:04:15.826116 192.168.1.1:3143 > 192.168.1.2:80 TCP TTL:128 TOS:0x0 ID:12832 IpLen:20 DgmLen:149 DF ***AP***Seq:0xDEFF5454 Ack:0x1A51AF74 Win:0x4470 TcpLen:20 [1:1730:1 ] WEBCGI ustorekeeper.pl directory traversal [Classification: Web Application Attack ] [Priority:1 ] 09/1610:04:15.836116 192.168 1.1:3144 > 192.168.1.2:80 TCP TTL:128 TOS:0x0 ID:12837 IpLen:20 DgmLen:141 DF ***AP***Seq:0xDEFFEE00 Ack:0x1AB7B107 Win:0x4470 TcpLen:20 [1:1721:1 ] WEBCGI adcycle access [Classification:sid ] [Priority:2 ] 09/1610:04:15.846116 192.168.1.1:3148 > 192.168 1.2:80 TCP TTL:128 TOS:0x0 ID:12857 IpLen:20 DgmLen:76 DF ***AP***Seq:0xDF035110 Ack:0x1A9AEFA4 Win:0x4470 TcpLen:20 Installing Swatch Now that you are logging alerts, you need to install swatch to monitor syslog. Swatch requires four Perl modules in order to function. They are: Date::Calc Date::Parse File::Tail Time::HiRes Most Linux distributions include these modules. In case your flavor does not, you can get these modules from https://metacpan.org/ To install them, run through the following list of commands to compile and install the modules: perl Makefile.PL make make test make install make realclean After you have the modules installed, you can download swatch. It is located at: You can install swatch by using the same commands you used to install the Perl modules. Configuring Swatch Swatch is controlled from commandline arguments and configuration files, much like Snort and Barnyard. The configuration file for swatch is named .swatchrc. In the .swatchrc file you specify a string for swatch to monitor the log for and the action to take. Some of the commands you could use to build real-time alerting include the following: .watchfor This is the required command that tells swatch what string to monitor for in the log. You can specify any string. For the purposes of this book we will search only for strings that match a certain priority number. The following example is a watchfor command tomonitor for alerts with a priority of 1. watchfor /Priority \:1/ You can find a tutorial on building regular expressions that are used in pattern matching at . echo The echo command echoes the matched line. This can be used to append alerting information into the body of the email, or to a text field in a pager . exec This command is used to execute an external program. If you have a paging program or any other script you want to execute, use the exec followed by the full path to the program. You can add a $N or $0 to the exec command, which appends N lines or the entire alert to the executed command. mail The mail option sends an email either to the local system or to a specified email address. You can store a group of email addresses in the alias file located at /etc/aliases , and use the alias to represent the group of email addresses. throttle This command limits the number of alerts to be acted on. When the throttle is set, alerts that match the string are not acted on in the specified time. You can use this to avoid stressing your mail server and overloading your account. You can use other commands for more advanced features of swatch, but the preceding are all you will need to send alerts via email or pager. With these commands you can install real-time alerting in many different manners. Open up the .swatchrc file for editing and add the following commands: watchfor /Priority \:1/ echo=normal mail=user \@domain.com, subject=Snort Security Alert! Note You must escape the @symbol with a backslash. This configuration watches for any alert with a priority of 1 and emails user@domain.com with the alert. If you wanted to call a paging program you could replace the mail command with an exec command. QuickPage is a paging gateway that can be integrated with sendmail. You can get QuickPage at: http://www.qpage.org To send emails via QuickPage to a text pager, you could add these commands: watchfor /Priority \:1/ echo=normal exec /usr/local/bin/qpage fsnort@domain.com p IDS_admin '$0' throttle 00:00:10 This command calls the QuickPage program and sends a page to IDS_admin, from the email address snort@domain.com . It makes use of the $0 to send the entire alert to the qpage command. With the throttle command, swatch ignores any alert of priority level 1 for 10 seconds after the page has been sent. You could also use swatch to ring the local PC bell with this command: watchfor /Priority \:2/ bell 5 This command rings the PC bell five times for each alert with a priority of 2. Note This is sure to ruin any rapport you have developed with your coworkers. You are not limited to one command set; you could implement all three if you wanted to. After you have the .swatchrc file configured to alert you in a manner you see fit, you can move on to running swatch. Swatch has a few commandline options you should be made aware of. -c This option specifies the location of the .swatchrc file. --input-record-separator With this commandline option you can specify the delimiting boundary for each alert. By default it is the newline character, \n. -p The p is used to read information outputted directly from a command. You can use this to monitor the output of a command for specific events. -t This option specifies the file to be monitored for security events. --daemon Append this switch to enable daemon mode. A sample swatch startup command follows: ./swatch c /usr/local/.swatchrc /var/log/snort/alert daemon This command runs swatch in daemon mode using the configuration file located at /usr/local/.swatchrc . It will monitor the syslog file at /var/log/. If you run this command, you will notice that swatch sends only the first line of the alert, as follows: [1:1704:1 ] WEBCGI cal_make.pl directory traversal attempt It does so because the default input record separator is used, \n. If you would like to see additional meta information, such as IP addresses, time, TCP flags, and so on, you need to append additional lines ofthe alert. To send the entire alert, make use of the tail command and swatch 's piping feature: ./swatch c /usr/local/.swatchrc inputrecordseparator="\n \n" p="tail f /var/log/snort/alert" daemon The p switch watches the alert file with the tail command for new data. It uses a double carriage return, \n \n , for record separation. You should now receive the entire alert: [1:1704:1 ] WEBCGI cal_make.pl directory traversal attempt [Classification:Web Application Attack ] [Priority:1 ] 09/1610:04:15.816116 192.168.1.1:3140 > 192.168.1.2:80 TCP TTL:128 TOS:0x0 ID:12817 IpLen:20 DgmLen:131 DF ***AP***Seq:0xDEFC8E6D Ack:0x1A519F30 Win:0x4470 TcpLen:20 [Xref => ] [Xref => ] This completes the swatch installation and real-time monitoring for hybrid server/sensors. Alerting with Distributed Snort To deploy real-time monitoring capability in a threetier Snort setup you use a different method than with the hybrid. It would be a waste of time and resources to install a mail ing application (such as sendmail)and swatch on each sensor. But making a single change to swatch and sendmail configurations across multiple sensors is bound to create confusion and possibly mistakes. To solve this problem, you can make use of syslog-ng and Stunnel to forward alerts securely from the sensors to the Snort server. You could optionally install another server to handle the alert collection and mailing functionality, in which case you would forward alerts to this new server. syslog-ng is a replacement for the syslog logging facility used by many different applications on Unix systems. Error messages and security alerts from applications or the operating system are posted to syslog. The original syslog has only 20 possible event types, which are known as facilities. Each facility has a priority assigned to it. The facilities are generic and are used by many different applications, so you will have many different applications reporting events to syslog with the same facility. With many applications reported asthe same facility, it becomes difficult to search for events generated by a specific application. Filtering is difficult when you have a large amount of data stored in a syslog file. syslog-ng solves this problem by making the filtering process much more granular. With syslog-ng, you can filter events based on the content of the event as well as the facility and priority. You can make use of regular expressions to filter events, which is not possible with the original syslog. syslog-ng supports some additional features that make it ideal for the Snort environment. The source of alerts from the original syslog can be obscured if the alerts are for warded over more than one host or forwarded with Stunnel. If you collect alerts from many different machines on one host, syslog reports the correct logging host. But if you forward these syslog alerts again to a master host, the alerts appear to come from the second host. In a large Snort environment, where multiple logging servers are used, this can make determining the source of the alert difficult. syslog-ng solves this problem by storing the complete hostname, along with time the alert was generated on the local host. The original syslog sends alerts via UDP. This is problematic, because Stunnel does not currently support the encryption of UDP traffic. You could install a UDP tunneling package specifically for syslog sessions, such as Zebedee, to fix this problem. It is easier to upgrade to syslog-ng, which uses TCP, and make use of the Stunnel package you have already installed. syslog-ng also has native support for emailing alerts. You can add lines in the configuration file to automatically mail alerts that match a particular string. This eliminates the need to install swatch. Configuring Snort and Installing Sendmail You need to install a mailing application, such as sendmail, to use real-time alerting via email. If you want to install another application, such as a pager or SMS gateway, you should do so. There are numerous resources online and inprint for installing and configuring sendmail. The documentation included with the source distribution is fairly detailed and should get you up and running. You can get the sendmail application and associated documentation at https://www.proofpoint.com/us/products/email-protection/open-source-email-solution After you have deployed sendmail, you should take care to secure it. Sendmail has a relatively miserable history of security exposures and should be properly hardened. After sendmail is secure, you need to configure Snort to send alerts to syslog. Sending alerts to syslog is accomplished via the output plugin, alert_syslog. Open up snort.conf and enable the alert_syslog output plugin by uncommenting the configuration line. Your configuration line should read: output alert_syslog: LOG_AUTH LOG_ALERT The stage is now set for the installation of syslog-ng. Installing syslog-ng on a Sensor The first step to deploying syslog-ng is to install and configure the package on the sensors. syslog-ng is dependent on the libol package. You must install it before attempting to install syslog-ng. Download the latest version of libol at: https://www.oneidentity.com Run the familiar configure , make , and make install commands to install the libol package. After you have this completed, download syslog-ng from https://www.oneidentity.com You can run through the usual configure, make, and make install commands to install the package. Configuring syslog-ng for the Sensor syslog-ng is controlled via a configuration file, syslog-ng.conf . You will be writing this file from scratch. The examples in this book use the ports typically used by rservices (512, 513, 514) for syslog-ng. You should not be using any of the rservices on the Snort tiers because they are insecure. If you want to use ports other than those specified in the examples, you are free to do so. To begin to configure syslog-ng for the sensor you must create a configuration file. Create a syslog-ng configuration file located at /etc/syslog-ng/syslog-ng.conf Note You want to create a new file, not use one of the default or sample syslog-ng.conf files included with the package. The purpose of the syslog-ng.conf file is to let syslog-ng know where to look for syslog information and what to do with it after it is discovered. You do so by adding sources and destinations and then associating a source with a destination. The sources are potential locations from which syslog-ng can receive alerts, and destinations are areas to which they should be output. Associating a source with a destination tells syslog-ng exactly where to look for alerts and where to send them. The two actions are not mutually exclusive;after you define a source you can associate it with as many destinations as your heart desires. The same holds true for sources. The first line you need to build is a source line. It is used to identify the source of the syslog-ng alerts to the syslog-ng application. You need to name the source with an identifier as well. A good guideline for naming is to use the name of the sensor, then an underscore, and finally the integer the sensor uses in ACID. Note This is only to help you remember what you have done at a later date; it is not required that you follow this guideline. The following format provides an example: source identifier {sourcedriver(parameter);}; The sourcedriver is where you want syslog-ng to look for alerts. The source driver can be the local machine, a TCP port, or even a file. You can specify as many sourcedrivers as you wish. For the sensor installation of syslog-ng, you should accept alerts from the local system. Use the following configuration line to accept alerts from the local system: source sensor_7 {unixstream("/dev/log ");internal();}; The name of the sensor is sensor, which corresponds with the integer of 7 in ACID, so the identifier is sensor_7. The unixstream("/dev/log ")sourcedriver unixdgram("/dev/log") . The internal command tells syslog-ng to also listen for messagesgenerated internally in syslog-ng. The next line to create is the destination to which the alerts are to be sent. On the sensor, all alerts should be forwarded directly to the Snort server. This is specified with a destination line, which has the following format: destination identifier {destinationdriver(parameter);}; The identifier is the name of the Snort server. The destination is the IP address and port that corresponds to the syslog-ng service that will be installed on the server. You should insert a line similar to the following: destination snort_server { tcp("Snort_Server_IP " port (514)); }; This line sends alerts to a syslog-ng daemon listening on port 514/TCP located at Snort_Server_IP . The final configuration line you need to add, log, lets syslog-ng know which sources you want to correspond to which destinations. In this case there is only have one source and one destination, so only a single configuration line is needed. The log configuration line has the following format: log {source(source_name); filter(filter_name); destination(destination_name) }; Because we are not using any filters at this point, we can ignore the filter options. We will need to filter syslog alerts later on to support real-time alerting. To construct the log line you simply utilize the source and destination lines you created previously: log {source(sensor_7); destination(snort_server); }; This completes the configuration of syslog-ng on the sensor. We will have to revisit this file later to enable Stunnel. To start syslog-ng, run the following command: /usr/local/sbin/syslog-ng Installing syslog-ng on the Server You can follow the same process for installing syslog-ng on the server as you did for the sensors. Download and install libol, then install syslog-ng. Configuring syslog-ng for the Server Configuring syslog-ng for the Snort server is relatively painless now that you understand how to configure a syslog-ng.conf file. Create a syslog-ng configuration filelocated at /etc/syslog-ng/syslog-ng.conf Open this file for editing. The first step is to create a source line that listens to both a TCP port and the local syslog-ng application. We want to see alerts that are incoming from the sensors, as well as any related to the syslog-ng application itself. Use the follow ing source line: source sensors {unixstream("/dev/log "); internal(); tcp(ip(Snort_Server_IP ) port(514) maxconnections(7) }; This command listens for alerts generated locally by syslog-ng. It also listens for alerts via TCP to port 514 to the interface with the IP address of Snort_Server_IP assigned to it. You should change this IP address to match the IP of the management NIC you use to control the sensors. The maxconnections()option sets the maximum number of sensors that can connect to the syslog-ng server. The next line to create is the destination configuration line. You should send alerts to a logfile local to the server. Do so with this line: destination localhost { file("/var/log/snort.log ")); }; This writes all the logs from the sensors to the log file located where specified. To complete the posting of alerts to a local file, add a log statement to associate the source and destination: log {source(sensors); destination(localhost); }; You should now test Snort by sending traffic to generate alerts and by checking the /var/log/snort.log file. If everything is working correctly, you can move on to configuring real-time alerting with syslog-ng. Configuring syslog-ng for real-time Alerting Configuring the syslog-ng to send alerts via email or pager involves creating a simple shell script that is executed by syslog-ng when a string is matched. The shell script in turn executes the mailing or paging application. Some additional configuration lines are required as well. The first thing is to add the configuration lines, and then create the shell script. Open the syslog-ng.conf file for editing. You will use the source line that is used to log to the localsnort.log file, so you need not create a new source line. The destination for the alerts is the shell script you have yet to create. Use this destination line to execute the script: destination email_alert_script {program ("/usr/local/bin/alert_mail.sh "); }; The program option specifies the command to be executed that will receive the alerts. Be sure to include the full path. Next, you need to create a filter that matches only your highpriority Snort alerts. If you want to match all Snort alerts with a priority of 1, you create this filter line: filter high_priority {match ("\\[Priority:1 \\]"); }; Notice that you must escape the bracket symbols with a double backslash, \\ . Create filters for each of the priorities on which you want to alert. Now you must add the final log statement to tie the source, destination, and filter lines together. log {source(sensors); filter(high_priority); destination(email_alert_script); }; This completes the setup of the syslog-ng.conf file. Exit and restart syslog-ng. The final piece of the puzzle is to write the simple shell script that syslog-ng is to execute. Open /usr/local/bin/alert_mail.sh for editing. Enter the following script: #!/bin/sh while read line; do echo $line |mail s "High Priority Snort Alert"
Jan 28, 2022
•
102
data analysissecurity toolscyber defenseHarnessing Threat Intelligence For Optimal Cyber Defense Strategies
Thank you to Oyelakin Timilehin Valentina and Duane Dunston for contributing this article. Threat intelligence (or threat intell) is information used to understand past, present, and future threats targeting an organization. It is evidence-based knowledge about a previous, existing or emerging threat to organizational assets. Threat intelligence also includes settings, implications, mechanisms, context, and even action-oriented advice on the threat. Context mentioned here includes who the attackers are, what their motivation is, what their capabilities are, and what indicators of compromise are in your system. An Indicator of compromise (IOC) is forensic data in a system log file, for example, which identifies malicious activities on a system or network. . Also, threat intelligence can be defined as data analysis using tools and techniques to get information about an existing or emerging threat targeting the organization. Notice that the definitions mentioned above include using knowledge (obtained from data) to achieve a common goal of mitigating cyber threats or cyberattacks. In this series, we will define threat intelligence as collecting, processing, and analyzing data that gives us meaningful knowledge to understand the pattern of previous or present attacks and leads to the building of a stronger and better cyber defense to help mitigate or prevent future attack. Importance of Threat Intelligence Threat intelligence provides deep knowledge on the potential threats to an organization. It helps to know all that is happening outside of the network, because it helps to recognize threats and exploits that the organization is vulnerable to using data from various tools and threat event sources to build a risk management plan to prevent future threats. Cyberattacks and data breaches lead to loss of data, but it also leads to costs like damage to the organization's reputation, market position, fines, lawsuits, expenses that come from investigation, and post-incident restoration andremediation. Practical threat intelligence that comes with effective defense strategies can also save an organization by cutting down or avoiding the cost of data breaches. With vulnerabilities being actively exploited, practical threat intelligence can quickly identify and mitigate their impact and increase the security team's efficiency in handling security alerts. Also, threat intelligence helps gather IOCs like signatures of tools used by the attackers, malware characteristics, and behavior. In this series, we will explore some tools that can be used for creating a threat intelligence program for an organization. The tools will be explained along with examples of how to run it and interpreting its output. While it cannot cover all possible implications to an organization, it can help provide a starting point for interpreting the output in context to your organization. We will begin with discussing how nmap can be used as one source to gather information to add to a threat intelligence program. Stay tuned! About the Authors Oyelakin Timilehin Valentina is a self-taught cybersecurity professional. As someone who loves to contribute to social responsibility, she volunteers for Cybersafe Foundation with its initiative #NoGoFallMaga. She is also a volunteer for The Young Ciso Network and The Diana Initiative. Duane Dunston is an Associate Professor of Information Security at Champlain College. He has been in information security since 1997, starting in the education sector, then to federal, and then into academia. . Profound understanding of threat intelligence and its importance in counteracting cyber risks for enhanced organizational safeguarding.. Threat Intelligence, Cyber Defense, Risk Management, Security Strategies. . Duane Dunston
Jun 03, 2021
•
Get the latest News and Insights
Get the latest Linux and open source security news straight to your inbox.
Community Poll
What got you started with Linux?
Search Topics
Powered By
Linux Security - Your source for Top Linux News, Advisories, HOWTOs and Feature Releases
QUICK LINKS
subscribe to newsletters!
Like staying secure? So do we.
Sign up for updates, tips, and alerts!
Discover faster search, smarter navigation, and deeper Linux security insights. Read More