Skip to content

IDS deployment

Jump to bottom
Stefan Schneider edited this page Nov 27, 2019 · 57 revisions

Deploying NS2 along with the IDS

NS2 + IDS artifacts:

The goal now is to add a security barrier to NS2 in order to be able to identify an attack and protect NS2 against that threat. The original NS2 was built of MDC + EAE + CC. The extended NS2 added SELK (Suricata/Filebeat + Logstash + Elasticsearch + Kibana) as shown in the picture.

NS2 MDC with eIDS

The extended NS2 offers two ways of deployment:

  • a TNG package for SP onboarding and deployment
  • a K8s deployment directory for manual deployment to a k8s cluster

Deployment and on-boarding on Tango SP

Packaging

Package NS2 with the IDS (requires tng-sdk-package to be installed):

cd tng-industrial-pilot/sdk-projects
tng-pkg -p tng-smpilot-ns2-k8s-eids

If it fails, it's probably due to errors in the validation. You can check these again separately:

tng-validate --project tng-smpilot-ns2-k8s-eids

If needed validation can be skipped with:

tng-pkg --skip-validation -p tng-smpilot-ns2-k8s-eids

On-boarding

$ tng-cli package -u eu.5gtango.tng-smp-ns2-k8s-mdc-eids.0.4.tgo

Onboard the package alternative

$ curl -X POST http://int-sp-ath.5gtango.eu:32002/api/v3/packages -F "package=@./eu.5gtango.tng-smp-ns2-k8s-mdc-eids.0.4.tgo" -vvv -H 'content-type:multipart/form-data'

You can confirm that the '.tgo' package is onboarded to the SP with:

$ curl  http://int-sp-ath.5gtango.eu:32002/api/v3/packages

Instantiation

NS2 needs to be instantiated using instantiation parameters that set the connection to NS1 and that configure the IDS rules. This is currently only possible with tng-cli, not with the portal.

  • Locally open sdk-projects/inst_params_ns2.yml and set all parameters to the desired values.

    • Set the MQTT_BROKER_HOST to the floating IP of NS1
    • In case of an intrusion, the MDC is reconfigured and sends traffic to an quarantine instance of NS1 with the IP address specified in QUARANTINE_MQTT_BROKER_HOST.
    • The default username and hostname of the IMMS are Alice and IMMS, which are configured by default. So you do not need to change them. (If you do, always specify the hostname in CAPITAL LETTERS. Background: Samba converts user and hostname to capitals before comparing them against the filter.)

  • Get the service UUID of the on-boarded NS2 from the portal by clicking on the service name. The UUID is displayed in the top left corner.

  • Instantiate NS2 with the instantiation parameters:

    # run from within the sdk-projects directory
# -n specifies the instance name and can be set to whatever (or omitted)
tng-cli service -n sm-ns2 --params_file inst_params_ns2.yml -i <ns2_service_uuid>

The NS2 service should be running after a few moments.

Accessing the Kibana Dashboard

  • Get the external IP address of Kibana with the SP (Open the instance and extend the k-vnf4 riter -> External_IP)

  • Kibana is set to its default port 5601, so you can access Kibana with your browser external-ip:5601.

  • Initially the logs should be empty since no alarm was detected yet

Trigger an alarm

  • Get the floating IP of the NS2 MDC through the portal by clicking the NS2 instance and there on the "msf-vnf1" CDU
  • Use smbclient -L <external-IP> to connect to the MDC.
    • If the user and hostname do not match the allowed one specified during instantiation, this should trigger an alarm that is logged and visible in Kibana.
    • If both user and hostname match, no alarm/log should be visible
    • With the -U flag, you can define a different user for smb
  • You can also trigger an alarm by connecting an IMMS that doesn't match the username and hostname. Eg:
docker run -d --rm -p 15001:15001 --name vnf-dt -e DT_EM63_SHARE_HOST=<NS2-MDC-floating-IP> -e DT_EM63_USERNAME=Eve sonatanfv/vnf-dt:latest

Alternatively, you can manually trigger a reconfiguration without any intrusion: https://github.com/sonata-nfv/tng-industrial-pilot/wiki/FSM-SSM-Development

Manual deployment to a k8s cluster

Instantiation

Start NS with the extended IDS with ELK:

cd tng-industrial-pilot/k8s
kubectl apply -f ns2-e-ids-v2

To check the Enhanced IDS deployment, use the kubectl command line tool to verify that IDS and ELK are running:

# check for correct pod name
$ kubectl get po
NAME                             READY   STATUS    RESTARTS   AGE
elasticsearch-6d8497ff6c-qjpxj   1/1     Running   0          47m
kibana-7c9bf5bcc4-5zpv7          1/1     Running   0          47m
logstash-74977795cd-m2ksr        2/2     Running   0          47m
ns2-mdc-sf-7b4c6965f9-hzjwk      3/3     Running   2          47m

# display logs
$ kubectl logs ns2-mdc-sf-7b4c6965f9-hzjwk suricata
25/7/2019 -- 13:14:00 - <Notice> - This is Suricata version 4.1.2 RELEASE
25/7/2019 -- 13:14:00 - <Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /var/lib/suricata/rules/suricata.rules
25/7/2019 -- 13:14:00 - <Warning> - [ERRCODE: SC_ERR_NO_RULES_LOADED(43)] - 1 rule files specified, but no rule was loaded at all!
25/7/2019 -- 13:14:00 - <Warning> - [ERRCODE: SC_ERR_SYSCALL(50)] - Failure when trying to set feature via ioctl for 'eth0': Operation not permitted (1)
25/7/2019 -- 13:14:00 - <Warning> - [ERRCODE: SC_ERR_SYSCALL(50)] - Failure when trying to set feature via ioctl for 'eth0': Operation not permitted (1)
25/7/2019 -- 13:14:00 - <Warning> - [ERRCODE: SC_ERR_SYSCALL(50)] - Failure when trying to set feature via ioctl for 'eth0': Operation not permitted (1)
25/7/2019 -- 13:14:00 - <Warning> - [ERRCODE: SC_ERR_SYSCALL(50)] - Failure when trying to set feature via ioctl for 'eth0': Operation not permitted (1)
25/7/2019 -- 13:14:00 - <Notice> - all 16 packet processing threads, 4 management threads initialized, engine started.

Just ignore these warnings. Instead, log into the IDS container and check the Suricata logs there :

# log into suricata
$ kubectl exec ns2-mdc-sf-7b4c6965f9-hzjwk -c suricata -it bash
# display logs
[root@ns2-mdc-sf /] cd var/log/suricata/
[root@ns2-mdc-sf suricata] ls
eve.json  fast.log  stats.log  suricata.log
[root@ns2-mdc-sf suricata] tail eve.json
{"timestamp":"2019-07-25T14:04:12.995573+0000","flow_id":182152630907125,"in_iface":"eth0","event_type":"dns","src_ip":"10.1.1.131","src_port":37641,"dest_ip":"10.152.183.10","dest_port":53,"proto":"UDP","dns":{"type":"query","id":63893,"rrname":"ns1-cc-service.cluster.local","rrtype":"A","tx_id":0}}
{"timestamp":"2019-07-25T14:04:12.995613+0000","flow_id":182152630907125,"in_iface":"eth0","event_type":"dns","src_ip":"10.1.1.131","src_port":37641,"dest_ip":"10.152.183.10","dest_port":53,"proto":"UDP","dns":{"type":"query","id":2526,"rrname":"ns1-cc-service.cluster.local","rrtype":"AAAA","tx_id":1}}
...

eve.json contains all logs and info collected by Suricata. Most of the data is irrelevant for Tango, but it shows that Suricata is working.

Display Kibana log dashboard

# get the external IP address of Kibana visualizer
$ kubectl get svc | grep kibana
kibana          LoadBalancer   10.152.183.206   10.1.1.2      5601:31526/TCP                              53m

Finally, point your browser to the Kibana URL: http://<KIBANA_IPADDR>:5601. Alternative: <IP of your host>:<external port (here 31526)>.

In the Kibana dashboard, click on "Logs" to see all relevant logs. The logs section should show only detected intrusions and should initially be empty.

Triggering an alarm

Concept:

  • Alarms are triggered based on the user and hostname of the machine that connects to the shared Samba folder. (Check username with echo $USER and hostname with hostname.)
  • Inside lh.yaml it is specified via an environmental variable, which user and hostname is allowed
env:
    - name: SMB_CLIENT_NAME
      value: "K8PRDCTRL1"		# this should be set to the desired hostname
    - name: SMB_USER_NAME
      value: "stefan"                   # and this to the desired user name
  • If a Samba client from another user or hostname tries to connect, an intrusion is detected and logged

Trigger alarm:

  • Get external IP of MDC
  • On machine with allowed user and hostname do smbclient -L <external-IP-of-mdc>. This should be fine and not trigger an alarm. smbclient will ask for a password, which you can leave blank.
  • Try the same thing on a machine with a different user or hostname. Now an alarm should be triggered and an entry should be visible in the Kibana logs
Clone this wiki locally