nicsftpagent.sh script required

[DeepanshuSood]

Can anyone kindly arrange and share an nicsftpagent.sh script, as I am going to integrate the McAfee Web Gateway with RSA Security Analytics, for file reader collection.

And also share all the required documents, for creation of nicsftpagent.sh, which I need to done it on the unix platform of Web Gateway.

Kindly share it soon, as we are on the live project for the implementation of RSA Security Analytics,

Thanks in advance..

[FernandoAllende]

I don't have it here, but I'm pretty sure that yoi can find all you need in

the enVision section of SCOL.

Good night from Chile,

Fernando Allendes.

El feb 24, 2014 2:54 AM, "deepanshu" <emc-community-network@emc.com>

escribió:

ECN <https://community.emc.com/?et=watches.email.thread> nicsftpagent.sh

script required

created by deepanshu<https://community.emc.com/people/deepanshu?et=watches.email.thread>in *RSA

Security Analytics* - View the full discussion<https://community.emc.com/message/796859?et=watches.email.thread#796859>

[RSAAdmin]

Hi,

Try here (SCOL account needed) for the agent.

For the device configuration guides which may have sample scripts with them check here. It looks like there is a sample script for McAfee Web Gateway so you're in luck.

Hope this helps.

[slippery]

Hi,

about the original question, does anyone know if the agent will behave correctly (no events duplicated/lost) even in the presence of log rotation? Our Web Gateway is rotating about every hour (max log size reached) and the nicsftpagent is scheduled to run each minute in order to keep up with the latest events produced. Is this set-up correct?

Thank you in advance

[LinkanDash]

Hi,

Just wanted check, if the web gateway is creating a new file after the existing file reaching to certain size ?? Or its appending to the same log file ??

[slippery]

Hi,

the mwg is fully rotating the log file which means renaming the original file, compressing it and creating a new one for the new content.

In the meanwhile, however, we queried support about this doubt and they answered that the set-up described in my previous post may led to events loss (the loss may happen even if the file is simply truncated). They said that nicsftpagent must be used to transfer either already closed files or files that are never truncated/rotated. Even in the latter case, however, you may still see truncated log entries due to race conditions between the writer and reader jobs.

Right now we are developing a custom script based on "tail --follow=name --retry" piped to a command to send each read line to SA via syslog (this way you should never miss an event and, as a bonus, the events are collected in near-real-time 😉

[LinkanDash]

Correct,

so there is no need of opting a second solution, creating a script which will uncompress  and save the logs in a different location after the application compresses it. And then configure NIC SFTP agent to send the logs to SA through SFTP . However this process will have a delay in reporting ..

[slippery]

Unfortunately, in our set-up we do need a second solution and I'll explain you why:

• right now SA is not able to correlate events based on their own timestamp (only with the timestamp that NwLogDecoder marks them)
• we have some custom event sources (legacy software) logging only on their own files, with no option to switch them to syslog;
• we have a lot of rules based on "followed by" conditions within tight time intervals (<1 minute)

The only thing that I'm wondering is why no-one updated the nicsftpagent to became near-RT even if the inotify subsystem (inotify - Wikipedia, the free encyclopedia) is around since 2005.