I am new to Ossec, and have recently installed it on a server forthe company I am currently working for.
This server monitors 80 Windows 7 agent machines. The main purpose for setting up Ossec on these agent machines was so we could deploy file integrity monitoring.
Now to my question; What sort of directories should I be monitoring? So far I only have the default directories provided by default from Ossec. I have also added FIM to the 'System' and 'System32' directories. Are there any more directories or files you would recommend I monitor?
Kind regards,
Alex
In part, the answer depends on why you installed OSSEC. If you installed it to be compliant with a regulation (like GDPR) you probably need it to monitor any files that relate to policies. For example, if you have a policy that all passwords must be 10 characters long and you have a settings file that enforces the 10 characters you should monitor that file.
You should have OSSEC monitor any configuration files. You might also want it to monitor user files and data files.
Think about what you need to protect. If a bad actor were to get access to one of those computers what would they likely change? With the answer to that question you'll know what to protect.
Related
A little bit of context, I'm currently working on a school project, and I have to set up a "Centrex" style Asterisk server, preparing and tunning thing to reach a production ready installation.
So far I've found informations about coupling your Asterisk to 1 LDAP/AD, with an LDIF file and some configuration of the Asterisk server.
But is it even feasible to use multiple distinct LDAP/AD ? Or are you supposed to connect to only one LDAP/AD per Asterisk server ?
If possible, how much of an hassle would it be to set up ?
I am running CentOS 7.7 with a fresh install of Asterisk 16.
Asterisk is opensource soft. Since almost nobody need connect 2 or more AD to server, this feature have no implementation.
There is 2 possible solution for this
1) read and modifiy ldap driver in asterisk. Just copy/paste to make second with other name. Require c/c++ programming experience
2) read openldap documentation and do do changes in it. Like make sub-trees etc. Require openldap/AD administration experience.
Both seams like require advanced experience.
I would say that typically, LDAP-aware applications only connect to one LDAP tree at a time. This has to do with differences in search locations, schema, etc.
Looking at the Asterisk LDAP integration docs, it looks like it follows the same pattern: it can integrate with one LDAP tree.
If you really want to link multiple ADs / LDAP directory trees, you might be able to use LDAP referrals but that requires quite a lot of knowledge.
I'm in a company which demands simultaneously collaboration on a web application, to avoid any conflict during development our CEO suggests the use of SVN version control system so each user can lock the file when they're working on it.
SVN does support locking files for each user but the problem is we need to lock the file on reading, SVN as I know to make you check for any updates every time you want to see the locking status on files. What we need is to not letting other users even open/read the files that have been locked! does SVN have such a feature?! or is there any other technologies like google drive to achieve such a mechanism?
Thank you all.
I am running Sitecore 6.5
I have two installations of Sitecore and want to transfer a whole site from one installation to another.
Have found a few articles that go into Serialization and Creating a Package although they don't go into detail about how these two fit together.
How do I transfer a site from one installation to another?
thanks.
Create a package with the package designer.
include these items and their children with the button "items statically". if you have placed your solution specific item in folders, it is only needed to include these.
/sitecore/content
/sitecore/layout
/sitecore/media library
/sitecore/templates/ (only take the templates you have created. e.g. the folder user defined
using the button "files statically", include the folders with you have solution specific changes to like:
/bin
/layouts
/app.config/include (only take the files changed in the solution,
compared to a default sitecore installation)
web.config (if you have made changes to this, compared to default
sitecore web.config)
if you have any user accounts you want to transfer to, you can include them with "security accounts".
then generate zip file and install on empty sitecore and full publish :)
If your systems are similar enough, you may want to consider moving the Sitecore DBs via backup/restore (in SQL) and copying over filesystem assets. Generally I find this faster and less prone to user error than creating/installing very large packages. (Just remember to take back-ups first.)
Large packages have a tendency to break, one option would be to look into this:
http://www.hhogdev.com/Products/Team-Development-for-Sitecore/Overview.aspx
TDS can sync all your items to XML on your dev box and from that you can create a different sort of installation package which is significantly more robust than a regular package you create through the Sitecore desktop. It's the same sort of package that Sitecore use when you upgrade versions.
I believe there is a 60 day trial on this product so plenty of time to try it out.
Note: when transferring user accounts, passwords will not be migrated when using either packages or serialization.
Solution is here - cowboy-aspx from Sitecore :)
https://kb.sitecore.net/articles/242631
As far as I know there's nothing special in DNN Core to limit the volume each user can upload files. Are there any ways like changing the code or installing any modules to handle that? (for example I don't want to let users to upload more than 100MB into a space allocated to them)
Is there any configuration in DNN core that puts user uploaded files in separate folders so that the browsing of files becomes easier? Any modules recommended. (for example I want to upload user12 files to a folder named user12 or anything similar)
The setting to establish and enforce a quota for file storage would be set at the module level -- not the DNN/Portal level. It depends on the module that you use.
There does not appear to be too many choices regarding a DNN Module that would allow your users to upload various files into their own folder. However, I did find one that has two positive reviews that, if it works as promised, should suit your requirements
http://www.snowcovered.com/snowcovered2/Default.aspx?tabid=242&PackageID=16691
According to the author, it allows you to give users their own directory which they can upload to.
DNN supports disk quotas on a per portal basis. I am not aware of a module that allows disk quotas on a per user basis.
You can find the settings under Admin | Site Settings | Advanced Settings | Host Settings
I'm configuring an installer for our product which, up until now, was distributed as a war file, usually on tomcat. Once tomcat has exploded the directory, the user has to open a properties file and set their database connection information. I'd like the installer to do this (we're using install4j) but there doesn't seem to be a built-in way to modify a text file inside a war file. I could just have the installer deploy the app as an exploded directory, which would save me the trouble here, but what do I lose by deploying like that instead of deploying the war?
It might work better to set up the database connection as a JNDI Datasource, rather than hand-editing a properties file inside the webapp/ directory. This is especially important if you want to allow users to re-deploy the application from the .WAR archive without overwriting their local configuration changes.
Of course, the JNDI setup isn't going to be trivially accomplished through the installer, either, since the mechanism used varies from app server to app server. However, any competent Java application server administrator should know how to configure a named datasource. Furthermore, by delegating responsibility to the app server, you allow your users to take advantage of connection pooling, clustering, and any other features provided by the datasource implementation bundled with their application server of choice.
Not much I would think - perhaps a bit of disk space, but if that's not a problem you'd be fine. Have you thought of having the installer generate the properties file and using a ZIP library (.WAR is really a .ZIP - rename it to a .ZIP and see what you get :) ) to replace or add it in?