Real-time anti-malware solutions all require it. It's the limitation they run into when attempting to implement kqueue. Not having the functionality of inotify is a show-stopper. I was hoping there was a way around this limitation in the newer FreeBSDs.fluca1978 said:I cannot imagine why a single process should monitor more than 1024 directories
Where do you get the 1024 limit?will run it out of the max number of open files (typically 1024)
[~]% sysctl -d kern.maxfiles kern.maxfiles: Maximum number of files [~]% sysctl -d kern.maxfilesperproc kern.maxfilesperproc: Maximum files allowed open per process [~]% sysctl kern.maxfiles kern.maxfiles: 12328 [~]% sysctl kern.maxfilesperproc kern.maxfilesperproc: 11095
I was reading here. http://git-annex.branchable.com/design/assistant/inotify/Carpetsmoker said:Where do you get the 1024 limit?...You can increase these further, but these are the defaults on my FreeBSD 8.2 and 9.0 systems...
"Under Linux, Gamin uses inotify or dnotify to monitor filesystem activity. Under FreeBSD, Gamin uses kqueue/kevent as the native FreeBSD kernel event notification mechanism, but in this case kqueue has one major drawback as compared to inotify: inotify is the filename-based monitoring facility and kqueue uses file descriptors for identification of monitored files, so, under FreeBSD, gam_server has to open each file in the monitored directory. This can be an issue when monitoring directories with many files stored, because system could easily reach its kernel limits on maximum file descriptor count (kern.maxfiles and kern.maxfilesperproc)."
SirDice said:No, iNotify is a Linux kernel feature.
Perhaps so. I never heard if inotify for FreeBSD, but while searching I found this http://www.freebsd.org/cgi/man.cgi?query=inotify&apropos=0&sektion=0&manpath=SuSE+Linux/i386+11.3&format=html a post on this forum. http://forums.freebsd.org/showthread.php?t=29988wblock@ said:
No, the problem is bots guessing passwords and placing exploits on their pages. You can have users come up with passwords that meet all of the complexity requirements but the bot finds them because they use things that are easy for them to remember. When their site gets blacklisted, and it's my fault. Firewall policies are problematic because bots know how to stay under the radar. If you set the policy below the robot, it also blocks customers.kpa said:Real-time anti-malware for FreeBSD? I take it's for checking Windows malware on a fileserver running FreeBSD
Unfortunately all those types of programs all work signature based. This means it will never catch everything. If I write a brand new exploit (or something specifically targeted at your site) these programs will never catch it. Just keep a sharp eye on your logs, analyse them daily. Filter out the obvious crap and see what's left. If you do that on a regular basis you will quickly see things that are out of place, investigate those.IT_Architect said:There is a program designed to catch web exploits. Linux Malware Detector (LMD). I deployed that. The problem is, I put a known exploit out there that I saved from a previous incident, and it didn't find it, while ClamAV, which is not designed for that type of exploit, did find it.
Make sure you set up an abuse email address or some other way people can use to complain. Read them, investigate and act on them as quickly as possible. You usually only get put on banlists when there's no way to comlain or you simply don't act on any abuse complaints.So I'm just trying to come up with ways to catch things before they get blacklisted by Google and Yahoo!/Bing.
I suppose it would also pose a problem with jailed processes and other non-privileged processes, but I made the suggestion given @IT_Architect's goal of server security. I certainly wouldn't use audit as a substitute for inotify myself because every occasion I've had to monitor files or directories in real time only involved a handful of each.decke said:From a user perspective having to enable audit seems wrong. The audit implementation could probably be a good example on how to get the information in the kernel but it needs a proper API for the userland.
fswatch, albeit sporting for now a GNU license, could perhaps help? https://github.com/emcrisostomo/fswatch
Reaction score: 4
There's one in the ports tree. From the pkg-descr:I personally would like to see an iNotify API. I know its a Linux thing but it is very convenient.
In many cases I just use Go for these types of problems, it provides an fsnotify interface across platforms that is "good enough".
pkgit even gives you a nice little warning that you may want to bump the kern.maxfiles value
fswatch: https://github.com/emcrisostomo/fswatch. But could only get it to compile in FreeBSD 10 and I needed something that worked in v9. The issue with
fswatchis that is written in c++ and the c++ compiler in FreeBSD 9.x is not working properly.
fswatchin the ports but it is not related to the
fswatchI just mentioned. The
fswatchin the ports is a hash generator for files...security/fswatch
Reaction score: 144
Agreed. Some sort of 'Notify' is getting more and more desirable/needed. Cloud sync is taking off like crazy.iNotify would also be useful for all the cloud synchronization services that start to become popular. They all have the same problem that they need to watch folders that get automatically synchronized to the cloud when they change or files are added.
I am no expert.