Tag: alienvault (Page 2 of 5)

Alienvault USM – Flat File Log Capture – Part 1

We’ve been working with and on Alienvault since the beginning of 2016 and a lot has changed since then. When we started out with Alienvault, they were a small-ish company still, with big ambitions, working with a very technical group out of Cork, Ireland. We had direct access to their technical team (I think even to one engineer) and the amount of knowledge we got from those early days are pretty much invaluable to where we are right now. Of course, Alienvault has changed a lot since then, and now being part of AT&T – for the record, we believe they have the right roadmap to go into cloud with their USM Anywhere concept, and their product right now is much more robust and enterprise ready. They are on the right trajectory.

However, back in the days, for Alienvault USM Appliance (not Anywhere), which is their Appliance offering, we could literally ‘jailbreak’ the system and go into the underlying OS and do stuff to Alienvault that we can’t do anymore in Anywhere. Some of the changes we made were to increase optimisation, put in our own scripts to clean up the system, troubleshoot the system and of course, create plugins for custom applications. We would write custom plugins in 1 – 2 days for multiple applications because of deadlines, I remember and had to do so much in so little time – but we did it anyway. We had to write a plugin for one of the oldest mainframes for a financial institution that was so difficult to interpret, we had to dig up old manuals to sort out the entries for log and events. It was like we were interpreting Egyptian hieroglyphs. But that’s what it took – 2 days, I think because of compliance requirements and customer breathing down our neck to get it done.

Writing plugins was the easier part of the battle – in some old machines or legacy applications, getting the logs was the problem. If Alienvault doesn’t get the logs, it can’t do anything with it. One solution was to leverage on the HIDs (Host IDS), or OSSEC as it was known, to grab log files from systems. It wasn’t so elegant, and we still had to end up writing plugins for it to normalise, but it resolve the issue where application was not able to forward logs to the SIEM, or not able to write the logs to the Windows Event service, or any other way to get logs out to a syslogger. So the solution here is for the application to just write the logs to a file, and Alienvault go ahead and grab this and interpret it. It may not be real time, but it works.

There’s a good write up over in Alienvault at
https://www.alienvault.com/documentation/usm-appliance/ids-configuration/process-reading-log-file-with-hids-agent-windows.htm. So a lot of it is just a repeat and probably an exposition on why we are doing certain things in a certain way.

So the first thing to do here is to ensure that you are able to install HIDs on the server. HIDs will be the key to get this file out to Alienvault. Technically, you could actually use NXLog as well but let’s explore that another time.

Once HIDs is installed, get into the ossec configuration file to define the <localfile> location. Now assuming that you have configured your application to write to a flat file called database.log.txt.

Go ahead and restart OSSEC. That’s pretty much what you need to do to start off so it’s pretty simple.

The rest of it is all done on Alienvault.

To summarise the steps:

Enable “logall” on your USM Appliance. You want to dump whatever you are getting in that flat file database log to a log inside your Alienvault so you can start doing stuff to it. In this case, in your AV User Interface:

Environment > Detection > HIDS > Config > Configuration.

Add <logall>yes</logall> to the <global> section of the file .

You are dumping these logs into /var/ossec/logs/archives/archives.log.

Restart the HIDs service through UI.

You should be able to see new logs coming into archives.log. Just do a tail -f on it, edit the log file (database.log.txt) in your remote system (just write something on it) and see if it appears in your archives.log. Once you see it, you are almost done. Very simple.

So for now, you have customised logs coming into your Alienvault. The next thing to do is to interpret these logs and make sure events are able to be derived from these logs to something that is useful to you!

Drop us an email at alienvault@pkfmalaysia.com for more information on Alienvault or any technical queries you have, and we will attend to it.

Alienvault: File Integrity Monitoring on Linux Part 2

So based on our previous article you have so far set up OSSEC (or HIDS in Alien-speak) in your Linux host which you want to monitor. The next thing to do is to configure FIM to work.

To recap, we have a running CENTOS7 system running in our lab and we finally got our ossec to be communicating with the Alienvault server. You can verify connectivity either through the CLI logs, or using the USM Interface. Now the HIDS can be used for a lot of things – it’s obviously a Host IDS (hence the name), but it’s also a log forwarder as well, so for Linux systems, it doubles up as a security logger, so you don’t need to configure separate plugins to log, for instance SSH denied attempts. If you don’t have the HIDS, you have to forward logs from rsyslog then setup Alienvault plugin for SSH to normalise SSH logs and create those events. HIDS does this for you. Try it. You can attempt multiple logins with wrong password and you should see an event called “SSHD Authentication Failed.”

But for this article, we will be focusing on File Integrity Monitoring or FIM for short. FIM in Alienvault USM is utilising OSSEC inbuilt integrity checking process called Syscheck. Syscheck runs periodically and depending on how many files/directories it is checking can run from 10 minutes to much longer. By default, syscheck in Alienvault executes very 20 hours – if that’s too long for you , you can shorten it in the configuration.

Let’s jump straight in.

In Alienvault (Server if you are using Standard), go Environment -> Detection and on HIDS tab, click on Agent. In the lower tabs, click on SYSCHECKS.

Over here is where you configure the Syschecks on the Agents and you can modify the frequency.

Because we are using Linux, we are going to ignore the portion where Windows Registry is being configured and go straight to: ”

FILES/DIRECTORIES MONITORED

Under files/Directories, put in a sample directory you need to monitor, for instance

/etc/pkf

Don’t worry, out of the box, standard directories being monitored are

/etc

/usr/bin

/usr/sbin

/bin

/sbin

We have in some cases clients insisting on us putting in /var/log in there to inform them of changes occurring in this directory. According to them, log files are key and they need to know if these log files are being changed.

Um, yes. Agree on the first part. But /var/log changes almost every nanosecond. Syscheck is not going to be of much use here. They are probably thinking about log archives as opposed to the current log folder. Anyway, we digress.

So go ahead and put in your own directory in there under agents and then restart HIDS from Alienvault, and also for good measure restart the agent as well (you can go Agent Control -> Click on the clock symbol under the Agent Name to restart). To check, you can click on Agent.Conf tab and you will find something similar to:

<agent_config>
    <syscheck>
      <frequency>1200</frequency>
      <auto_ignore>no</auto_ignore>
      <alert_new_files>yes</alert_new_files>
      <scan_on_start>yes</scan_on_start>
<directories realtime="yes" report_changes="yes" check_all="yes">/etc/pkf</directories>
    </syscheck>
  </agent_config>

So it looks all set up. If you have restarted HIDS and also the agent, you should be able to verify on the agent itself if the configuration has been uploaded. On the client, go to

/var/ossec/etc/shared

Look into agent.conf file and you should be able to see the same thing as the configuration above. Also, you can go to

/var/ossec/logs

and look into ossec.log file and you should be able to see something like

ossec-syscheckd: INFO: Monitoring directory: '/etc/pkf'.
ossec-syscheckd: INFO: Directory set for real time monitoring: '/etc/pkf'.

So there you have it. You can do some testing now.

So we will go into the local directory of our CENTOS and go ahead to create a few random files. The first thing you notice is that even if in our config there was:

<alert_new_files>yes</alert_new_files>

We still do not get any alerts once we create new files in the directory. This is because OSSEC doesn’t check new files in realtime (just changes to files), and we will need to wait for our syscheck to run, or you can go ahead and restart the agent from the Alienvault GUI. For good measure, change a few things about the files as well.

You might notice a strange thing happening here.

Going into the SIEM, you might not find any events relating to integrity issues in your host. This doesn’t seem to be an isolated incident, if you head over to the Alienvault forum, you will see many people having the same issue: We have enabled FIM and we can’t find anything on the SIEM or any events!

If you check on the agent itself, and you click on the “modified files”

You will see a raw list of all the files modified and you will see that /etc/pkf/filename is there listed as well, so it means OSSEC is working and syscheck is working. Another way to verify is to head over to your Alienvault Server and go to

/var/ossec/logs/alerts 

grep pkf alerts.log

Basically I am doing a grep on anything that identifies the files or directories I am looking at to see if alerts are generated. You should change the grep to something related to your filename/directory name. You should be able to see that alerts are generated.

So what gives?

Plugins.

Apparently for some strange reason, some Alienvault setup by default does not have the proper plugins enabled to read the integrity alerts log of ossec. This is very strange, as FIM is touted as a feature for Alienvault, but we need to still work further to get it up and running. So go ahead to your Alienvault GUI:

Configuration -> Deployment

Click on System Detail of your Alienvault setup

Click on Sensor Configuration in the menu on the right side

Go to “Collection”

You notice you have Alienvault_HIDS and Alienvault_NIDS enabled. However, in some cases, Alienvault_HIDS-IDM plugin might be missing and can’t be found under “Plugins Available” column. IDM Is for identity management and it needs to be enabled for FIM to properly work.

The plugin that makes this happen is

ossec-idm-single-line.cfg

In our case, the plugin file was there in /etc/ossim/agent/plugins, but it wasn’t in the ossim database as a “Plugins Available” option. This generally means that it wasn’t (for some reason) written into the ossim-db. So head over to the directory in Alienvault:

/usr/share/doc/ossim-mysql/contrib/plugins

You will see that there is an ossec.sql.gz in there, so go ahead and unzip it and run

cat ossec.sql | ossim-db

alienvault-reconfig

Wait for the reconfig to occur then head back to the GUI of Alienvault, all the way back to the sensor configuration->collection and you will be able to see Alienvault_HIDS-IDM available for selection.

Go ahead and select it there, and then reconfig and now you can try to run the FIM test again.

a) Create a new file

b) Restart the agent (to simulate the syscheck being run)

c) Check SIEM , filter Data Sources to Alienvault HIDS, you should find

AlienVault HIDS: File added to the system.

d) Go to the host and edit the new file and change it

e) Go back and check SIEM and you will find

AlienVault HIDS: Integrity checksum changed.

The last event should be immediate and need not have any restart of the agent. Unless of course, we noticed if the change occurred during the time syscheck is running, if so the event will occur once syscheck finishes. It’s not perfect, but it will have to do.

Congratulations, you have FIM events up and running for Alienvault! If you need further assistance in any Alienvault matters, drop us an email at alienvault@pkfmalaysia.com and we will look into it.

 

Alienvault: File Integrity Monitoring on Linux Part 1

If you have been deploying or troubleshooting Alienvault long enough, you would know a few things: Alienvault is one of the most flexible SIEMs in the market. It has the most varied security features, and covers almost the entire spectrum of our PCI-DSS needs – from IDS, to SIEM, to File Integrity Monitoring, to vulnerability scaring to a partridge in a pear tree.

One of the products working under the Alienvault hood is OSSEC, which is a opensorce host based IDS. Sometimes, its interchangeable to HIDS, which is Host IDS, but really, the latter is simply the type; while the former is the actual name itself. For the sake of this article, we will interchange both terms.

OSSEC runs well with Windows, where Alienvault can do an auto deployment given the correct setup and credentials. However, it’s on Linux boxes that sometimes we get a bit concerned. Not because the product doesn’t work, but simply because the setting up of the installation. There is no auto deployment, so we need to set it up manually, and this might mean downloading the correct packages in the first place.

After this, we are going to look at a specific function of HIDS – File Integrity Monitoring or FIM for short.

Firstly, let’s get started. We have set up a simple CentOS 7 box in our lab in the same network as Alienvault, and we are going to install HIDS on this box as an AGENT. This will then talk to the Alienvault USM which is the server.

So let’s assume you have your agent system network setup (please ensure your DNS is set properly, you should be able to work this out in CentOS 7 either through the network tools or editing resolv.conf).

 yum groupinstall "Development Tools" -y

The CentOS development tools are very useful tools which is a bundle, used primarily for building and compiling software from source code. “Yum” here while making you think of going for a teh tarik is a command found in almost all red-hat based distros to run installations. It’s used for update, installations etc. In the old days before YUM, we would use RPM (which is really what YUM is using), but we would have to manually track down dependencies and it really sucks because to install an RPM package might mean to install a whole bunch of stupid libraries or updating stuff and you are basically running around the internet looking for RPMs like Where’s Wally. It looks awful now, but back in the days, RPM was heavensent. We didn’t need to do “tar”, configure, make, “make install” anymore!

Anyway, the -y argument behind simply automates the command by answering yes to the prompts. So once you run that, fingers crossed, everything runs ok and you get

Complete!

Which means everything is ok.

The next is to get the kernel-devel package.

yum install kernel-devel -y

This is a package that allows us to install a kernel driver later. It’s not the full kernel source, so it shouldn’t take too long before you see the “complete!”.

At this point you are ready to install OSSEC. If there are any issues, then troubleshooting is obviously required.

First, we need to locate the version of HIDS that can work with Alienvault. You might think heading to the latest HIDS in https://ossec.github.io/downloads.html might be the answer, but for Alienvault, we would recommend to get the 2.8.3 version. You can find it here:

https://bintray.com/ossec/ossec-hids/download_file?file_path=ossec-hids-2.8.3.tar.gz

So, go to a installation directory (optional) like /usr/src and run

curl -OL https://bintray.com/ossec/ossec-hids/download_file?file_path=ossec-hids-2.8.3.tar.gz

We used curl here because for some reason wget wasn’t installed. the -OL is supposed to handle the redirected links for that particular site and supposedly to rename it to a proper remote file name. It doesn’t do the rename though (don’t know?) and we wind up with a file called “download_file?file_path=ossec-hids-2.8.3.tar.gz”. Just rename it if you are into aesthetics to ossec-hids-2.8.3.tar.gz.

So now lets do an extraction

tar –xzvf ossec-hids-2.8.3.tar.gz

We now have a folder called ossec-hids-2.8.3. Go into this folder and then run

./install.sh

Once you run, you will be given a series of questions. Default should be fine for most, and you should just select ‘agent’ and also key in the server (Alienvault) IP address. Now if you are running a separate Alienvault setup (non-AIO), then this IP address is actually the address of your SENSOR. Not Alienvault Server. So don’t get mixed up. The Sensor is the Server. Hm.

So everything ready, fingers crossed, just go ahead and install. There will be a lot of text filling your screen but the important thing is that there is no ERROR or WARNING (well warning ain’t bad), but at the end you should have a welcome note stating

 Thanks for using the OSSEC HIDS.
 If you have any question, suggestion or if you find any bug, contact us 
at contact@ossec.net or using our public maillist at ossec-list@ossec.net 
(http://www.ossec.net/main/support/ ).

Press enter and you should be out of the installation. Congratulations!

You are not done yet. You still need to get Alienvault to talk to your box. The steps are as follows:

a) Generate an Agent Key from Alienvault

Go to your Alienvault AIO or your Server (since a standard sensor has no GUI, remember?).

Environment->Detection->Agents

Click “Add Agent”

Select the host from the list (It should be there automatically, but if it’s not just add it there through the asset list).

So now the agent has been created but you should see it as “Disconnected” from the list. Click the little Key sign that says “Extract Key”.

You should see something like

Agent key information for '2' is:

MiBIb3N0LTE5Mi0xNjgtMC01MCAxOTIuMTY4LjAuNTAgMDBmYzI0MzUyNzg4N.....etc
The garbled message is the key. So go ahead and highlight and copy it.

b) Import the key into the agent system

Go back to your agent system and head over to /var/ossec/bin and run

./manage-agents

Type in ‘I’ to import

Paste the whole key into the screen and confirm adding it.

Quit and then restart by going

/var/ossec/bin

And

./ossec-control restart

c) Restarting HIDS on the server

On the server head over to

Environment->Detection->HIDS Control

On the right side, click “Restart” the HIDS and you should be fine.

d) Check the Agent Logs

Head back to the agent system and check the logs

cd /var/ossec/logs
more ossec.log

You should (hopefully!) see

INFO: Connected to the server (192.168.0.xxx:1514).

where xxx is your server IP address.

Back in the USM server you will be able to see that now the agent is “Active”.

In the next article we will see if we can get the FIM to work.

Tonight, I Wanna Cry

There is a country song that goes:

I’ve never been the kind to ever let my feelings show,
And I thought that being strong meant never losin’ your self control
But I’m just drunk enough, to let go of my pain,
To hell with my pride, let it fall like rain, from my eyes,
Tonight I wanna cry.

And cry they did. Almost 75,000 and counting, over 99 countries hit by one of the largest ransomware attacks of all time, “WannaCry” and the other Wanna* variants.

Wannacry was released on the 12th of May 2017. The irony of it all was that we were invited as one of the speakers in a Ransomware event in Putrajaya under Panda Security the day before and we were just warning those in attendance that the next wave of ransomware is due to hit and within 24 hours, bam, we have Wannacry. In Malaysia, there seems to be already infection, thanks to the guys at

https://intel.malwaretech.com/botnet/wcrypt/?t=24h&bid=all

There have been reports of large telecommunication companies, banks and telcos are being affected. Tens of thousands of networks worldwide have been hit and the attacks do not appear to be targeted to any specific region or industry. Once infected, victims are asked to pay approximately $300 by Bitcoin. For the curious, you can check

https://bitref.com/13AM4VW2dhxYgXeQepoHkHSQuy6NgaEb94

This means there is around 5.8348 bitcoins paid already to this. Which translates to around RM46,000 paid so far – which isn’t so much if you think the average of ransom payment is around RM10,000 – RM11,000 for other ransoms.

So what is this?

Wannacry is using the file extension .wncry, and it also deletes the Shadow Copies (which is normal for ransomwares, like Locky) which is a technology introduced into the Microsoft platforms as far back as Windows XP and Windows Vista as the Volume Shadow Copy service. This means that even backup copies produced by this service, such as Windows Backup and System Restore will be screwed. That’s mean. Here is the command executed.

cmd.exe /c vssadmin delete shadows /all /quiet & wmic shadowcopy delete & bcdedit /set {default} bootstatuspolicy ignoreallfailures & bcdedit /set {default} recoveryenabled no & wbadmin delete catalog -quiet (PID: 2292)

The following file is also created in the affected systems: @Please_Read_Me@.txt

How it gets in is just like any other ransomware: email either phishing or spear phshing. Basically, don’t click on any email attachments that are suspicious! It’s easier said than done, especially if you see one coming in stating that you are behind in your payments for your credit card. Resist the urge. One of the things to check on email:

The return email – most phishing doesn’t even attempt to spoof their email, and you will get emails coming from strange domains like maaybank or clmbclicks. Bad language is also a hallmark of a phishing email. “All your base are belong to us” type of english. Anyone asking for passwords, or click on a link etc is nonsense. Don’t click on email links. Don’t click on the attachments, above all.

Back to Wannacry. It exploits a known Microsoft Windows vulnerability to spread. This vulnerability was released as part of the Shadow Brokers leaks back in April. It hits the SMB (Server Message Block) – some people pronounce it as SAMBA, which technically is not so correct, as SAMBA is the SMB implementation on Linux. It basically allows the sharing of files and printers in networked environment. Which means, if one gets infected, the infection spreads through network shares even to systems without connectivity to the internet.

Microsoft released a patch for MS17-010 on March 14th 2017. Obviously, a lot of systems – especially those in healthcare still runs on Windows XP. The case has been deemed so serious that Microsoft has taken the step to release patches for systems already dead like XP! This shows how unusually dangerous this ransomware is.

OK, so if you have been hit, what do you do?

Well, you can pay. Around 41 transactions have been made so you could make the number, but don’t expect too much out of it. In fact, we probably do not recommend this course of action. You need to remove Wannacry and there are plenty of sites that gives details on that. The problem with ransomware is not so much of removing it, its a matter of recovering your files. Here’s a site you can check if there is a decryptor available:

https://www.nomoreransom.org/crypto-sheriff.php

Please be careful – some so called ‘decryptors’ are disguised as further malware and gets you a double whammy of sorts, so you need to ensure these are proper tools and not something you download from torrent.

As an advisory to all our clients, especially PCI-DSS here’s what you can do to protect yourself:

a) PATCH

https://technet.microsoft.com/en-us/library/security/ms17-010.aspx

Now we see how important it is to patch your systems. Most PCI clients struggle on this and the examples can come from: Our servers are not connected to the internet, or If I patch, my application breaks. Well, if your application breaks then you need to get a warranty from your developers or get them to upgrade and improve.

b) Backup

While PCI doesn’t really focus much on backup or BCP (after all PCI’s interest is in the confidentiality of credit card and not the availability of your business) – it’s still good practice to backup your system. And not just online as ransomware hits shadow copies firstly – but offline backup and ensure your restoration has been tested. Remember those grandfather-father-son backup scheme you learnt in college and university? Yup, it can be applied.

c) Antivirus and Antimalware Updates

While it’s known Antivirus is missing a chunk of malware out there, it’s still for many systems the last line of defence and most vendors have released protection signatures for the ransomware so get it updated. It’s like having the final militia protecting against an invasion. It will probably not hold out forever, but at least it buys your administrators some time.

d) Remove SMB v1 support

https://support.microsoft.com/en-us/help/2696547/how-to-enable-and-disable-smbv1,-smbv2,-and-smbv3-in-windows-vista,-windows-server-2008,-windows-7,-windows-server-2008-r2,-windows-8,-and-windows-server-2012

Simply, for Windows 8 for instance, you need to run Powershell in administrator mode and then just issue

Set-SmbServerConfiguration -EnableSMB1Protocol $false

to disable SMBv1

e) Network segmentation

While this is helpful, it still doesn’t save everyone. Segmentation helps because it isolates computers. Vector of attacks usually comes into the access network (where end users access) and if you segment this from the critical systems, you will need the malware to traverse through your firewall or a filtering device in between which leads us to:

f) IDS, SIEM, IPS or any protection systems you have!

If you don’t have any IDS, IPS or SIEM deployed in your environment, it’s time you get one and this is a good argument for your business budget. IDS/IPS are usually available features in most firewalls these days, so if you segregate your networks, you can then enable these features and it should detect or prevent malware coming into your critical environment.

SIEM is critical. Security Information and Event Management systems have been around since the dawn of time but most companies avoid these due to costs, ever relying on the good old free syslog services. No, not allowed anymore, as far as PCI is concerned. We need more visibility over these logs, malicious traffic and even outgoing traffic to check if there is any communications with a command and control (C&C) server, which is the normal operations of these ransomware. SIEM these days are also no longer that expensive, with a Gartner SIEM like Alienvault starting off at a little over RM25K to get it up and running. We recently deployed a very large SIEM deployment over AWS cloud and on-premise on a major airlines with a fraction of the cost compared to traditional SIEM deployments.

There you have it. WannaCry is a very serious outbreak and we will be monitoring this system and also making our visits to our clients to give a short talk and description over it. If you have any questions over this, or on PCI-DSS or SIEM, drop us a note at avantedge@pkfmalaysia.com.

Stay safe!

Deploy HIDS agent in a Checkpoint Environment

avlogo

In our years of deploying and implementing SIEM, if we get 10 ringgit everytime a customer says: “Nothing wrong on our side, your SIEM is the problem” and then after hours of troubleshooting, the customer responds: “Ooops sorry, seems like our problem, we blocked your traffic” – we would all be as rich as Jack Ma by now.

The issue here is not so much that SIEMs are notoriously difficult to deploy – they are not, but its more that other devices need to talk to it. Deploying SIEM is easy, the finetuning is the problem. Because products need to get logs to the SIEM – either through the good old Syslog via UDP/TCP 514 or through agents installed on the systems, or through third party applications like Snare and NXLog – both for the naughty Windows machine where no syslog facility is found for some strange, Bill Gatesy reason.

It’s also because most Administrators guard their systems like pitbulls and any request for them to send logs over is generally greeted by a dumbfounded “Why are you so stupid” look, or “Over my dead body” look, or simply you get ignored completely. Oh, and also the “I want to go home at 5 pm today, so don’t mess with my jam” look. Whatever. The war between Administrators and Implementers has been going on longer than the blood feud between Lycans and Vampires.

We have been through deployments where countless of hours were spent just trying to convince our customer: “We are NOT getting anything on the interface. No packets. It’s being blocked.” And customer: “No, there are no firewalls between.” Five hours later, customer: “Oh yeah, there is a small firewall between and it’s blocking. Cheers”. On our SIEM, it’s easy. If our interface doesn’t see it, it ain’t there. That’s it. Do a tcpdump and grep the IP or port and boom, we know it’s not our problem.

The issue here is that “Not our problem” generally gets translated to “It’s now your problem” and we end up troubleshooting for our clients how to fix THEIR systems and devices. I’ve called my pals at Fortigate, Bluecoat, Cisco, Juniper etc so many times, asking them about issues that my client should be doing it themselves.

So anyway – we had this issue whereby we deployed a fair bit of HIDS (Host IDS, aka OSSEC) agents in a fairly large environment. It basically traverses through a firewall (Checkpoint). That Checkpoint firewall dropped UDP 1514 connection between agent and our AlienVault server. Port 1514 is the port that our HIDS uses to communicate between agent and server.

Firstly, establish whether we are getting those traffic or not in the interface. If we are not, then the problem could be on their end. When we do a tcpdump for udp 1514 on that specific host, we are able to observe some traffic from the server and vice versa. In our case even with that, the connection cannot be established. Bascially, our agent is able to reach the server but the server tries to respond but the traffic disappears. Therefore, the agent is orphaned.

For this case, after troubleshoot and checking, we found out that Checkpoint is dropping the UDP 1514 traffic responses from the alienvault server. So the communication between the HIDS agent and the server is never established. The log shows that UDP traffic is dropped with the following message:

Message_Info: Violated unidirectional connection

Great. UDP traffic is a stateless protocol. According to Checkpoint, by default, a reply to a UDP packet is not allowed. The Security Gateway can mark a connection in the Connections Table to allow traffic to pass only in one direction (hence the term ‘unidirectional’). If a UDP connection uses a bi-directional communication method, this would create a violation.

Therefore, the workaround to this is to allow Checkpoint to respond to this bi-directional communication. It’s pretty straightforward for Checkpoint actually.

You will need to add or edit a service object in Checkpoint. Again, we are Alienvault implementers but we end up mucking through Checkpoint firewalls just to get our job done!

So on a checkpoint edge box, it’s basically

Main Menu->Network->Network Services tab

You can now edit or add.

Go ahead and add a new UDP service, fill in the requirements, and then you will have an option for advanced, click OK.

In the Advanced UDP service property, ensure “Accept Replies” is clicked.

Now go ahead and use this service under the new or existing policy rule that has been set up for Agent->Server communication for HIDS.

Ta-da, done!

If you have any questions on Alienvault USM deployment, drop us a note at alienvault@pkfmalaysia.com.

« Older posts Newer posts »

© 2024 PKF AvantEdge

Up ↑