How To Build A SIEM with Suricata and Elastic Stack on Ubuntu 20.04

ref:https://www.digitalocean.com/community/tutorials/how-to-build-a-siem-with-suricata-and-elastic-stack-on-ubuntu-20-04

Introduction
The previous tutorials in this series guided you through installing, configuring, and running Suricata as an Intrusion Detection (IDS) and Intrusion Prevention (IPS) system. You also learned about Suricata rules and how to create your own.

In this tutorial you will explore how to integrate Suricata with Elasticsearch, Kibana, and Filebeat to begin creating your own Security Information and Event Management (SIEM) tool using the Elastic stack and Ubuntu 20.04. SIEM tools are used to collect, aggregate, store, and analyze event data to search for security threats and suspicious activity on your networks and servers.

The components that you will use to build your own SIEM tool are:

Elasticsearch to store, index, correlate, and search the security events that come from your Suricata server.
Kibana to display and navigate around the security event logs that are stored in Elasticsearch.
Filebeat to parse Suricata’s eve.json log file and send each event to Elasticsearch for processing.
Suricata to scan your network traffic for suspicious events, and either log or drop invalid packets.
First you’ll install and configure Elasticsearch and Kibana with some specific authentication settings. Then you’ll add Filebeat to your Suricata system to send its eve.json logs to Elasticsearch.

Finally, you’ll learn how to connect to Kibana using SSH and your web browser, and then load and interact with Kibana dashboards that show Suricata’s events and alerts.

Prerequisites
If you have been following this tutorial series then you should already have Suricata running on an Ubuntu 20.04 server. This server will be referred to as your Suricata server.

If you still need to install Suricata then you can follow this tutorial that explains How To Install Suricata on Ubuntu 20.04.
You will also need some Suricata signatures loaded and configured to generate alerts, or to drop traffic. Follow the Understanding Suricata Signatures tutorial in this series for a guide on how to create your own signatures. Or you can download a comprehensive set of signatures by following Step 3 — Updating Suricata Rulesets in the How To Install Suricata tutorial.
You will also need a second server to host Elasticsearch and Kibana. This server will be referred to as your Elasticsearch server. It should be an Ubuntu 20.04 server with:

4GB RAM and 2 CPUs set up with a non-root sudo user. You can achieve this by following the Initial Server Setup with Ubuntu 20.04.
For the purposes of this tutorial, both servers should be able to communicate using private IP addresses. You can use a VPN like WireGuard to connect your servers, or use a cloud-provider that has private networking between hosts. You can also choose to run Elasticsearch, Kibana, Filebeat, and Suricata on the same server for experimenting.

Step 1 — Installing Elasticsearch and Kibana
The first step in this tutorial is to install Elasticsearch and Kibana on your Elasticsearch server. To get started, add the Elastic GPG key to your server with the following command:

curl -fsSL https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo apt-key add –
Next, add the Elastic source list to the sources.list.d directory, where apt will search for new sources:

echo “deb https://artifacts.elastic.co/packages/7.x/apt stable main” | sudo tee -a /etc/apt/sources.list.d/elastic-7.x.list
Now update your server’s package index and install Elasticsearch and Kibana:

sudo apt update
sudo apt install elasticsearch kibana
Once you are done installing the packages, find and record your server’s private IP address using the ip address show command:

ip -brief address show
You will receive output like the following:

Output
lo UNKNOWN 127.0.0.1/8 ::1/128
eth0 UP 159.89.122.115/20 10.20.0.8/16 2604:a880:cad:d0::e56:8001/64 fe80::b832:69ff:fe46:7e5d/64
eth1 UP 10.137.0.5/16 fe80::b883:5bff:fe19:43f3/64
The private network interface in this output is the highlighted eth1 device, with the IPv4 address 10.137.0.5/16. Your device name, and IP addresses will be different. However, the address will be from the following reserved blocks of addresses:

10.0.0.0 to 10.255.255.255 (10/8 prefix)
172.16.0.0 to 172.31.255.255 (172.16/12 prefix)
192.168.0.0 to 192.168.255.255 (192.168/16 prefix)
If you would like to learn more about how these blocks are allocated visit the RFC 1918 specification)

Record the private IP address for your Elasticsearch server (in this case 10.137.0.5). This address will be referred to as your_private_ip in the remainder of this tutorial. Also note the name of the network interface, in this case eth1. In the next part of this tutorial you will configure Elasticsearch and Kibana to listen for connections on the private IP address coming from your Suricata server.

Step 2 — Configuring Elasticsearch
Elasticsearch is configured to only accept local connections by default. Additionally, it does not have any authentication enabled, so tools like Filebeat will not be able to send logs to it. In this section of the tutorial you will configure the network settings for Elasticsearch and then enable Elasticsearch’s built-in xpack security module.

Configuring Elasticsearch Networking
Since Your Elasticsearch and Suricata servers are separate, you will need to configure Elasticsearch to listen for connections on its private network interface. You will also need to configure your firewall rules to allow access to Elasticsearch on your private network interface.

Open the /etc/elasticsearch/elasticsearch.yml file using nano or your preferred editor:

sudo nano /etc/elasticsearch/elasticsearch.yml
Find the commented out #network.host: 192.168.0.1 line between lines 50–60 and add a new line after it that configures the network.bind_host setting, as highlighted below:

/etc/elasticsearch/elasticsearch.yml
# By default Elasticsearch is only accessible on localhost. Set a different
# address here to expose this node on the network:
#
#network.host: 192.168.0.1
network.bind_host: [“127.0.0.1”, “your_private_ip”]
#
# By default Elasticsearch listens for HTTP traffic on the first free port it
# finds starting at 9200. Set a specific HTTP port here:
Substitute your private IP in place of the your_private_ip address. This line will ensure that Elasticsearch is still available on its local address so that Kibana can reach it, as well as on the private IP address for your server.

Next, go to the end of the file using the nano shortcut CTRL+v until you reach the end.

Add the following highlighted lines to the end of the file:

/etc/elasticsearch/elasticsearch.yml
. . .
discovery.type: single-node
xpack.security.enabled: true
The discovery.type setting allows Elasticsearch to run as a single node, as opposed to in a cluster of other Elasticsearch servers. The xpack.security.enabled setting turns on some of the security features that are included with Elasticsearch.

Save and close the file when you are done editing it. If you are using nano, you can do so with CTRL+X, then Y and ENTER to confirm.

Finally, add firewall rules to ensure your Elasticsearch server is reachable on its private network interface. If you followed the prerequisite tutorials and are using the Uncomplicated Firewall (ufw), run the following commands:

sudo ufw allow in on eth1
sudo ufw allow out on eth1
Substitute your private network interface in place of eth1 if it uses a different name.

Next you will start the Elasticsearch daemon and then configure passwords for use with the xpack security module.

Starting Elasticsearch
Now that you have configured networking and the xpack security settings for Elasticsearch, you need to start it for the changes to take effect.

Run the following systemctl command to start Elasticsearch:

sudo systemctl start elasticsearch.service
Once Elasticsearch finishes starting, you can continue to the next section of this tutorial where you will generate passwords for the default users that are built-in to Elasticsearch.

Configuring Elasticsearch Passwords
Now that you have enabled the xpack.security.enabled setting, you need to generate passwords for the default Elasticsearch users. Elasticsearch includes a utility in the /usr/share/elasticsearch/bin directory that can automatically generate random passwords for these users.

Run the following command to cd to the directory and then generate random passwords for all the default users:

cd /usr/share/elasticsearch/bin
sudo ./elasticsearch-setup-passwords auto
You will receive output like the following. When prompted to continue, press y and then RETURN or ENTER:

Initiating the setup of passwords for reserved users elastic,apm_system,kibana,kibana_system,logstash_system,beats_system,remote_monitoring_user.
The passwords will be randomly generated and printed to the console.
Please confirm that you would like to continue [y/N]y

Changed password for user apm_system
PASSWORD apm_system = eWqzd0asAmxZ0gcJpOvn

Changed password for user kibana_system
PASSWORD kibana_system = 1HLVxfqZMd7aFQS6Uabl

Changed password for user kibana
PASSWORD kibana = 1HLVxfqZMd7aFQS6Uabl

Changed password for user logstash_system
PASSWORD logstash_system = wUjY59H91WGvGaN8uFLc

Changed password for user beats_system
PASSWORD beats_system = 2p81hIdAzWKknhzA992m

Changed password for user remote_monitoring_user
PASSWORD remote_monitoring_user = 85HF85Fl6cPslJlA8wPG

Changed password for user elastic
PASSWORD elastic = 6kNbsxQGYZ2EQJiqJpgl
You will not be able to run the utility again, so make sure to record these passwords somewhere secure. You will need to use the kibana_system user’s password in the next section of this tutorial, and the elastic user’s password in the Configuring Filebeat step of this tutorial.

At this point in the tutorial you are finished configuring Elasticsearch. The next section explains how to configure Kibana’s network settings and its xpack security module.

Step 3 — Configuring Kibana
In the previous section of this tutorial, you configured Elasticsearch to listen for connections on your Elasticsearch server’s private IP address. You will need to do the same for Kibana so that Filebeats on your Suricata server can reach it.

First you’ll enable Kibana’s xpack security functionality by generating some secrets that Kibana will use to store data in Elasticsearch. Then you’ll configure Kibana’s network setting and authentication details to connect to Elasticsearch.

Enabling xpack.security in Kibana
To get started with xpack security settings in Kibana, you need to generate some encryption keys. Kibana uses these keys to store session data (like cookies), as well as various saved dashboards and views of data in Elasticsearch.

You can generate the required encryption keys using the kibana-encryption-keys utility that is included in the /usr/share/kibana/bin directory. Run the following to cd to the directory and then generate the keys:

cd /usr/share/kibana/bin/
sudo ./kibana-encryption-keys generate -q
The -q flag suppresses the tool’s instructions so that you only receive output like the following:

Output
xpack.encryptedSavedObjects.encryptionKey: 66fbd85ceb3cba51c0e939fb2526f585
xpack.reporting.encryptionKey: 9358f4bc7189ae0ade1b8deeec7f38ef
xpack.security.encryptionKey: 8f847a594e4a813c4187fa93c884e92b
Copy your output somewhere secure. You will now add them to Kibana’s /etc/kibana/kibana.yml configuration file.

Open the file using nano or your preferred editor:

sudo nano /etc/kibana/kibana.yml
Go to the end of the file using the nano shortcut CTRL+v until you reach the end. Paste the three xpack lines that you copied to the end of the file:

/etc/kibana/kibana.yml
. . .

# Specifies locale to be used for all localizable strings, dates and number formats.
# Supported languages are the following: English – en , by default , Chinese – zh-CN .
#i18n.locale: “en”

xpack.encryptedSavedObjects.encryptionKey: 66fbd85ceb3cba51c0e939fb2526f585
xpack.reporting.encryptionKey: 9358f4bc7189ae0ade1b8deeec7f38ef
xpack.security.encryptionKey: 8f847a594e4a813c4187fa93c884e92b
Keep the file open and proceed to the next section where you will configure Kibana’s network settings.

Configuring Kibana Networking
To configure Kibana’s networking so that it is available on your Elasticsearch server’s private IP address, find the commented out #server.host: “localhost” line in /etc/kibana/kibana.yml. The line is near the beginning of the file. Add a new line after it with your server’s private IP address, as highlighted below:

/etc/kibana/kibana.yml
# Kibana is served by a back end server. This setting specifies the port to use.
#server.port: 5601

# Specifies the address to which the Kibana server will bind. IP addresses and host names are both valid values.
# The default is ‘localhost’, which usually means remote machines will not be able to connect.
# To allow connections from remote users, set this parameter to a non-loopback address.
#server.host: “localhost”
server.host: “your_private_ip”
Substitute your private IP in place of the your_private_ip address.

Save and close the file when you are done editing it. If you are using nano, you can do so with CTRL+X, then Y and ENTER to confirm.

Next, you’ll need to configure the username and password that Kibana uses to connect to Elasticsearch.

Configuring Kibana Credentials
There are two ways to set the username and password that Kibana uses to authenticate to Elasticsearch. The first is to edit the /etc/kibana/kibana.yml configuration file and add the values there. The second method is to store the values in Kibana’s keystore, which is an obfuscated file that Kibana can use to store secrets.

We’ll use the keystore method in this tutorial since it avoids editing Kibana’s configuration file directly

If you prefer to edit the file instead, the settings to configure in it are elasticsearch.username and elasticsearch.password.

If you choose to edit the configuration file, skip the rest of the steps in this section.

To add a secret to the keystore using the kibana-keystore utility, first cd to the /usr/share/kibana/bin directory. Next, run the following command to set the username for Kibana:

sudo ./kibana-keystore add elasticsearch.username
You will receive a prompt like the following:

Username Entry
Enter value for elasticsearch.username: *************
Enter kibana_system when prompted, either by copying and pasting, or typing the username carefully. Each character that you type will be masked with an * asterisk character. Press ENTER or RETURN when you are done entering the username.

Now repeat the same command for the password. Be sure to copy the password for the kibana_system user that you generated in the previous section of this tutorial. For reference, in this tutorial the example password is 1HLVxfqZMd7aFQS6Uabl.

Run the following command to set the password:

sudo ./kibana-keystore add elasticsearch.password
When prompted, paste the password to avoid any transcription errors:

Password Entry
Enter value for elasticsearch.password: ********************
Starting Kibana
Now that you have configured networking and the xpack security settings for Kibana, as well as added credentials to the keystore, you need to start it for the changes to take effect.

Run the following systemctl command to restart Kibana:

sudo systemctl start kibana.service
Once Kibana starts, you can continue to the next section of this tutorial where you will configure Filebeat on your Suricata server to send its logs to Elasticsearch.

Step 4 — Installing Filebeat
Now that your Elasticsearch and Kibana processes are configured with the correct network and authentication settings, the next step is to install and set up Filebeat on your Suricata server.

To get started installing Filebeat, add the Elastic GPG key to your Suricata server with the following command:

curl -fsSL https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo apt-key add –
Next, add the Elastic source list to the sources.list.d directory, where apt will search for new sources:

echo “deb https://artifacts.elastic.co/packages/7.x/apt stable main” | sudo tee -a /etc/apt/sources.list.d/elastic-7.x.list
Now update the server’s package index and install the Filebeat package:

sudo apt update
sudo apt install filebeat
Next you’ll need to configure Filebeat to connect to both Elasticsearch and Kibana. Open the /etc/filebeat/filebeat.yml configuration file using nano or your preferred editor:

sudo nano /etc/filebeat/filebeat.yml
Find the Kibana section of the file around line 100. Add a line after the commented out #host: “localhost:5601” line that points to your Kibana instance’s private IP address and port:

/etc/filebeat/filebeat.yml
. . .
# Starting with Beats version 6.0.0, the dashboards are loaded via the Kibana API.
# This requires a Kibana endpoint configuration.
setup.kibana:

# Kibana Host
# Scheme and port can be left out and will be set to the default (http and 5601)
# In case you specify and additional path, the scheme is required: http://localhost:5601/path
# IPv6 addresses should always be defined as: https://[2001:db8::1]:5601
#host: “localhost:5601”
host: “your_private_ip:5601”

. . .
This change will ensure that Filebeat can connect to Kibana in order to create the various SIEM indices, dashboards, and processing pipelines in Elasticsearch to handle your Suricata logs.

Next, find the Elasticsearch Output section of the file around line 130 and edit the hosts, username, and password settings to match the values for your Elasticsearch server:

output.elasticsearch:
# Array of hosts to connect to.
hosts: [“your_private_ip:9200”]

# Protocol – either `http` (default) or `https`.
#protocol: “https”

# Authentication credentials – either API key or username/password.
#api_key: “id:api_key”
username: “elastic”
password: “6kNbsxQGYZ2EQJiqJpgl”

. . .
Substitute in your Elasticsearch server’s private IP address on the hosts line in place of the your_private_ip value. Uncomment the username field and leave it set to the elastic user. Change the password field from changeme to the password for the elastic user that you generated in the Configuring Elasticsearch Passwords section of this tutorial.

Save and close the file when you are done editing it. If you are using nano, you can do so with CTRL+X, then Y and ENTER to confirm.

Next, enable Filebeats’ built-in Suricata module with the following command:

sudo filebeat modules enable suricata
Now that Filebeat is configured to connect to Elasticsearch and Kibana, with the Suricata module enabled, the next step is to load the SIEM dashboards and pipelines into Elasticsearch.

Run the filebeat setup command. It may take a few minutes to load everything:

sudo filebeat setup
Once the command finishes you should receive output like the following:

Output
Overwriting ILM policy is disabled. Set `setup.ilm.overwrite: true` for enabling.

Index setup finished.
Loading dashboards (Kibana must be running and reachable)
Loaded dashboards
Setting up ML using setup –machine-learning is going to be removed in 8.0.0. Please use the ML app instead.
See more: https://www.elastic.co/guide/en/machine-learning/current/index.html
It is not possible to load ML jobs into an Elasticsearch 8.0.0 or newer using the Beat.
Loaded machine learning job configurations
Loaded Ingest pipelines
If there are no errors, use the systemctl command to start Filebeat. It will begin sending events from Suricata’s eve.json log to Elasticsearch once it is running.

sudo systemctl start filebeat.service
Now that you have Filebeat, Kibana, and Elasticsearch configured to process your Suricata logs, the last step in this tutorial is to connect to Kibana and explore the SIEM dashboards.

Step 5 — Navigating Kibana’s SIEM Dashboards
Kibana is the graphical component of the Elastic stack. You will use Kibana with your browser to explore Suricata’s event and alert data. Since you configured Kibana to only be available via your Elasticsearch server’s private IP address, you will need to use an SSH tunnel to connect to Kibana.

Connecting to Kibana with SSH
SSH has an option -L that lets you forward network traffic on a local port over its connection to a remote IP address and port on a server. You will use this option to forward traffic from your browser to your Kibana instance.

On Linux, macOS, and updated versions of Windows 10 and higher, you can use the built-in SSH client to create the tunnel. You will use this command each time you want to connect to Kibana. You can close this connection at any time and then run the SSH command again to re-establish the tunnel.

Run the following command in a terminal on your local desktop or laptop computer to create the SSH tunnel to Kibana:

ssh -L 5601:your_private_ip:5601 [email protected] -N
The various arguments to SSH are:

The -L flag forwards traffic to your local system on port 5601 to the remote server.
The your_private_ip:5601 portion of the command specifies the service on your Elasticsearch server where your traffic will be fowarded to. In this case that service is Kibana. Be sure to substitute your Elasticsearch server’s private IP address in place of your_private_ip
The 203.11.0.5 address is the public IP address that you use to connect to and administer your server. Substitute your Elasticsearch server’s public IP address in its place.
The -N flag instructs SSH to not run a command like an interactive /bin/bash shell, and instead just hold the connection open. It is generally used when forwarding ports like in this example.
If you would like to close the tunnel at any time, press CTRL+C.

On Windows your terminal should resemble the following screenshot:

Note: You may be prompted to enter a password if you are not using an SSH key. Type or paste it into the prompt and press ENTER or RETURN.

Screenshot of Windows Command Prompt Showing SSH Command to Port Forward to Kibana

On macOS and Linux your terminal will be similar to the following screenshot:

Screenshot of Windows Command Prompt Showing SSH Command to Port Forward to Kibana

Once you have connected to your Elasticsearch server over SSH with the port forward in place, open your browser and visit http://127.0.0.1:5601. You will be redirected to Kibana’s login page:

Screenshot of a Browser on Kibana’s Login Page

If your browser cannot connect to Kibana you will receive a message like the following in your terminal:

Output
channel 3: open failed: connect failed: No route to host
This error indicates that your SSH tunnel is unable to reach the Kibana service on your server. Ensure that you have specified the correct private IP address for your Elasticsearch server and reload the page in your browser.

Log in to your Kibana server using elastic for the Username, and the password that you copied earlier in this tutorial for the user.

Browsing Kibana SIEM Dashboards
Once you are logged into Kibana you can explore the Suricata dashboards that Filebeat configured for you.

In the search field at the top of the Kibana Welcome page, input the search terms type:dashboard suricata. This search will return two results: the Suricata Events and Suricata Alerts dashboards per the following screenshot:

Screenshot of a Browser Using Kibana’s Global Search Box to Locate Suricata Dashboards

Click the [Filebeat Suricata] Events Overview result to visit the Kibana dashboard that shows an overview of all logged Suricata events:

Screenshot of a Browser on Kibana’s Suricata Events Dashboard

To visit the Suricata Alerts dashboard, repeat the search or click the Alerts link that is included in the Events dashboard. Your page should resemble the following screenshot:

Screenshot of a Browser on Kibana’s Suricata Alerts Dashboard

If you would like to inspect the events and alerts that each dashboard displays, scroll to the bottom of the page where you will find a table that lists each event and alert. You can expand each entry to view the original log entry from Suricata, and examine in detail the various fields like source and destination IPs for an alert, the attack type, Suricata signature ID, and others.

Kibana also has a built-in set of Security dashboards that you can access using the menu on the left side of the browser window. Navigate to the Network dashboard for an overview of events displayed on a map, as well as aggregate data about events on your network. Your dashboard should resemble the following screenshot:

Screenshot of a Browser on Kibana’s Security -> Network Dashboard

You can scroll to the bottom of the Network dashboard for a table that lists all of the events that match your specified search timeframe. You can also examine each event in detail, or select an event to generate a Kibana timeline, that you can then use to investigate specific traffic flows, alerts, or community IDs.

Conclusion
In this tutorial you installed and configured Elasticsearch and Kibana on a standalone server. You configured both tools to be available on a private IP address. You also configured Elasticsearch and Kibana’s authentication settings using the xpack security module that is included with each tool.

After completing the Elasticsearch and Kibana configuration steps, you also installed and configured Filebeat on your Suricata server. You used Filebeat to populate Kibana’s dashboards and start sending Suricata logs to Elasticsearch.

Finally, you created an SSH tunnel to your Elasticsearch server and logged into Kibana. You located the new Suricata Events and Alerts dashboards, as well as the Network dashboard.

The last tutorial in this series will guide you through using Kibana’s SIEM functionality to process your Suricata alerts. In it you will explore how to create cases to track specific alerts, timelines to correlate network flows, and rules to match specific Suricata events that you would like to track or analyze in more detail.

Configuring On-Access Scanning in ClamAV

原文:

https://docs.clamav.net/manual/OnAccess.html

https://www.ibm.com/docs/en/ahte/4.0?topic=wf-configuring-linux-many-watch-folders

Purpose

This guide is for users interested in leveraging and understanding ClamAV’s On-Access Scanning feature. It will walk through how to set up and use the On-Access Scanner and step through some common issues and their solutions.

Requirements

On-Access is only available on Linux systems. On Linux, On-Access requires a kernel version >= 3.8. This is because it leverages a kernel api called fanotify to block processes from attempting to access malicious files. This prevention occurs in kernel-space, and thus offers stronger protection than a purely user-space solution.

For Versions >= 0.102.0

It also requires Curl version >= 7.45 to ensure support for all curl options used by clamonacc. Users on Linux operating systems that package older versions of libcurl have a number of options:

  1. Wait for your package maintainer to provide a newer version of libcurl.
  2. Install a newer version of libcurl from source.
  3. Disable installation of clamonacc and On-Access Scanning capabilities with the ./configure flag --disable-clamonacc.

General Use

To use ClamAV’s On-Access Scanner, operation will vary depending on version.

For Versions >= 0.102.0

You will need to run the clamd and clamonacc applications side by side. First, you will need to configure and run clamd. For instructions on how to do that, see the clamd configuration guide. One important thing to note while configuring clamd.conf is that–like clamdscan–the clamonacc application will connect to clamd using the clamd.conf settings for either LocalSocket or TCPAddr/TCPSocket. Another important thing to note, is that when using a clamd.conf that specifies a LocalSocket, then clamd will need to be run under a user with the right permissions to scan the files you plan on including in your watch-path.

Next, you will need to configure clamonacc. For a very simple configuration, follow these steps:

1. Open `clamd.conf` for editing
2. Specify the path(s) you would like to recursively watch by setting the `OnAccessIncludePath` option
3. Set `OnAccessPrevention` to `yes`
4. Check what username `clamd` is running under
5. Set `OnAccessExcludeUname` to `clamd`'s uname
6. Save your work and close `clamd.conf`

For slightly more nuanced configurations, which may be adapted to your use case better, please check out the recipe guide below.

Then, run clamonacc with elevated permissions:

sudo clamonacc

If all went well, the On-Access scanner will fork to the background, and will now be actively protecting the path(s) specified with OnAccessIncludePath. You can test this by dropping an eicar file into the specified path, and attempting to read/access it (e.g. cat eicar.txt). This will result in an “Operation not permitted” message, triggered by fanotify blocking the access attempt at the kernel level.

Finally, you will have to restart both clamd and clamonacc. If default clamonacc performance is not to your liking, and your system has the resources available, we reccomend increasing the values for the following clamd.conf configuration options to increase performance:

  • MaxQueue
  • MaxThreads
  • OnAccessMaxThreads

For Versions <= 0.101.x

You will only need to run the clamd application in older versions. First, we reccomend you configure clamd for your environment. For instructions on how to do that, see the clamd configuration guide.

Next, you will need to configure On Access Scanning using the clamd.conf file. For a very simple configuration follow these steps:

1. Open `clamd.conf` for editing
2. Set the `ScanOnAccess` option to `yes`
3. Specify the path(s) you would like to recursively watch by setting the `OnAccessIncludePath` option
4. Set `OnAccessPrevention` to `yes`
6. Save your work and close `clamd.conf`

For slightly more nuanced configurations, which may be adapted to your use case better, please check out the recipe guide below.

Then, run clamd with elevated permissions:

sudo clamd

If all went well, the On-Access scanner will fork to the background, and will now be actively protecting the path(s) specified with OnAccessIncludePath. You can test this by dropping an eicar file into the specified path, and attempting to read/access it (e.g. cat eicar.txt). This will result in an “Operation not permitted” message, triggered by fanotify blocking the access attempt at the kernel level.

Troubleshooting

Some OS distributors have disabled fanotify, despite kernel support. You can check for fanotify support on your kernel by running the command:

cat /boot/config-<kernel_version> | grep FANOTIFY

You should see the following:

CONFIG_FANOTIFY=y
CONFIG_FANOTIFY_ACCESS_PERMISSIONS=y

If you see this…

CONFIG_FANOTIFY_ACCESS_PERMISSIONS is not set

… then ClamAV’s On-Access Scanner will still function, scanning and alerting on files normally in real time. However, it will be unable to block access attempts on malicious files. We call this notify-only mode.

ClamAV’s On-Access Scanning system uses a scheme called Dynamic Directory Determination (DDD for short) which is a shorthand way of saying that it tracks the layout of every directory specified with OnAccessIncludePath dynamically, and recursively.

In real time. It does this by leveraging inotify which by default has a limited number of watch-points available for use by a process at any given time. Given the complexity of some directory hierarchies, ClamAV may warn you that it has exhausted its supply of inotify watch-points (8192 by default). To increase the number of inotify watch-points available for use by ClamAV (to 524288), run the following command:

echo 524288 | sudo tee -a /proc/sys/fs/inotify/max_user_watches

The OnAccessIncludePath option will not accept / as a valid path. This is because fanotify works by blocking a process’ access to a file until a access_ok or access_denied determination has been made by the original fanotify calling process. Thus, by placing fanotify watch-points on the entire filesystem, key system files may have their access blocked to key processes at the kernel level, which will result in a system lockup.

This restriction was made to prevent users from “shooting themselves in the foot.” However, clever users will find it’s possible to circumvent this restriction by using multiple OnAccessIncludePath options to recursively protect most of the filesystem anyways, or better still, simply the paths they truly care about.

The OnAccessMountPath option uses a different fanotify api configuration which makes it incompatible with OnAccessIncludePath and the DDD System. Therefore, inotify watch-point limitations will not be a concern when using this option. Unfortunately, this also means that the following options cannot be used in conjunction with OnAccessMountPath:

  • OnAccessExtraScanning – is built around catching inotify events.
  • OnAccessExcludePath – is built upon the DDD System.
  • OnAccessPrevention – would lock up the system if / was selected for OnAccessMountPath. If you need OnAccessPrevention, you should use OnAccessIncludePath instead of OnAccessMountPath.

Configuration and Recipes

More nuanced behavior can be coerced from ClamAV’s On-Access Scanner via careful modification to clamd.conf. Each option related to On-Access Scanning is easily identified by looking for the OnAccess prefix pre-pended to each option. The default clamd.conf file contains descriptions of each option, along with any documented limitations or safety features.

Below are examples of common use cases, recipes for the correct minimal configuration, and the expected behavioral result.

Use Case 0x0

  • User needs to watch the entire file system, but blocking malicious access attempts isn’t a concern
    ScanOnAccess yes ## versions <= 0.101.x
    OnAccessMountPath /
    OnAccessExcludeRootUID yes
    OnAccessExcludeUname clamav ## versions >= 0.102

This configuration will put the On-Access Scanner into notify-only mode. It will also ensure only non-root, non-clam, user processes will trigger scans against the filesystem.

Use Case 0x1

  • System Administrator needs to watch the home directory of multiple Users, but not all users. Blocking access attempts is un-needed.
    ScanOnAccess yes ## versions <= 0.101.x
    OnAccessIncludePath /home
    OnAccessExcludePath /home/user2
    OnAccessExcludePath /home/user4
    OnAccessExcludeUname clamav ## versions >= 0.102

With this configuration, the On-Access Scanner will watch the entirety of the /home directory recursively in notify-only mode. However, it will recursively exclude the /home/user2 and /home/user4 directories.

Use Case 0x2

  • The user needs to protect a single directory non-recursively and ensure all access attempts on malicious files are blocked.
    ScanOnAccess yes ## versions <= 0.101.x
    OnAccessIncludePath /home/user/Downloads
    OnAccessExcludeUname clamav ## versions >= 0.102
    OnAccessPrevention yes
    OnAccessDisableDDD yes

The configuration above will result in non-recursive real-time protection of the /home/user/Downloads directory by ClamAV’s On-Access Scanner. Any access attempts that ClamAV detects on malicious files within the top level of the directory hierarchy will be blocked by fanotify at the kernel level.

Command Line Options for Versions >= 0.102

Beyond clamd.conf configuration, you can change the behavior of the On-Access scanner by passing in a number of command line options. A list of all options can be retrieved with --help, but below is a list and explanation of some of options you might find most useful.

  • --log=FILE (-l FILE) – passing this option is important if you want a record of scan results, otherwise clamonacc will operate silently.
  • --verbose (-v) – primarily for debugging as this will increase the amount of noise in your log by quite a lot, but useful for troubleshooting potential connection problems
  • --foreground (-F) – forces clamonacc to not for the background, which is useful for debugging potential issues with during startup or runtime
  • --include-list=FILE (-e FILE) – allows users to pass a list of directories for clamonacc to watch, each directory must be a full path and separated by a newline
  • --exclude-list=FILE (-e FILE) – same as include-list option, but for excluding at startup
  • --remove – after an infected verdict, an attempt will be made to remove the infected file
  • --move=DIRECTORY – just like the remove option, but infected file will be moved to the specified quarantine location instead
  • --copy=DIRECTORY – just like the move, except infected file is also left in place

 

 

 

Configuring Linux for Many Watch Folders

Last Updated: 2021-03-01

To run many (>100) push Watch Folders on Linux computers, adjust three system settings and then reload the sysctl.conf file to activate them.

Procedure

  1. Increase the maximum number of watches allowed by the system.

    Retrieve the current value by running the following command:

    $ cat /proc/sys/fs/inotify/max_user_watches
    8192

     

    To permanently increase the number of available watches (to a value that is greater than the number of files to watch, such as 524288), add the configuration to /etc/sysctl.conf:

    $ sudo echo "fs.inotify.max_user_watches=524288" >> /etc/sysctl.conf

     

  2. Increase the maximum number of inotify instances, which correspond to the number of allowed Watch Services instances.

    Retrieve the current value by running the following command:

    $ cat /proc/sys/fs/inotify/max_user_instances
    128

     

    On many systems, the default value is 128, meaning only 128 watches can be created. To permanently increase the number available (to a value that is greater than the number of desired Watch Folder instances, such as 1024), add the configuration to /etc/sysctl.conf:

    $ sudo echo "fs.inotify.max_user_instances=1024" >> /etc/sysctl.conf

     

  3. Increase the open file limit.

    Retrieve the current value by running the following command:

    $ cat /proc/sys/fs/file-max
    794120

     

    To permanently increase the open file limit (to a value that is greater than the number of desired watches, such as 2097152), add the configuration to /etc/sysctl.conf:

    $ sudo echo "fs.file-max=2097152" >> /etc/sysctl.conf

     

  4. Reload systemd settings to activate the new settings.

    To reload systemd settings, either reboot the machine or run the following command:

    $ sudo sysctl -p /etc/sysctl.conf

How To Configure Suricata as an Intrusion Prevention System (IPS) on Ubuntu 20.04

原文:

https://www.digitalocean.com/community/tutorials/how-to-configure-suricata-as-an-intrusion-prevention-system-ips-on-ubuntu-20-04

https://suricata.readthedocs.io/en/suricata-6.0.0/setting-up-ipsinline-for-linux.html

Introduction

In this tutorial you will learn how to configure Suricata’s built-in Intrusion Prevention System (IPS) mode on Ubuntu 20.04. By default Suricata is configured to run as an Intrusion Detection System (IDS), which only generates alerts and logs suspicious traffic. When you enable IPS mode, Suricata can actively drop suspicious network traffic in addition to generating alerts for further analysis.

Before enabling IPS mode, it is important to check which signatures you have enabled, and their default actions. An incorrectly configured signature, or a signature that is overly broad may result in dropping legitimate traffic to your network, or even block you from accessing your servers over SSH and other management protocols.

In the first part of this tutorial you will check the signatures that you have installed and enabled. You will also learn how to include your own signatures. Once you know which signatures you would like to use in IPS mode, you’ll convert their default action to drop or reject traffic. With your signatures in place, you’ll learn how to send network traffic through Suricata using the netfilter NFQUEUE iptables target, and then generate some invalid network traffic to ensure that Suricata drops it as expected.

Prerequisites

If you have been following this tutorial series then you should already have Suricata running on an Ubuntu 20.04 server.

If you still need to install Suricata then you can follow How To Install Suricata on Ubuntu 20.04

You should also have the ET Open Ruleset downloaded using the suricata-update command, and included in your Suricata signatures.

The jq command line JSON processing tool. If you do not have it installed from a previous tutorial, you can do so using the apt command:

sudo apt update
sudo apt install jq

You may also have custom signatures that you would like to use from the previous Understanding Suricata Signatures tutorial.

Step 1 — Including Custom Signatures

The previous tutorials in this series explored how to install and configure Suricata, as well as how to understand signatures. If you would like to create and include your own rules then you need to edit Suricata’s /etc/suricata/suricata.yaml file to include a custom path to your signatures.

First, let’s find your server’s public IPs so that you can use them in your custom signatures. To find your IPs you can use the ip command:

ip -brief address show

You should receive output like the following:

Output
lo UNKNOWN 127.0.0.1/8 ::1/128
eth0 UP 203.0.113.5/20 10.20.0.5/16 2001:DB8::1/32 fe80::94ad:d4ff:fef9:cee0/64
eth1 UP 10.137.0.2/16 fe80::44a2:ebff:fe91:5187/64

Your public IP address(es) will be similar to the highlighted 203.0.113.5 and 2001:DB8::1/32 IPs in the output.

Now let’s create the following custom signature to scan for SSH traffic to non-SSH ports and include it in a file called /var/lib/suricata/rules/local.rules. Open the file with nano or your preferred editor:

sudo nano /var/lib/suricata/rules/local.rules

Copy and paste the following signature:

Invalid SSH Traffic Signature

alert ssh any any -> 203.0.113.5 !22 (msg:"SSH TRAFFIC on non-SSH port"; flow:to_client, not_established; classtype: misc-attack; target: dest_ip; sid:1000000;)
alert ssh any any -> 2001:DB8::1/32 !22 (msg:"SSH TRAFFIC on non-SSH port"; flow:to_client, not_established; classtype: misc-attack; target: dest_ip; sid:1000001;)

Substitute your server’s public IP address in place of the 203.0.113.5 and 2001:DB8::1/32 addresses in the rule. If you are not using IPv6 then you can skip adding that signature in this and the following rules.

You can continue adding custom signatures to this local.rules file depending on your network and applications. For example, if you wanted to alert about HTTP traffic to non-standard ports, you could use the following signatures:

HTTP traffic on non-standard port signature

alert http any any -> 203.0.113.5 !80 (msg:"HTTP REQUEST on non-HTTP port"; flow:to_client, not_established; classtype:misc-activity; sid:1000002;)
alert http any any -> 2001:DB8::1/32 !80 (msg:"HTTP REQUEST on non-HTTP port"; flow:to_client, not_established; classtype:misc-activity; sid:1000003;)

To add a signature that checks for TLS traffic to ports other than the default 443 for web servers, add the following:

TLS traffic on non-standard port signature

alert tls any any -> 203.0.113.5 !443 (msg:"TLS TRAFFIC on non-TLS HTTP port"; flow:to_client, not_established; classtype:misc-activity; sid:1000004;)
alert tls any any -> 2001:DB8::1/32 !443 (msg:"TLS TRAFFIC on non-TLS HTTP port"; flow:to_client, not_established; classtype:misc-activity; sid:1000005;)

When you are done adding signatures, save and close the file. If you are using nano, you can do so with CTRL+X, then Y and ENTER to confirm. If you are using vi, press ESC and then 😡 then ENTER to save and exit.

Now that you have some custom signatures defined, edit Suricata’s /etc/suricata/suricata.yaml configuration file using nano or your preferred editor to include them:

sudo nano /etc/suricata/suricata.yaml

Find the rule-files: portion of the configuration. If you are using nano use CTRL+_ and then enter the line number 1879. If you are using vi enter 1879gg to go to the line. The exact location in your file may be different, but you should be in the correct general region of the file.

Edit the section and add the following highlighted – local.rules line:

/etc/suricata/suricata.yaml

. . .
rule-files:
- suricata.rules
- local.rules
. . .

Save and exit the file. Be sure to validate Suricata’s configuration after adding your rules. To do so run the following command:

sudo suricata -T -c /etc/suricata/suricata.yaml -v

The test can take some time depending on how many rules you have loaded in the default suricata.rules file. If you find the test takes too long, you can comment out the – suricata.rules line in the configuration by adding a # to the beginning of the line and then run your configuration test again. Be sure to remove the # comment if you plan to use the suricata.rules signature in your final running configuration.

Once you are satisfied with the signatures that you have created or included using the suricata-update tool, you can proceed to the next step, where you’ll switch the default action for your signatures from alert or log to actively dropping traffic.

Step 2 — Configuring Signature Actions

Now that you have your custom signatures tested and working with Suricata, you can change the action to drop or reject. When Suricata is operating in IPS mode, these actions will actively block invalid traffic for any matching signature.

These two actions are described in the previous tutorial in this series, Understanding Suricata Signatures. The choice of which action to use is up to you. A drop action will immediately discard a packet and any subsequent packets that belong to the network flow. A reject action will send both the client and server a reset packet if the traffic is TCP-based, and an ICMP error packet for any other protocol.

Let’s use the custom rules from the previous section and convert them to use the drop action, since the traffic that they match is likely to be a network scan, or some other invalid connection.

Open your /var/lib/suricata/rules/local.rules file using nano or your preferred editor and change the alert action at the beginning of each line in the file to drop:

sudo nano /var/lib/suricata/rules/local.rules

/var/lib/suricata/rules/local.rules

drop ssh any any -> 203.0.113.5 !22 (msg:"SSH TRAFFIC on non-SSH port"; classtype: misc-attack; target: dest_ip; sid:1000000;)
drop ssh any any -> 2001:DB8::1/32 !22 (msg:"SSH TRAFFIC on non-SSH port"; classtype: misc-attack; target: dest_ip; sid:1000001;)
. . .

Repeat the step above for any signatures in /var/lib/suricata/rules/suricata.rules that you would like to convert to drop or reject mode.

Note: If you ran suricata-update in the prerequisite tutorial, you may have more than 30,000 signatures included in your suricata.rules file.

If you convert every signature to drop or reject you risk blocking legitimate access to your network or servers. Instead, leave the rules in suricata.rules for the time being, and add your custom signatures to local.rules. Suricata will continue to generate alerts for suspicious traffic that is described by the signatures in suricata.rules while it is running in IPS mode.

After you have a few days or weeks of alerts collected, you can analyze them and choose the relevant signatures to convert to drop or reject based on their sid.

Once you have all the signatures configured with the action that you would like them to take, the next step is to reconfigure and then restart Suricata in IPS mode.

Step 3 — Enabling nfqueue Mode

Suricata runs in IDS mode by default, which means it will not actively block network traffic. To switch to IPS mode, you’ll need to edit Suricata’s /etc/default/suricata configuration file.

Open the file in nano or your preferred editor:

sudo nano /etc/default/suricata

Find the LISTENMODE=af-packet line and comment it out by adding a # to the beginning of the line. Then add a new line LISTENMODE=nfqueue line that tells Suricata to run in IPS mode.

Your file should have the following highlighted lines in it when you are done editing:

/etc/default/suricata

. . .
# LISTENMODE=af-packet
LISTENMODE=nfqueue
. . .

Save and close the file. Now you can restart Suricata using systemctl:

sudo systemctl restart suricata.service

Check Suricata’s status using systemctl:

sudo systemctl status suricata.service

You should receive output like the following:

 

Output
● suricata.service - LSB: Next Generation IDS/IPS
Loaded: loaded (/etc/init.d/suricata; generated)
Active: active (running) since Wed 2021-12-01 15:54:28 UTC; 2s ago
Docs: man:systemd-sysv-generator(8)
Process: 1452 ExecStart=/etc/init.d/suricata start (code=exited, status=0/SUCCESS)
Tasks: 12 (limit: 9513)
Memory: 63.6M
CGroup: /system.slice/suricata.service
└─1472 /usr/bin/suricata -c /etc/suricata/suricata.yaml --pidfile /var/run/suricata.pid -q 0 -D -vvv

Dec 01 15:54:28 suricata systemd[1]: Starting LSB: Next Generation IDS/IPS...
Dec 01 15:54:28 suricata suricata[1452]: Starting suricata in IPS (nfqueue) mode... done.
Dec 01 15:54:28 suricata systemd[1]: Started LSB: Next Generation IDS/IPS.

Note the highlighted active (running) line that indicates Suricata restarted successfully. Also note the Starting suricata in IPS (nfqueue) mode… done. line, which confirms Suricata is now running in IPS mode.

With this change you are now ready to send traffic to Suricata using the UFW firewall in the next step.

Step 4 — Configuring UFW To Send Traffic to Suricata

Now that you have configured Suricata to process traffic in IPS mode, the next step is to direct incoming packets to Suricata. If you followed the prerequisite tutorials for this series and are using an Ubuntu 20.04 system, you should have the Uncomplicated Firewall (UFW) installed and enabled.

To add the required rules for Suricata to UFW, you will need to edit the firewall files in the /etc/ufw/before.rules (IPv4 rules) and /etc/ufw/before6.rules (IPv6) directly.

Open the first file for IPv4 rules using nano or your preferred editor:

sudo nano /etc/ufw/before.rules

Near the beginning of the file, insert the following highlighted lines:

/etc/ufw/before.rules

(此处参考https://suricata.readthedocs.io/en/suricata-6.0.0/setting-up-ipsinline-for-linux.html,hosts规则)

. . .
# Don't delete these required lines, otherwise there will be errors
*filter
:ufw-before-input - [0:0]
:ufw-before-output - [0:0]
:ufw-before-forward - [0:0]
:ufw-not-local - [0:0]
# End required lines

## Start Suricata NFQUEUE rules
-I FORWARD -j NFQUEUE
-I OUTPUT -j NFQUEUE
## End Suricata NFQUEUE rules

# allow all on loopback
-A ufw-before-input -i lo -j ACCEPT
-A ufw-before-output -o lo -j ACCEPT
. . .

Save and exit the file when you are done editing it. Now add the same highlighted lines to the same section in the /etc/ufw/before6.rules file:

sudo nano /etc/ufw/before.rules

Ensure that both files have the same contents. Save and exit the file when you are done editing it.

The first two INPUT and OUTPUT rules are used to bypass Suricata so that you can connect to your server using SSH, even when Suricata is not running. Without these rules, an incorrect or overly broad signature could block your SSH access. Additionally, if Suricata is stopped, all traffic will be sent to the NFQUEUE target and then dropped since Suricata is not running.

The next FORWARD rule ensures that if your server is acting as a gateway for other systems, all that traffic will also go to Suricata for processing.

The final two INPUT and OUTPUT rules send all remaining traffic that is not SSH traffic to Suricata for processing.

Restart UFW to load the new rules:

sudo systemctl restart ufw.service

Note: If you are using another firewall you will need to modify these rules to match the format your firewall expects.

If you are using iptables, then you can insert these rules directly using the iptables and ip6tables commands. However, you will need to ensure that the rules are persistent across reboots with a tool like iptables-persistent.

If you are using firewalld, then the following rules will direct traffic to Suricata:

firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT 0 -p tcp --dport 22 -j NFQUEUE --queue-bypass
firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT 1 -j NFQUEUE
firewall-cmd --permanent --direct --add-rule ipv6 filter INPUT 0 -p tcp --dport 22 -j NFQUEUE --queue-bypass
firewall-cmd --permanent --direct --add-rule ipv6 filter INPUT 1 -j NFQUEUE

firewall-cmd --permanent --direct --add-rule ipv4 filter FORWARD 0 -j NFQUEUE
firewall-cmd --permanent --direct --add-rule ipv6 filter FORWARD 0 -j NFQUEUE

firewall-cmd --permanent --direct --add-rule ipv4 filter OUTPUT 0 -p tcp --sport 22 -j NFQUEUE --queue-bypass
firewall-cmd --permanent --direct --add-rule ipv4 filter OUTPUT 1 -j NFQUEUE
firewall-cmd --permanent --direct --add-rule ipv6 filter OUTPUT 0 -p tcp --sport 22 -j NFQUEUE --queue-bypass
firewall-cmd --permanent --direct --add-rule ipv6 filter OUTPUT 1 -j NFQUEUE

At this point in the tutorial you have Suricata configured to run in IPS mode, and your network traffic is being sent to Suricata by default. You will be able to restart your server at any time and your Suricata and firewall rules will be persistent.

The last step in this tutorial is to verify Suricata is dropping traffic correctly.

Step 5 — Testing Invalid Traffic

Now that you have Suricata and your firewall configured to process network traffic, you can test whether Suricata will drop packets that match your custom and other included signatures.

Recall signature sid:2100498 from the previous tutorial, which is modified in this example to drop matching packets:

sid:2100498

drop ip any any -> any any (msg:"GPL ATTACK_RESPONSE id check returned root"; content:"uid=0|28|root|29|"; classtype:bad-unknown; sid:2100498; rev:7; metadata:created_at 2010_09_23, updated_at 2010_09_23;)

Find and edit the rule in your /var/lib/suricata/rules/suricata.rules file to use the drop action if you have the signature included there. Otherwise, add the rule to your /var/lib/suricata/rules/local.rules file.

Send Suricata the SIGUSR2 signal to get it to reload its signatures:

sudo kill -usr2 $(pidof suricata)

Now test the rule using curl:

curl --max-time 5 http://testmynids.org/uid/index.html

You should receive an error stating that the request timed out, which indicates Suricata blocked the HTTP response:

Output
curl: (28) Operation timed out after 5000 milliseconds with 0 out of 39 bytes received

You can confirm that Suricata dropped the HTTP response using jq to examine the eve.log file:

jq 'select(.alert .signature_id==2100498)' /var/log/suricata/eve.json

You should receive output like the following:

Output
{
. . .
"community_id": "1:tw19kjR2LeWacglA094gRfEEuDU=",
"alert": {
"action": "blocked",
"gid": 1,
"signature_id": 2100498,
"rev": 7,
"signature": "GPL ATTACK_RESPONSE id check returned root",
"category": "Potentially Bad Traffic",
"severity": 2,
"metadata": {
"created_at": [
"2010_09_23"
],
"updated_at": [
"2010_09_23"
]
}
},
"http": {
"hostname": "testmynids.org",
"url": "/uid/index.html",
"http_user_agent": "curl/7.68.0",
"http_content_type": "text/html",
"http_method": "GET",
"protocol": "HTTP/1.1",
"status": 200,
"length": 39
},
. . .

The highlighted “action”: “blocked” line confirms that the signature matched, and Suricata dropped or rejected the test HTTP request.

Conclusion

In this tutorial you configured Suricata to block suspicious network traffic using its built-in IPS mode. You also added custom signatures to examine and block SSH, HTTP, and TLS traffic on non-standard ports. To tie everything together, you also added firewall rules to direct traffic through Suricata for processing.

Now that you have Suricata installed and configured in IPS mode, and can write your own signatures that either alert on or drop suspicious traffic, you can continue monitoring your servers and networks, and refining your signatures.

Once you are satisfied with your Suricata signatures and configuration, you can continue with the last tutorial in this series, which will guide you through sending logs from Suricata to a Security and Information Event Management (SIEM) system built using the Elastic Stack.

Customer Guidance for WannaCrypt attacks

 

https://blogs.technet.microsoft.com/msrc/2017/05/12/customer-guidance-for-wannacrypt-attacks/

Microsoft solution available to protect additional products

Today many of our customers around the world and the critical systems they depend on were victims of malicious “WannaCrypt” software. Seeing businesses and individuals affected by cyberattacks, such as the ones reported today, was painful. Microsoft worked throughout the day to ensure we understood the attack and were taking all possible actions to protect our customers. This blog spells out the steps every individual and business should take to stay protected. Additionally, we are taking the highly unusual step of providing a security update for all customers to protect Windows platforms that are in custom support only, including Windows XP, Windows 8, and Windows Server 2003. Customers running Windows 10 were not targeted by the attack today.

Details are below.

  • In March, we released a security update which addresses the vulnerability that these attacks are exploiting. Those who have Windows Update enabled are protected against attacks on this vulnerability. For those organizations who have not yet applied the security update, we suggest you immediately deploy Microsoft Security Bulletin MS17-010.
  • For customers using Windows Defender, we released an update earlier today which detects this threat as Ransom:Win32/WannaCrypt. As an additional “defense-in-depth” measure, keep up-to-date anti-malware software installed on your machines. Customers running anti-malware software from any number of security companies can confirm with their provider, that they are protected.
  • This attack type may evolve over time, so any additional defense-in-depth strategies will provide additional protections. (For example, to further protect against SMBv1 attacks, customers should consider blocking legacy protocols on their networks).

We also know that some of our customers are running versions of Windows that no longer receive mainstream support. That means those customers will not have received the above mentioned Security Update released in March. Given the potential impact to customers and their businesses, we made the decision to make the Security Update for platforms in custom support only, Windows XP, Windows 8, and Windows Server 2003, broadly available for download (see links below).

Customers who are running supported versions of the operating system (Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8.1, Windows Server 2012, Windows 10, Windows Server 2012 R2, Windows Server 2016) will have received the security update MS17-010 in March. If customers have automatic updates enabled or have installed the update, they are protected. For other customers, we encourage them to install the update as soon as possible.

This decision was made based on an assessment of this situation, with the principle of protecting our customer ecosystem overall, firmly in mind.

Some of the observed attacks use common phishing tactics including malicious attachments. Customers should use vigilance when opening documents from untrusted or unknown sources. For Office 365 customers we are continually monitoring and updating to protect against these kinds of threats including Ransom:Win32/WannaCrypt. More information on the malware itself is available from the Microsoft Malware Protection Center on the Windows Security blog. For those new to the Microsoft Malware Protection Center, this is a technical discussion focused on providing the IT Security Professional with information to help further protect systems.

We are working with customers to provide additional assistance as this situation evolves, and will update this blog with details as appropriate.

Update 5/22/2017: Today, we released an update to the Microsoft Malicious Software Removal Tool (MSRT) to detect and remove WannaCrypt malware. For customers that run Windows Update, the tool will detect and remove WannaCrypt and other prevalent malware infections. Customers can also manually download and run the tool by following the guidance here. The MSRT tool runs on all supported Windows machines where automatic updates are enabled, including those that aren’t running other Microsoft security products.

Phillip Misner, Principal Security Group Manager  Microsoft Security Response Center

Further resources:

General information on ransomware

Protecting your PC from ransomware

MS17-010 security update

How to verify that MS17-010 is installed

Download English language security updates: Windows Server 2003 SP2 x64Windows Server 2003 SP2 x86, Windows XP SP2 x64Windows XP SP3 x86Windows XP Embedded SP3 x86Windows 8 x86, Windows 8 x64

Download localized language security updates: Windows Server 2003 SP2 x64Windows Server 2003 SP2 x86Windows XP SP2 x64Windows XP SP3 x86Windows XP Embedded SP3 x86Windows 8 x86Windows 8 x64

How to enable and disable SMB in Windows and Windows Server & GPO deployment

Guidance for Azure customers

Applying MS17-010 using Microsoft Intune

ConfigMgr SQL queries for reporting on KBs related to MS17-010

Guidance for Operations Management Suite customers

LiveUpdate 更新受阻的解决方案

一、选取可用 IP 地址。
使用 PING 测试下列三组 IP,各选出一个可连通且延迟最低的 IP.

  1. liveupdate.symantec.com
  2. 152.195.12.135
  3. 152.195.132.120
  4. 152.195.38.43

复制代码

  1. liveupdate.symantecliveupdate.com
  2. 152.195.12.171
  3. 152.195.132.156
  4. 152.195.38.63

复制代码

  1. update.symantec.com
  2. 165.254.106.202
  3. 165.254.106.196
  4. 165.254.106.226
  5. 165.254.106.208
  6. 69.192.2.38
  7. 124.40.41.156
  8. 69.192.2.35
  9. 69.192.2.34
  10. 69.192.2.37
  11. 69.192.2.36
  12. 124.40.41.235
  13. 124.40.41.146
  14. 124.40.41.236
  15. 69.192.2.39
  16. 69.192.2.39
  17. 69.192.2.35
  18. 104.94.101.45
  19. 104.94.101.44
  20. 104.94.101.48
  21. 104.94.101.49
  22. 104.94.101.46

复制代码

二、添加至 HOSTS 文件。
将上一步选取的三个 IP 地址添加至 HOSTS 文件。方法不再赘述。
提供一个模板如下:

  1. # Symantec LiveUpdate IP Address
  2. 152.195.132.120 liveupdate.symantec.com
  3. 152.195.12.171  liveupdate.symantecliveupdate.com
  4. 69.192.2.39     update.symantec.com

复制代码

三、刷新本地 DNS 缓存。
管理员权限运行命令:

  1. ipconfig /flushDNS

复制代码

四、已知问题。

  • 重定向 Norton 更新域名后,Norton 可能会报 SecurityRisk.URLRedir

symantec离线下载

产品目录
https://www.symantec.com/zh/cn/security_response/definitions.jsp?

https://www.symantec.com/security_response/definitions/download/detail.jsp?gid=sep

SEP 14
https://www.symantec.com/security_response/definitions/download/detail.jsp?gid=sep14
https://www.symantec.com/security_response/definitions/download/detail.jsp?gid=ips14

Symantec Endpoint Protection官方下载

下载链接

12.1.6 MP6

http://esdownload.symantec.com/akdlm/CD/MTV/Symantec_Endpoint_Protection_12.1.6_MP6_All_Clients_EN.zip

http://esdownload.symantec.com/akdlm/CD/MTV/Symantec_Endpoint_Protection_12.1.6_MP6_All_Clients_CH.zip

http://esdownload.symantec.com/akdlm/CD/MTV/Symantec_Endpoint_Protection_12.1.6_MP6_All_Clients_CS.zip

 

12.1.6 MP9

http://esdownload.symantec.com/akdlm/CD/MTV/Symantec_Endpoint_Protection_12.1.6_MP9_All_Clients_EN.zip

http://esdownload.symantec.com/akdlm/CD/MTV/Symantec_Endpoint_Protection_12.1.6_MP9_All_Clients_CH.zip

http://esdownload.symantec.com/akdlm/CD/MTV/Symantec_Endpoint_Protection_12.1.6_MP9_All_Clients_CS.zip

 

wget --header="Cookie: veritas_main" http://esdownload.symantec.com/akdlm/CD/MTV/Symantec_Endpoint_Protection_12.1.6_MP9_All_Clients_CS.zip

 

14.0

http://esdownload.symantec.com/akdlm/CD/MTV/Symantec_Endpoint_Protection_14.0.1_MP1_SEPM_CS.exe

http://esdownload.symantec.com/akdlm/CD/MTV/Symantec_Endpoint_Protection_14.0.1_MP1_All_Clients_CS.zip

http://esdownload.symantec.com/akdlm/CD/MTV/Symantec_Endpoint_Protection_14.0.1_MP1_Full_Installation_CS.exe

 

wget --header="Cookie: veritas_main" http://esdownload.symantec.com/akdlm/CD/MTV/Symantec_Endpoint_Protection_14.0.1_MP1_All_Clients_CS.zip

 

14.2

http://esdownload.symantec.com/akdlm/CD/MTV/Symantec_Endpoint_Protection_14.2.0_SEPM_CS.exe

http://esdownload.symantec.com/akdlm/CD/MTV/Symantec_Endpoint_Protection_14.2.0_All_Clients_CS.zip

http://esdownload.symantec.com/akdlm/CD/MTV/Symantec_Endpoint_Protection_14.2.0_Full_Installation_CS.exe

 

http://esdownload.symantec.com/akdlm/CD/MTV/Symantec_Endpoint_Protection_14.2.0_SEPM_EN.exe

http://esdownload.symantec.com/akdlm/CD/MTV/Symantec_Endpoint_Protection_14.2.0_All_Clients_EN.zip

http://esdownload.symantec.com/akdlm/CD/MTV/Symantec_Endpoint_Protection_14.2.0_Full_Installation_EN.exe

wget --header="Cookie: veritas_main" http://esdownload.symantec.com/akdlm/CD/MTV/Symantec_Endpoint_Protection_14.2.0_All_Clients_EN.zip

14.3

官方生成的链接:
International English 英文https://downloadsapi.broadcom.com/utils/IpqOz1cVZGarMEw/18508784/Sep_to_558_Client_Only_Patches_EN.zip
https://downloadsapi.broadcom.com/utils/u56InEACYjN1805/18508785/Symantec_Endpoint_Protection_14.3.0_All_Clients_EN.zip
https://downloadsapi.broadcom.com/utils/FLiPp91CCyHPw5A/18508786/Symantec_Endpoint_Protection_14.3.0_Full_Installation_EN.exe
https://downloadsapi.broadcom.com/utils/jFNHuzlJSDAwfdI/18508787/Symantec_Endpoint_Protection_14.3.0_SEPM_EN.exe
Traditional Chinese 繁体中文
https://downloadsapi.broadcom.com/utils/RpNkqTax8NUTLzo/18508788/Symantec_Endpoint_Protection_14.3.0_All_Clients_CH.zip
https://downloadsapi.broadcom.com/utils/XJNqvD70rflmx4w/18508790/Symantec_Endpoint_Protection_14.3.0_Full_Installation_CH.exe
https://downloadsapi.broadcom.com/utils/ZOfqCDORBCMchtS/18508792/Symantec_Endpoint_Protection_14.3.0_SEPM_CH.exe
Simplified Chinese 简体中文
https://downloadsapi.broadcom.com/utils/vXFb1jD4gg3WKMm/18508795/Symantec_Endpoint_Protection_14.3.0_All_Clients_CS.zip
https://downloadsapi.broadcom.com/utils/FBIt8Q2O120hBIM/18508796/Symantec_Endpoint_Protection_14.3.0_Full_Installation_CS.exe
https://downloadsapi.broadcom.com/utils/GYi8eW9sDVMkZBU/18508797/Symantec_Endpoint_Protection_14.3.0_SEPM_CS.exe
Spanish 西班牙
https://downloadsapi.broadcom.com/utils/eu13JRHHURNInjP/18508798/Symantec_Endpoint_Protection_14.3.0_All_Clients_SL.zip
https://downloadsapi.broadcom.com/utils/aPeKOMpxwQwyPdP/18508799/Symantec_Endpoint_Protection_14.3.0_Full_Installation_SL.exe
https://downloadsapi.broadcom.com/utils/aPeKOMpxwQwyPdP/18508799/Symantec_Endpoint_Protection_14.3.0_Full_Installation_SL.exe

离线库

产品目录
https://www.symantec.com/zh/cn/security_response/definitions.jsp?

SEP14

https://www.broadcom.cn/support/security-center/definitions?pid=sep14

Mirror

14.3 RU1

Symantec Endpoint Protection 14.3 RU1 for Windows 64-bit (115 MB)
https://dl.comss.org/download/Symantec_Endpoint_Protection_14.3.0_RU1_Win64-bit_Client_EN.exe

Symantec Endpoint Protection 14.3 RU1 for Windows 32-bit (105 MB)
https://dl.comss.org/download/Symantec_Endpoint_Protection_14.3.0_RU1_Win32-bit_Client_EN.exe

Symantec Endpoint Protection 14.3 RU1 for MacOS (124 MB)
https://dl.comss.org/download/Symantec_Endpoint_Protection_14.3.0_RU1_Mac_Client_EN.zip

Symantec Endpoint Protection 14.3 RU1 – All Clients (344 MB)
https://dl.comss.org/download/Symantec_Endpoint_Protection_14.3.0_RU1_All_Clients_EN.zip

Symantec Endpoint Protection 14.3 RU1 – Full Installation (1.9 GB)
https://dl.comss.org/download/Symantec_Endpoint_Protection_14.3.0_RU1_Full_Installation_EN.exe

14.3_RU1_MP1

https://dl.comss.org/download/Symantec_Endpoint_Protection_14.3_RU1_MP1_Full_Installation_EN.exe

https://dl.comss.org/download/Symantec_Endpoint_Protection_14.3_RU1_MP1_Win64-bit_Client_EN.exe

14.3 RU2

Symantec Endpoint Protection 14.3 RU2 for Windows 64-bit
https://dl.comss.org/download/Symantec_Endpoint_Protection_14.3.0_RU2_Win64-bit_Client_EN.exe

Symantec Endpoint Protection 14.3 RU2 for MacOS
https://dl.comss.org/download/Symantec_Endpoint_Protection_14.3.0_RU2_Mac_Client_EN.zip

Symantec Endpoint Protection 14.3 RU2 – All Clients
https://dl.comss.org/download/Symantec_Endpoint_Protection_14.3.0_RU2_All_Clients_EN.zip

Symantec Endpoint Protection 14.3 RU2 – Full Installation
https://dl.comss.org/download/Symantec_Endpoint_Protection_14.3.0_RU2_Full_Installation_EN.exe

No More Ransom! 協助你一同對抗勒索病毒

https://www.nomoreransom.org/

 

 

近年來遭受勒索病毒(Ransomware)侵擾的機構層出不窮,其中不乏政府機關、醫院、學校或中小企業公司,甚至許多人的家用電腦都曾經中毒。一般來說,勒索病毒慣用手法是包裝在軟體或郵件附件,以其他格式偽裝,當使用者不小心執行後,它就會在電腦內進行部署,最終將所有檔案加密變成無法存取使用,跳出支付贖金來脅迫使用者取得解密金鑰恢復檔案,而且使用比特幣(Bitcoin)技術使嫌犯更難以被追蹤。

 

趨勢科技針對勒索軟體推出的免費復原工具 Trend Micro Ransomware File Decryptor,能有效對付某些類型勒索病毒,在不用支付贖金的情況下來強制重新復原救回檔案,這個工具目前支援包括 TeslaCrypt、CryptXXX、SNSLocker 等等在內共十多種勒索軟體類型。除此之外,本文要來介紹一個「No More Ransom」網站,一個勒索病毒主題入口網站,以專門對付勒索病毒為主,網站來頭不小,由 Intel Security、Interpol、荷蘭警方和卡巴斯基安全實驗室聯手打造!主要是協助使用者對抗危害,提供各種解密破解工具,讓使用者在不支付勒索贖金的情況下恢復重要文件檔案。

 

與其說 No More Ransom 是一個提供解密工具的網站,倒不如說他是一個教育使用者如何避免遇到勒索病毒危害的教育網站,內容簡單扼要一目了然,例如:備份資料、只打開認識且信任的聯絡人郵件附件、安裝防毒軟體、讓電腦軟體更新保持最新狀態,這些雖是老生常談,謹記在心準沒錯。

此外,No More Ransom 還提供線上勒索病毒檢測平台,使用者只要上傳自己被加密後的檔案,它就能從該組織擁有的 16 萬組解密金鑰中找出能夠解鎖的方式,還會讓你免費下載合適的復原工具,接下來我就簡單介紹一下 No More Ransom 這個網站的使用方法吧!

 

使用教學

STEP 1

開啟 No More Ransom! 網站後,首頁會直接詢問是否要協助你解鎖、復原你的檔案或文件,而不用支付給駭客贖金?點選 YES 後會進入檢測平台,如果點選 No 則會有一系列的防護安全資訊供使用者參考學習,不過目前僅有英文版。

 

STEP 2

No More Ransom! 的 Crypto Sherief 加密檔案自我檢測平台相當厲害,可能是目前網路唯一提供這項服務的網站!簡單來說,使用者只要點選左側兩個按鈕將被加密的任一兩個檔案選取、上傳,右側則是填入你在支付贖金頁面看到的 Email、網址,這部分需要確認無誤,以避免找不到可以解密的金鑰或工具,你也可以直接上傳勒索病毒留下來的訊息(.txt 或 .html 格式)。

最後,點選下方按鈕,No More Ransom! 就會找出可能可以解蜜、復原檔案的金鑰讓你免費下載,或者可能可以還原的免費工具。

 

STEP 3

在網站的 Decryption Tools 解密工具頁面,提供一系列可協助處理、還原或救援被勒索病毒加密後檔案的工具(CoinVault、RannohDecryptor、RakhniDecryptor、ShadeDecryptor),都有各自對應可以處理的勒索病毒副檔名格式。

不過在下載前請務必先閱讀使用說明,尤其要先確保勒索病毒已經從你的系統被完整移除,避免在解密後又被重新加密造成檔案損毀,任何可信賴的防毒軟體都能做到。

 

目前勒索軟體(勒索病毒)的數量相當多,而且不斷變種,有更多型態出現,現階段破解工具還無法涵蓋所有的勒索病毒,不過 No More Ransom! 網站提醒:盡量不支付贖金給這些病毒駭客,一來你會讓這些人認為有利可圖,進而找出更多方法來入侵其他使用者電腦;二來支付贖金獲取的解密金鑰也可能無法使用!讓你掉入被詐騙的陷阱當中。若你真的不幸中了勒索病毒,請記得先到 No More Ransom 網站找找解決辦法。

Tool for decrypting files affected by Trojan-Ransom.Win32.Rannoh infection

Tool for decrypting files affected by Trojan-Ransom.Win32.Rannoh infection

Back to “Virus-fighting utilities”

2016 May 24 ID: 8547

If the system is infected by a malicious program of the family Trojan-Ransom.Win32.Rannoh, Trojan-Ransom.Win32.AutoIt, Trojan-Ransom.Win32.Fury, Trojan-Ransom.Win32.CrybolaTrojan-Ransom.Win32.Cryakl or Trojan-Ransom.Win32.CryptXXX, all files on the computer will be encrypted in the following way:

  • In case of a Trojan-Ransom.Win32.Rannoh infection, file names and extensions will be changed according to the template locked-<original_name>.<four_random_letters>.
  • In case of a Trojan-Ransom.Win32.Cryakl infection, the tag {CRYPTENDBLACKDC} is added to the end of file names.
  • In case of a Trojan-Ransom.Win32.AutoIt infection, extensions will be changed according to the template<original_name>@<mail server>_.<random_set_of_characters>.
    Example: [email protected]_.RZWDTDIC.
  • In case of a Trojan-Ransom.Win32.CryptXXX infection, extensions will be changed according to the template<original_name>.crypt.

RannohDecryptor tool is designed to decrypt files dectypted by Trojan-Ransom.Win32.Rannoh, Trojan-Ransom.Win32.AutoIt,Trojan-Ransom.Win32.Fury, Trojan-Ransom.Win32.Crybola, Trojan-Ransom.Win32.Cryakl or Trojan-Ransom.Win32.CryptXXX versions 1 and 2 (files encrypted by Trojan-Ransom.Win32.CryptXXX version 3 are detected, but not decrypted).

 

Disinfection

To disinfect the system:

http://media.kaspersky.com/utilities/VirusUtilities/EN/rannohdecryptor.zip

  1. Download RannohDecryptor.zip. The following pages contain information on how to download the file.
  2. Run RannohDecryptor.exe on the infected computer.
  3. In the main window, click Start scan.

RD_8547_1

  1. Indicate path to one encrypted file and one not encrypted file.
    If the file is encrypted by Trojan-Ransom.Win32.CryptXXX, indicate the largest files. Only the files of this size or smaller ones will be decrypted.
  2. Wait until the files are found and decrypted.
  3. Reboot the computer, if needed.
  4. To delete copies of encrypted files named like locked-<original_name>.<four_random_letters> after a successful decryption, use the option Delete encrypted files after decryption.
Please note. If the file was encrypted by Trojan-Ransom.Win32.Cryakl, the tool will save the files with the extension.decryptedKLR.original_extension. If you select the option Delete encrypted files after decryption, the decrypted file will be saved under the original name.
  1. By default, the tool log is saved on system disk (the one with the operating system installed).Log file name is: UtilityName.Version_Date_Time_log.txt

    For example, C:\RannohDecryptor.1.1.0.0_02.05.2012_15.31.43_log.txt

If the system is encrypted by Trojan-Ransom.Win32.CryptXXX, the tool scans a limited number of files. If you have selected a file encrypted by CryptXXX v2, the encryption key restoration can take a rather long time. In this case the tool views the following message:

RD_8547_2

 

Command line options

-l <file_name> – create a log file with given name.

-y – close the window after decryption.

Symantec Endpoint Protection 12.1

这个可以理解为SCS的升级新一代版本,试用后感觉响应速度和PF占用都有了很大进步,使用symantec SAV或者SCS的朋友可以考虑更新到这个版本了。
中文名称:赛门铁克端点防护
Symantec Endpoint Protection V12.1简体中文版
英文名称:Symantec_Endpoint_Protection 12.1

版本:官方最新发布
发行时间:2011年

制作发行:Symantec
地区:中国大陆
语言:简体中文
[安装测试] 在WindowsXP SP2 SP3中文版Windows 7 中文版安装测试通过,因我没有该系统

[版权声明]资源版权归原作者及其公司所有,如果你喜欢,请购买正版。

简介:
Symantec Endpoint Protection将Symantec AntiVirus与高级威胁防御功能相结合,可以为笔记本、台式机和服务器提供无与伦比的恶意软件防护能力。 它在一个代{过}{滤}理和管理控制台中无缝集成了基本安全技术,从而不仅提高了防护能力,而且还有助于降低总拥有成本。

主要功能
* 无缝集成一些基本技术,如防病毒、反间谍软件、防火墙、入侵防御和设备控制。
* 只需要一个代{过}{滤}理,通过一个管理控制台即可进行管理。
* 由端点安全领域的市场领导者提供无可匹敌的端点防护。
* 无需对每个端点额外部署软件即可立即进行 NAC 升级。

主要优势
* 阻截恶意软件,如病毒、蠕虫、特洛伊木马、间谍软件、恶意软件、bot、零日威胁和 rootkit。
* 防止安全违规事件的发生,从而降低管理开销。
* 降低保障端点安全的总拥有成本。

新功能

单个代{过}{滤}理和单个控制台
为所有 Symantec Endpoint Protection 技术和 Symantec Network Access Control 提供一个代{过}{滤}理。 为管理所有 Symantec Endpoint Protection 技术和 Symantec Network Access Control 提供一个集成的界面。 允许对所有技术采用一种通信方法和一个内容交付系统。
* 提供了出色的操作效能,如单个软件更新、单个策略更新等。
* 提供了统一的集中报告。
* 提供了统一的授权许可和维护。
* 添加 Symantec Network Access Control 实施功能时不需要对客户端进行更改。
* 降低保障端点安全的总拥有成本。
* 降低了管理工作量。

主动威胁扫描
基于行为的防护,可以防御零日威胁和前所未见的威胁。 与其它启发式技术不同,主动威胁扫描可以对未知应用程序的行为好坏进行分类,从而提供了更精确的恶意软件检测。
* 无需设置基于规则的配置即可准确检测恶意软件。
* 有助于降低误报数量。

高级 Rootkit 检测和删除功能
通过集成 VxMS(Veritas 映射服务,Veritas 的一种技术)提供了出色的 rootkit 检测和删除功能,从而可以访问操作系统底层,进行全面分析和修复。
* 检测并删除最难以处理的 rootkit。
* 无需对受感染的计算机重新制作映像,因此节省了时间和金钱,同时防止工作效率下降。

应用程序控制
允许管理员控制用户和其它应用程序访问特定进程、文件和文件夹。 它提供了应用程序分析、进程控制、文集和注册表访问控制,以及模块和 DLL 控制。 它使管理员能够限制某些被视为可疑或高风险类型的活动。
* 防止恶意软件传播或破坏端点。
* 锁定端点,防止数据泄漏。

设备控制
控制可以连接到计算机的外设以及这些外设的使用方式。 它可以锁定一个端点,阻止其与拇指驱动器、CD 刻录机、打印机和其它 USB 设备相连。
* 防止敏感的机密信息从端点被提取或窃取(数据泄漏)。
* 防止端点被通过外设传播的病毒感染。

系统要求
Symantec Endpoint Protection 客户端(32 位)
最低要求
* Windows 2000 SP3+、Windows XP、Windows Server 2003、Windows Vista (x86)
* Pentium III 300 MHz(Windows Vista 需要 1GHz)
* 256 MB 内存
* 180 MB 磁盘(安装期间额外需要 440 MB)

Symantec Endpoint Protection 客户端(64 位)
最低要求
* Windows XP Professional (x64) SP1+、Windows Server 2003 (x64)、Windows Vista (x64)
* 1 GHz,采用以下处理器之一:具有 Intel EM64T 支持的 Intel Xeon、具有 EM64T 支持的 Intel Pentium IV、AMD 64 位 Opteron、AMD 64 位 Athlon(注意:不支持 Itanium)
* 256 MB 内存
* 180 MB 磁盘(安装期间额外需要 440 MB)

Symantec AntiVirus for Linux 客户端
支持的 Linux 分发:Red Hat Enterprise Linux、SuSE Linux Enterprise(服务器/台式机)、Novell Open Enterprise Server、VMWare ESX
Symantec Endpoint Protection Manager
中央管理服务器
最低要求
* Windows XP Professional SP2;Windows Server 2003 Standard/Enterprise
* Microsoft Internet Information Services(Web 服务器)
* Microsoft SQL Server 2000 SP3 或 SQL Server 2005(可选)
* 2GB 内存
* 1GB 可用磁盘空间

Symantec Endpoint Protection 控制台
远程管理控制台(可选)
最低要求
* Windows XP Professional;Windows Server 2003 Standard 或 Enterprise;Windows 2000 Professional/Server/Advanced Server
* Sun Java Runtime Environment (JRE) 1.5
* Microsoft Internet Explorer 6.0 SP2
* 512 MB 内存

Symantec? Endpoint Protection combines Symantec AntiVirus? with advanced threat prevention in a single agent delivering unmatched defense against malware for laptops, desktops and servers.

Features:
– Seamlessly integrates essential technologies such as antivirus, antispyware, firewall, intrusion prevention, device control
– Requires only a single agent and managed by a single management console
– Unmatched endpoint protection from a proven, market leading endpoint security vendor
– Each endpoint comes “SNAC-ready” (Symantec Network Access Control)(Optional purchase), enabling instant upgrade without additional software deployment on the endpoints

Benefits:
– Stops malware and such as viruses, worms, trojans, spyware, adware and rootkits
– Helps prevent security outbreaks
– Lowers TCO for endpoint security
– Reduces administrative effort

产品资料:
http://www.symantec.com/content/zh/cn/ente…n-us.pdf
官网:
http://edm.symantec.com/endpointsecurity/



官方下载地址 注:简体中文版
第一张
http://esdownload.symantec.com/akdlm/CD/MTV/Symantec_Endpoint_Protection_12.1_Win32-bit_Client_CS.exe
内容:
SEP客户端32位

第二张
http://esdownload.symantec.com/akdlm/CD/MTV/Symantec_Endpoint_Protection_12.1_Win64-bit_Client_CS.exe
内容:
SEP客户端64位

第三张[个人用户不必下载]
http://esdownload.symantec.com/akdlm/CD/MTV/Symantec_Endpoint_Protection_12.1_Full_CS.exe
内容:
服务端包含客户端

以上是简体版,为了方便各位网友以下是英文版
英文版32位客户端http://esdownload.symantec.com/akdlm/CD/MTV/Symantec_Endpoint_Protection_12.1_Win32-bit_Client_EN.exe
英文版64位客户端
http://esdownload.symantec.com/akdlm/CD/MTV/Symantec_Endpoint_Protection_12.1_Win64-bit_Client_EN.exe

英文版服务端包含客户端
http://esdownload.symantec.com/akdlm/CD/MTV/Symantec_Endpoint_Protection_12.1_Full_CS.exe