[ossec-list] Re: Detect Deleted Files
my server is running on cent os 6 and i have currently two agents runng one lunix cent os 6 and another windows servr 2008. in both the cases ( in windows as well as cent os ) i am not getting the log (intrigity check) for deleted files. please let me know if you need any more information. i can even copy the indivisual files or upload the vm for you. thanks regards bijesh On Friday, June 28, 2013 3:07:44 PM UTC+5:45, Rogue Bull wrote: > > What OS are you facing this issue on? Which version of OSSEC? What > comprises of "everything needed" that you did? > > You folks need to learn a thing or two when you ask for help on a forum. > Learn to provide enough details to anyone who might be kind enough to try > and help you out. Show effort. Give and you shall receive. > > On Friday, June 28, 2013 12:02:43 AM UTC+5:30, jigish thakar wrote: >> >> Guys >> >> Facing the same issue, did everything needed (as far as i know) but still >> cant see any alert. Also checked archive.log nothing is appearing there. >> >> On Thursday, July 19, 2012 6:59:47 PM UTC+5:30, Wagner Thomas wrote: >>> >>> Hi! >>> >>> >>> >>> I’m currently testing OSSEC 2.6 on centOS and basically it works fine. >>> >>> Setup was easy to do and also the configuration of manager and agent >>> went fine. >>> >>> >>> >>> My problem now is, that I don’t get alerts if files are deleted (added >>> and changed files are reported correctly). >>> >>> >>> >>> This is my rule for deleted files (nothing changed after the >>> installation): >>> >>> >>> >>> >>> >>> ossec >>> >>> syscheck_deleted >>> >>> File deleted. Unable to retrieve checksum. >>> >>> syscheck, >>> >>> >>> >>> >>> >>> Should it work with that rule or do I have to configure something else >>> additionally? >>> >>> >>> >>> I hope someone knows that problem and can help me! >>> >>> >>> >>> Best regards, >>> >>> Thomas >>> >>> >>> >>> >>> >>> *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"* >>> T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien >>> Handelsgericht Wien, FN 79340b >>> >>> *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"* >>> Notice: This e-mail contains information that is confidential and may be >>> privileged. >>> If you are not the intended recipient, please notify the sender and then >>> delete this e-mail immediately. >>> >>> *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"* >>> >> -- --- You received this message because you are subscribed to the Google Groups "ossec-list" group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[ossec-list] Very big syscheck queue - how to deal with it?
Hey guys, we are having an OSSEC server installation on debian with about 210 Windows and Linux Ossec-Clients in our network. Regarding to syscheck we have literally have the default settings of ossec that includes a big part of the windows registry and windows directory as well as most linux directories and this check is executed every 10 hours. Now looking at our /var/ossec/queue/syscheck queue directory at the server, this folder has an size of 5.4 GB and contains 2 "files" for almost every ossec-client. I really wonder why this folder grows that big, cause it should only be the queue if our server isnt able to perform the checks at the given time due to lacking cpu/ram/network ressources. Because none of these lacks are given i´d like to know how i can decrease the size of this queue. Thx for response -- --- You received this message because you are subscribed to the Google Groups "ossec-list" group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ossec-list] Re: Microsoft Azure Multi-Factor Decode and Rules.
On Fri, Dec 5, 2014 at 3:19 PM, Brent Morris wrote: > Wish I could edit that last post! > > I forgot a few lines complete local_decoder.xml below. > > add the following to local_decoder.xml > > > > ^pfsvc > > > >pfsvc-auth > Pfauth \w+ for user '(\S+)'. Call status: > (\S+) - "\w+\s+\w+|\w+\s+\w+\s+\w+\.". > srcuser, status > > Awesome stuff! Can you provide some log samples? > > > On Friday, December 5, 2014 11:51:18 AM UTC-8, Brent Morris wrote: >> >> Not exactly sure if this is the right place to post this, but it took me >> some time to get working decodes for Microsoft's Azure Multi-Factor >> Authentication (PhoneFactor.net). >> >> It's pretty cool multifactor authentication for on-prem RDP Gateway and >> OWA using your phone as the second factor. >> >> This was my first attempt to create my own decodes for an app that wasn't >> supported by OSSEC. OSSEC is so cool that I wanted to share these with >> others incase there might be one or two of you out there that could benefit. >> We're not using the APP or voice calls, but it shouldn't be to hard with the >> info below to setup the rest of the options for those. >> >> You could have the agent monitor the log files, or setup syslog inside the >> PhoneFactor app. I opted for syslog messages. >> >> And let me know if I'm posting in the wrong place, have an error in my >> decodes, or anything else helpful. >> >> Thanks! >> >> --- >> >> >> >> add the following to local_decoder.xml >> >> >>pfsvc-auth >> Pfauth \w+ for user '(\S+)'. Call status: >> (\S+) - "\w+\s+\w+|\w+\s+\w+\s+\w+\.". >> srcuser, status >> >> >> then add the following to local_rules.xml (tailor to your specific needs). >> >> >> >> pfsvc-auth >> Phone Factor Authentication app group. >> >> >> 100140 >> FAILED_SMS_OTP_INCORRECT >> User Failed SMS Challenge/Response >> >> >> >> --end local_rules.xml > > -- > > --- > You received this message because you are subscribed to the Google Groups > "ossec-list" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to ossec-list+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- --- You received this message because you are subscribed to the Google Groups "ossec-list" group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ossec-list] Very big syscheck queue - how to deal with it?
On Mon, Dec 8, 2014 at 7:17 AM, horst knete wrote: > Hey guys, > > we are having an OSSEC server installation on debian with about 210 Windows > and Linux Ossec-Clients in our network. > > Regarding to syscheck we have literally have the default settings of ossec > that includes a big part of the windows registry and windows directory as > well as most linux directories and this check is executed every 10 hours. > > Now looking at our /var/ossec/queue/syscheck queue directory at the server, > this folder has an size of 5.4 GB and contains 2 "files" for almost every > ossec-client. > Those are actually files. > I really wonder why this folder grows that big, cause it should only be the > queue if our server isnt able to perform the checks at the given time due to > lacking cpu/ram/network ressources. > Those files grow because there are changes on the systems they represent. Those are the syscheck database files. If you need them shrunk, you'll have to clear the databases. I don't know what the rest of that means though (the cpu/ram/network stuff). > Because none of these lacks are given i´d like to know how i can decrease > the size of this queue. > > Thx for response > > -- > > --- > You received this message because you are subscribed to the Google Groups > "ossec-list" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to ossec-list+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- --- You received this message because you are subscribed to the Google Groups "ossec-list" group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ossec-list] Re: Detect Deleted Files
On Mon, Dec 8, 2014 at 2:28 AM, Bijesh Maskey wrote: > my server is running on cent os 6 and i have currently two agents runng one > lunix cent os 6 and another windows servr 2008. in both the cases ( in > windows as well as cent os ) i am not getting the log (intrigity check) for > deleted files. please let me know if you need any more information. i can > even copy the indivisual files or upload the vm for you. What version of OSSEC are you using? > thanks > regards > bijesh > > > On Friday, June 28, 2013 3:07:44 PM UTC+5:45, Rogue Bull wrote: >> >> What OS are you facing this issue on? Which version of OSSEC? What >> comprises of "everything needed" that you did? >> >> You folks need to learn a thing or two when you ask for help on a forum. >> Learn to provide enough details to anyone who might be kind enough to try >> and help you out. Show effort. Give and you shall receive. >> >> On Friday, June 28, 2013 12:02:43 AM UTC+5:30, jigish thakar wrote: >>> >>> Guys >>> >>> Facing the same issue, did everything needed (as far as i know) but still >>> cant see any alert. Also checked archive.log nothing is appearing there. >>> >>> On Thursday, July 19, 2012 6:59:47 PM UTC+5:30, Wagner Thomas wrote: Hi! I'm currently testing OSSEC 2.6 on centOS and basically it works fine. Setup was easy to do and also the configuration of manager and agent went fine. My problem now is, that I don't get alerts if files are deleted (added and changed files are reported correctly). This is my rule for deleted files (nothing changed after the installation): ossec syscheck_deleted File deleted. Unable to retrieve checksum. syscheck, Should it work with that rule or do I have to configure something else additionally? I hope someone knows that problem and can help me! Best regards, Thomas *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"* T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien Handelsgericht Wien, FN 79340b *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"* Notice: This e-mail contains information that is confidential and may be privileged. If you are not the intended recipient, please notify the sender and then delete this e-mail immediately. *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"* > > -- > > --- > You received this message because you are subscribed to the Google Groups > "ossec-list" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to ossec-list+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- --- You received this message because you are subscribed to the Google Groups "ossec-list" group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ossec-list] Silent mode for an agent during system updates?
On Fri, Dec 5, 2014 at 5:35 PM, Christina Plummer wrote: > >> > Is there a way to silence an agent for a specific time, so it will not >> > generate events? During a system update, there shouldn't be any alarms >> > of >> >> You can clear the database, update the system, and then run a new scan. > > > I believe this has been asked before as well, but I could not find the > answer in my search - is it possible for the AGENT to trigger this action? > If you have one central OSSEC server and many agent servers that patch > themselves on different days, it seems like it would be challenging to time > the clearing of the database just right... For example, in my environment, > we update servers in many batches of 20-30 at a time - if we centrally clear > the databases of all before we start, it's possible that a syscheck run may > kick off on some of the servers in the group BEFORE they actually receive > their updates. I'd like to be able to easily trigger the syscheck_control > -u for a specific agent just before they start their updates. > Yes and no. It's cludgy, but you could have a package update trigger an active response on the manager to clear the database. It could be a security issue, handing over some control of the database to the agent, but it should be possible. >> >> > yum, changing binaries and configuration files. There should be some >> > kind of >> > maintenance mode for agents while the system is updated. >> > >> >> We look forward to this contribution, it's a fairly frequently asked >> question. Please submit a pull request at >> https://github.com/ossec/ossec-hids > > > Would that I could. I can, however, write up a feature request if that > would help to get it on the enhancement list? I took a look and did not see > it already there. Actually, there might be a few possible > enhancement/feature requests in this area (based on what I've seen brought > up on the list over the past couple of years): > 1) enable agents to go into maintenance mode > 2) allow agents to re-initialize their own database per the above (not sure > if there is a security reason to prevent this) Possibly compromised systems shouldn't have control over a database they do not have control over. That's kind of the idea behind sending the hashes to the manager. It helps prevent shady behavior. > 3) enable syscheckd to compare changes against a trusted database such as > yum/dpkg and possibly a configurable local database (e.g. we centrally > manage some config files so it would be nice if we could NOT alert if the > file matched the current version according to our config mgr). Lots of people want this, no one wants it enough to do the work. That's what it boils down to really. You want these features, but not enough to get them done. Everyone seems to agree with you, these aren't currently worth doing. > 4) selectively clear/update the contents of the syscheckd database. I hate > to receive alerts about "known" changes, but I also hate to clear the > database and lose all the history just because I need to push out some > planned changes > > Let me know if any of these are already in the system (or are extremely > ill-advised for some reason!), otherwise I can submit them as new issues. > If you don't see an issue about them, create one. > Christina > > -- > > --- > You received this message because you are subscribed to the Google Groups > "ossec-list" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to ossec-list+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- --- You received this message because you are subscribed to the Google Groups "ossec-list" group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ossec-list] ossec 2.7.1 file deletion not detected
On Sun, Dec 7, 2014 at 1:20 AM, Bijesh Maskey wrote: > hi all, > I have installed and configure ossec server in cent os 6 and two client Win > 2k8 and cent os as agents running on my virtual box. Ossec is running > smoothly and detecting all the changes made on the files where the path is > assigned. I am getting logs form both the clients. but the problem came when > I did my test for delete files. on the ossec server itself I crated the file > ( osec reported), I changed the content of the file it detected. and when I > delete it didn't. can any one please guide me through. as per my research, > ossec should have returned "-1" value when the file is deleted how ever I am > not even getting the update. > > as I went further down on the web to search for the issue : I found this is > include in one of the rule files: can you please suggest me in which file is > this suggested rule located: > > or do I have to include this in the config file, > > > ossec > > syscheck_deleted > > File deleted. Unable to retrieve checksum. > > syscheck, > > > > can anyone suggest. > Popular question this weekend. What version of OSSEC are you running? > thanks > > regards > > bijesh > > > -- > > --- > You received this message because you are subscribed to the Google Groups > "ossec-list" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to ossec-list+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- --- You received this message because you are subscribed to the Google Groups "ossec-list" group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[ossec-list] Error with server installatin in binary Mode
We have an error with installing the OSSEC Server when using Binary Installation Mode: Example: 2014/12/08 16:26:46 Could not get ossec gid. Started ossec-analysisd... 2014/12/08 16:26:46 ossec-logcollector(1103): ERROR: Unable to open file '/queue/ossec/.agent_info'. Started ossec-logcollector... Started ossec-remoted... 2014/12/08 16:26:46 ossec-syscheckd(1103): ERROR: Unable to open file '/queue/ossec/.agent_info'. 2014/12/08 16:26:46 ossec-syscheckd(1103): ERROR: Unable to open file '/queue/ossec/.agent_info'. Started ossec-syscheckd... Started ossec-monitord... Completed. When we are using "compiling" mode, the queue will be created successfully. Maybe something to change in src/headers/defs.h ? best regards Philipp -- --- You received this message because you are subscribed to the Google Groups "ossec-list" group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ossec-list] Silent mode for an agent during system updates?
On Mon, Dec 8, 2014 at 8:01 AM, dan (ddp) wrote: > Yes and no. It's cludgy, but you could have a package update trigger > an active response on the manager to clear the database. It could be a > security issue, handing over some control of the database to the > agent, but it should be possible. > FYI, as I've posted before, I'm using Active Response to verify the changed file with dpkg/rpm, then raising a custom alert if the file was changed. I'm writing something up about this right now. There's a better way to do this, though, and my approach does have some problems. > Possibly compromised systems shouldn't have control over a database > they do not have control over. That's kind of the idea behind sending > the hashes to the manager. It helps prevent shady behavior. > So, possibly compromised systems can't be trusted to maintain their own database, but can be trusted to provide their own hashes? I'm not sure I understand the difference? Lots of people want this, no one wants it enough to do the work. > That's what it boils down to really. You want these features, but not > enough to get them done. Everyone seems to agree with you, these > aren't currently worth doing. > The manager gets the hashes, which pretty much solves the underlying problem. What I'd prefer to do is stop mucking about with Active Response, which is ugly, and have an alert filter in place that understands what checksums are acceptable, as well as understand the rate of alerts: one alert for a given file on one server in a 24-hour period is bad, but 1 alert per server across all servers is fine (so long as all alerts pass the 'known good checksum' stuff). If things check out okay, quash the alert. If they don't, pass it on. If things look fishy, generate your own alert. Unfortunately, now that I've removed my pain with the Active Response stuff, I have no motivation to work on fixing this properly. It'll get added to the list of things I should do but will never have time for. -- --- You received this message because you are subscribed to the Google Groups "ossec-list" group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ossec-list] Error with server installatin in binary Mode
On Mon, Dec 8, 2014 at 10:30 AM, Philipp Hoferichter wrote: > We have an error with installing the OSSEC Server when using Binary > Installation Mode: > > Example: > 2014/12/08 16:26:46 Could not get ossec gid. Does the ossec group exist? > Started ossec-analysisd... > 2014/12/08 16:26:46 ossec-logcollector(1103): ERROR: Unable to open file > '/queue/ossec/.agent_info'. > Started ossec-logcollector... > Started ossec-remoted... > 2014/12/08 16:26:46 ossec-syscheckd(1103): ERROR: Unable to open file > '/queue/ossec/.agent_info'. > 2014/12/08 16:26:46 ossec-syscheckd(1103): ERROR: Unable to open file > '/queue/ossec/.agent_info'. > Started ossec-syscheckd... > Started ossec-monitord... > Completed. > > > When we are using "compiling" mode, the queue will be created successfully. > > Maybe something to change in src/headers/defs.h ? > > best regards > > Philipp > > -- > > --- > You received this message because you are subscribed to the Google Groups > "ossec-list" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to ossec-list+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- --- You received this message because you are subscribed to the Google Groups "ossec-list" group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ossec-list] Silent mode for an agent during system updates?
On Mon, Dec 8, 2014 at 10:34 AM, Damian Gerow wrote: > On Mon, Dec 8, 2014 at 8:01 AM, dan (ddp) wrote: >> >> Yes and no. It's cludgy, but you could have a package update trigger >> an active response on the manager to clear the database. It could be a >> security issue, handing over some control of the database to the >> agent, but it should be possible. > > > FYI, as I've posted before, I'm using Active Response to verify the changed > file with dpkg/rpm, then raising a custom alert if the file was changed. > I'm writing something up about this right now. > > There's a better way to do this, though, and my approach does have some > problems. > >> >> Possibly compromised systems shouldn't have control over a database >> they do not have control over. That's kind of the idea behind sending >> the hashes to the manager. It helps prevent shady behavior. > > > So, possibly compromised systems can't be trusted to maintain their own > database, but can be trusted to provide their own hashes? I'm not sure I > understand the difference? > Yep, it's the best we've come up with. Have any good ideas? >> Lots of people want this, no one wants it enough to do the work. >> That's what it boils down to really. You want these features, but not >> enough to get them done. Everyone seems to agree with you, these >> aren't currently worth doing. > > > The manager gets the hashes, which pretty much solves the underlying > problem. > > What I'd prefer to do is stop mucking about with Active Response, which is > ugly, and have an alert filter in place that understands what checksums are > acceptable, as well as understand the rate of alerts: one alert for a given > file on one server in a 24-hour period is bad, but 1 alert per server across > all servers is fine (so long as all alerts pass the 'known good checksum' > stuff). If things check out okay, quash the alert. If they don't, pass it > on. If things look fishy, generate your own alert. > > Unfortunately, now that I've removed my pain with the Active Response stuff, > I have no motivation to work on fixing this properly. It'll get added to > the list of things I should do but will never have time for. > > -- > > --- > You received this message because you are subscribed to the Google Groups > "ossec-list" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to ossec-list+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- --- You received this message because you are subscribed to the Google Groups "ossec-list" group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ossec-list] Silent mode for an agent during system updates?
On Mon, Dec 8, 2014 at 10:39 AM, dan (ddp) wrote: > >> Possibly compromised systems shouldn't have control over a database > >> they do not have control over. That's kind of the idea behind sending > >> the hashes to the manager. It helps prevent shady behavior. > > > > > > So, possibly compromised systems can't be trusted to maintain their own > > database, but can be trusted to provide their own hashes? I'm not sure I > > understand the difference? > > > > Yep, it's the best we've come up with. Have any good ideas? Not really, as this is a deviously complicated problem to solve: the vast majority of restrictions placed on a client that's following the rules can be emulated by a client that's not. I've been trying to figure out this particular problem for years now, to no avail. I think the way OSSEC does it makes sense, but I also think it's a bit disingenuous to state that we can trust systems to report on their own binaries, but not to maintain their own database: the latter is just a recorded collection of the former. And yes, not being able to wipe your own database is an improvement, but I'm not sure by how much. Any potential improvement I think about I eventually discard with the reasoning: if an attacker is smart enough to not be caught by a local agent that collects file metadata, he/she is smart enough to not be caught by as well. -- --- You received this message because you are subscribed to the Google Groups "ossec-list" group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ossec-list] Silent mode for an agent during system updates?
On Mon, Dec 8, 2014 at 10:56 AM, Damian Gerow wrote: > On Mon, Dec 8, 2014 at 10:39 AM, dan (ddp) wrote: >> >> >> Possibly compromised systems shouldn't have control over a database >> >> they do not have control over. That's kind of the idea behind sending >> >> the hashes to the manager. It helps prevent shady behavior. >> > >> > >> > So, possibly compromised systems can't be trusted to maintain their own >> > database, but can be trusted to provide their own hashes? I'm not sure >> > I >> > understand the difference? >> > >> >> Yep, it's the best we've come up with. Have any good ideas? > > > Not really, as this is a deviously complicated problem to solve: the vast > majority of restrictions placed on a client that's following the rules can > be emulated by a client that's not. > > I've been trying to figure out this particular problem for years now, to no > avail. I think the way OSSEC does it makes sense, but I also think it's a > bit disingenuous to state that we can trust systems to report on their own > binaries, but not to maintain their own database: the latter is just a I'm sorry, I didn't mean to type that. What I meant was sending the hashes to the manager helps prevent some shady behavior. I believe that's also the thought behind using multiple hashes. It's also pretty obvious that the data from a compromised system cannot be trusted, so it's possible all of this is totally worthless. Hopefully you get a couple of alerts from the system before the compromise makes them worthless. > recorded collection of the former. And yes, not being able to wipe your own > database is an improvement, but I'm not sure by how much. > > Any potential improvement I think about I eventually discard with the > reasoning: if an attacker is smart enough to not be caught by a local agent > that collects file metadata, he/she is smart enough to not be caught by > as well. > > -- > > --- > You received this message because you are subscribed to the Google Groups > "ossec-list" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to ossec-list+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- --- You received this message because you are subscribed to the Google Groups "ossec-list" group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ossec-list] Silent mode for an agent during system updates?
On Mon, Dec 8, 2014 at 11:05 AM, dan (ddp) wrote: > >> >> Possibly compromised systems shouldn't have control over a database > >> >> they do not have control over. That's kind of the idea behind sending > >> >> the hashes to the manager. It helps prevent shady behavior. > >> > > >> > > >> > So, possibly compromised systems can't be trusted to maintain their > own > >> > database, but can be trusted to provide their own hashes? I'm not > sure > >> > I > >> > understand the difference? > >> > > >> > >> Yep, it's the best we've come up with. Have any good ideas? > > > > > > Not really, as this is a deviously complicated problem to solve: the vast > > majority of restrictions placed on a client that's following the rules > can > > be emulated by a client that's not. > > > > I've been trying to figure out this particular problem for years now, to > no > > avail. I think the way OSSEC does it makes sense, but I also think it's > a > > bit disingenuous to state that we can trust systems to report on their > own > > binaries, but not to maintain their own database: the latter is just a > > I'm sorry, I didn't mean to type that. What I meant was sending the > hashes to the manager helps prevent some shady behavior. I believe > that's also the thought behind using multiple hashes. It's also pretty > obvious that the data from a compromised system cannot be trusted, so > it's possible all of this is totally worthless. Hopefully you get a > couple of alerts from the system before the compromise makes them > worthless. > I think we're in agreement here, then. -- --- You received this message because you are subscribed to the Google Groups "ossec-list" group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[ossec-list] Monitoring ASA - Agentless
Hello; I would like to monitor our ASA 5510. Is there any documentation or tutorial on monitoring an ASA ? I have found limited information and my understading. 1)I have to edit the register_host.sh, add the host.: if so, Where? 2)edit ssh_asa-fwsmconfig_diff, with the password: is this the SNMP pwd ? 3)Run ssh_asa-fwsmconfig_diff within \ossec Is this basically all there is to be done? Thank you for your help -- --- You received this message because you are subscribed to the Google Groups "ossec-list" group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ossec-list] Silent mode for an agent during system updates?
On 2014-12-08 9:56, Damian Gerow wrote: On Mon, Dec 8, 2014 at 10:39 AM, dan (ddp) wrote: Possibly compromised systems shouldn't have control over a database they do not have control over. That's kind of the idea behind sending the hashes to the manager. It helps prevent shady behavior. So, possibly compromised systems can't be trusted to maintain their own database, but can be trusted to provide their own hashes? I'm not sure I understand the difference? Yep, it's the best we've come up with. Have any good ideas? Not really, as this is a deviously complicated problem to solve: the vast majority of restrictions placed on a client that's following the rules can be emulated by a client that's not. I've been trying to figure out this particular problem for years now, to no avail. I think the way OSSEC does it makes sense, but I also think it's a bit disingenuous to state that we can trust systems to report on their own binaries, but not to maintain their own database: the latter is just a recorded collection of the former. And yes, not being able to wipe your own database is an improvement, but I'm not sure by how much. With real-time checks enabled, it's a time-based security problem. Can the agent send the hashes to the manager before the attacker can alter or stop them? In many cases, the answer is yes. But if the attacker has administrator or root access then of course, in theory at least, he could disable the ossec agent before doing the naughty stuff. This is one of the problems that mandatory labels attempt to solve. Technologies like SELinux on 'nix or Mandatory Integrity Control on Windows could protect the hashes on the agent even if the attacker has administrative access. I'm not sure about Windows, but I think SELinux at least can be configured such that relabeling requires a reboot first. The agent files could be configured with these labels. Of course there are plenty of "but-ifs and what-ifs" here. The real question is: is the way OSSEC behaves likely to be sufficient for most use cases and will the hashes sent to the manager be trustworthy? I think the answer in the vast majority of cases is "yes." And if the manager indicates that a monitored host is compromised, the assumption should be made that all data is suspect and work back from there. -- --- You received this message because you are subscribed to the Google Groups "ossec-list" group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ossec-list] Monitoring ASA - Agentless
On Mon, Dec 8, 2014 at 11:55 AM, Semperfi wrote: > Hello; > > I would like to monitor our ASA 5510. Is there any documentation or > tutorial on monitoring an ASA ? > > I have found limited information and my understading. > > > > 1)I have to edit the register_host.sh, add the host.: if so, > Where? > Try running register_host.sh instead. > 2)edit ssh_asa-fwsmconfig_diff, with the password: is this the > SNMP pwd ? > register_host.sh should take care of getting the password. And the login/password information it will require will be for SSHing to the system (notice ssh_ at the beginning of the file name). > 3)Run ssh_asa-fwsmconfig_diff within \ossec > You shouldn't have to do this if the system is registered properly. > > > Is this basically all there is to be done? > I can't guarantee that this is totally correct at this point, but take a peek at this: http://ossec-docs.readthedocs.org/en/latest/manual/agent/agentless-monitoring.html#getting-started-with-agentless > > > Thank you for your help > > > > -- > > --- > You received this message because you are subscribed to the Google Groups > "ossec-list" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to ossec-list+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- --- You received this message because you are subscribed to the Google Groups "ossec-list" group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[ossec-list] Re: Monitoring ASA - Agentless
Sir, You can also configure the ASA to send log events via syslog, either directly to OSSEC or to the syslog daemon on the ossec server, so OSSEC can monitor that output as well. Caveat: I am not very familiar with the remote monitoring but it is my understanding that this would only check the configuration and would not have access to the ASA's logs. thanks, Rick On Monday, December 8, 2014 11:55:30 AM UTC-5, Semperfi wrote: > > Hello; > > I would like to monitor our ASA 5510. Is there any documentation or > tutorial on monitoring an ASA ? > > I have found limited information and my understading. > > > > 1)I have to edit the register_host.sh, add the host.: if > so, Where? > > 2)edit ssh_asa-fwsmconfig_diff, with the password: is this > the SNMP pwd ? > > 3)Run ssh_asa-fwsmconfig_diff within \ossec > > > > Is this basically all there is to be done? > > > > Thank you for your help > > > -- --- You received this message because you are subscribed to the Google Groups "ossec-list" group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ossec-list] Silent mode for an agent during system updates?
On Mon, Dec 8, 2014 at 12:13 PM, Michael Starks < ossec-l...@michaelstarks.com> wrote: > With real-time checks enabled, it's a time-based security problem. Can the > agent send the hashes to the manager before the attacker can alter or stop > them? Yes: stop OSSEC, start your own agent. This is precisely the use case I'm concerned about, as this is the use case of a malicious user or a compromised SSH key. In all other cases -- where OSSEC is not stopped first -- a standalone OSSEC agent with real-time monitoring will catch pretty much anything. Using agents and a centralized manager doesn't address this head-on, but does make it more likely the attacker would flag something. > This is one of the problems that mandatory labels attempt to solve. > Technologies like SELinux on 'nix or Mandatory Integrity Control on Windows > could protect the hashes on the agent even if the attacker has > administrative access. I'm not sure about Windows, but I think SELinux at > least can be configured such that relabeling requires a reboot first. The > agent files could be configured with these labels. > I'm fairly familiar with SELinux, and I'm not entirely sure how it can help. Can you expand a bit, please? What is it that SELinux would actually be protecting (aka can you clarify "protect the hashes on the agent"), and how would it do so? > Of course there are plenty of "but-ifs and what-ifs" here. The real > question is: is the way OSSEC behaves likely to be sufficient for most use > cases and will the hashes sent to the manager be trustworthy? I think the > answer in the vast majority of cases is "yes." Agreed, with the exception of the use case (root-level compromise) we identified above. This isn't limited to OSSEC; this is an issue with pretty much all in-OS indicators of compromise: if the context in which you're running is also the context in which you were compromised, you're going to have a bad time. In other words, and to underline the point I was making: in the cases where the hashes are trustworthy (non-root compromise), so, too, would a local database be trustworthy. In the cases where we would benefit from having a remote database that is not directly accessible from the agent (root compromise), the benefits of doing so would be slim, as we can no longer trust the hashes. There are definitely still cases where this indirect database access helps, yes. (I've taken this conversation off into the weeds; I apologize.) -- --- You received this message because you are subscribed to the Google Groups "ossec-list" group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ossec-list] Re: Microsoft Azure Multi-Factor Decode and Rules.
I can. Are you interested in just the important bits as they relate to the decodes (authentication success/failure), or did you want to see the entire log file? It's a fairly verbose application, so with the logging level that I setup on it, it only reports application errors, administrator functions, and authentications (so far anyway). In our case, we're using SMS text message only at the moment. I tested the voice call and the local_rules would need to be updated for failures on that. Looks like it follows a similar format. Sanitized logs below from syslog: 2014 Dec 08 13:04:05 pfserver->1.2.3.4 Dec 8 13:04:05 pfserver pfsvc: Pfauth succeeded for user 'DOMAIN\username'. Call status: SUCCESS_SMS_AUTHENTICATED - "SMS Authenticated". 2014 Dec 08 13:04:43 pfserver->1.2.3.4 Dec 8 13:04:43 pfserver pfsvc: Pfauth succeeded for user 'DOMAIN\username'. Call status: SUCCESS_SMS_AUTHENTICATED - "SMS Authenticated". 2014 Dec 08 13:06:32 pfserver->1.2.3.4 Dec 8 13:06:32 pfserver pfsvc: Pfauth failed for user 'DOMAIN\username'. Call status: FAILED_SMS_OTP_INCORRECT - "SMS OTP Incorrect". 2014 Dec 08 13:33:23 pfserver->1.2.3.4 Dec 8 13:33:23 pfserver pfsvc: User "DOMAIN\domainadmin" changed user "DOMAIN\username" value mode3 from 3 to 2. 2014 Dec 08 13:33:50 pfserver->1.2.3.4 Dec 8 13:33:50 pfserver pfsvc: Pfauth succeeded for user 'DOMAIN\username'. Call status: SUCCESS_NO_PIN - "Only # Entered". 2014 Dec 08 13:35:23 pfserver->1.2.3.4 Dec 8 13:35:23 pfserver pfsvc: Pfauth failed for user 'DOMAIN\username'. Call status: SUCCESS_NO_PIN_BUT_TIMEOUT - "No Phone Input - Timed Out". On Monday, December 8, 2014 5:03:57 AM UTC-8, dan (ddpbsd) wrote: > On Fri, Dec 5, 2014 at 3:19 PM, Brent Morris > wrote: > > Wish I could edit that last post! > > > > I forgot a few lines complete local_decoder.xml below. > > > > add the following to local_decoder.xml > > > > > > > > ^pfsvc > > > > > > > >pfsvc-auth > > Pfauth \w+ for user '(\S+)'. Call > status: > > (\S+) - "\w+\s+\w+|\w+\s+\w+\s+\w+\.". > > srcuser, status > > > > > > Awesome stuff! Can you provide some log samples? > > > > > > > On Friday, December 5, 2014 11:51:18 AM UTC-8, Brent Morris wrote: > >> > >> Not exactly sure if this is the right place to post this, but it took > me > >> some time to get working decodes for Microsoft's Azure Multi-Factor > >> Authentication (PhoneFactor.net). > >> > >> It's pretty cool multifactor authentication for on-prem RDP Gateway and > >> OWA using your phone as the second factor. > >> > >> This was my first attempt to create my own decodes for an app that > wasn't > >> supported by OSSEC. OSSEC is so cool that I wanted to share these with > >> others incase there might be one or two of you out there that could > benefit. > >> We're not using the APP or voice calls, but it shouldn't be to hard > with the > >> info below to setup the rest of the options for those. > >> > >> You could have the agent monitor the log files, or setup syslog inside > the > >> PhoneFactor app. I opted for syslog messages. > >> > >> And let me know if I'm posting in the wrong place, have an error in my > >> decodes, or anything else helpful. > >> > >> Thanks! > >> > >> --- > >> > >> > >> > >> add the following to local_decoder.xml > >> > >> > >>pfsvc-auth > >> Pfauth \w+ for user '(\S+)'. Call > status: > >> (\S+) - "\w+\s+\w+|\w+\s+\w+\s+\w+\.". > >> srcuser, status > >> > >> > >> then add the following to local_rules.xml (tailor to your specific > needs). > >> > >> > >> > >> pfsvc-auth > >> Phone Factor Authentication app group. > >> > >> > >> 100140 > >> FAILED_SMS_OTP_INCORRECT > >> User Failed SMS Challenge/Response > >> > >> > >> > >> --end local_rules.xml > > > > -- > > > > --- > > You received this message because you are subscribed to the Google > Groups > > "ossec-list" group. > > To unsubscribe from this group and stop receiving emails from it, send > an > > email to ossec-list+...@googlegroups.com . > > For more options, visit https://groups.google.com/d/optout. > -- --- You received this message because you are subscribed to the Google Groups "ossec-list" group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ossec-list] Juniper SSG > OSSEC via syslog
On Thu, 4 Dec 2014, dan (ddp) wrote: On Wed, Dec 3, 2014 at 7:51 PM, Jarrod Farncomb wrote: Hi guys, I have some Juniper SSG devices which I need log in events to be reported to OSSEC so that they can be included within the daily report. From my research, the Juniper SSGs will specifc the OSSEC server as their syslog server so that syslog messages are sent to the OSSEC server. My question is, what configuration is required on the OSSEC server in order for it to correctly listen for these events, log them, and report them? As this isn't an agent or agentless client I'm not sure what configuration is required so that OSSEC knows which device is sending the messages in and what to do with them for instance. I like using a syslog daemon to accept the log messages, and just have OSSEC read the log files on the system. Other people prefer to use OSSEC's syslog support. http://ossec-docs.readthedocs.org/en/latest/syntax/head_ossec_config.remote.html#element-connection does ossec have the ability to listen to stdin rather than having to write the logs to a file and have ossec scrape them? I'm looking to avoid having to worry about disk space for this sort of config. David Lang
[ossec-list] Re: Monitoring ASA - Agentless
I think dan mentioned it all - but basically... Run the register_host.sh and plug in your username@host password enablepassword Step 1 e.g. ./register_host.sh ciscouser@1.2.3.4 password enablepassword Steps 2 and 3 in your list are incorrect. Delete those... Edit the ossec.conf and add/edit section e.g. ssh_pixconfig_diff 36000 ciscouser@1.2.3.4 periodic_diff Then restart ossec. /var/ossec/bin/ossec-control -restart Someone also mentioned syslog to capture all the setup and teardowns... along with other useful information. I highly recommend configuring that as well!!! Good luck! Let us know how you are doing!! On Monday, December 8, 2014 8:55:30 AM UTC-8, Semperfi wrote: > Hello; > > I would like to monitor our ASA 5510. Is there any documentation or > tutorial on monitoring an ASA ? > > I have found limited information and my understading. > > > > 1)I have to edit the register_host.sh, add the host.: if > so, Where? > > 2)edit ssh_asa-fwsmconfig_diff, with the password: is this > the SNMP pwd ? > > 3)Run ssh_asa-fwsmconfig_diff within \ossec > > > > Is this basically all there is to be done? > > > > Thank you for your help > > > On Monday, December 8, 2014 8:55:30 AM UTC-8, Semperfi wrote: > > Hello; > > I would like to monitor our ASA 5510. Is there any documentation or > tutorial on monitoring an ASA ? > > I have found limited information and my understading. > > > > 1)I have to edit the register_host.sh, add the host.: if > so, Where? > > 2)edit ssh_asa-fwsmconfig_diff, with the password: is this > the SNMP pwd ? > > 3)Run ssh_asa-fwsmconfig_diff within \ossec > > > > Is this basically all there is to be done? > > > > Thank you for your help > > > -- --- You received this message because you are subscribed to the Google Groups "ossec-list" group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ossec-list] Juniper SSG > OSSEC via syslog
> I'm looking to avoid having to worry about disk space for this sort of > config. > > You must be joking? Disk space is _very_ cheap nowadays and it's also possible to use compression .. -- Eero -- --- You received this message because you are subscribed to the Google Groups "ossec-list" group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ossec-list] Juniper SSG > OSSEC via syslog
David, Eero is right that disk space is relatively quite inexpensive these days; I think lots of us are more concerned with log retention against future audit needs than with disk usage. Anyway, it's pretty easy to set up cron scripts for log file cleanups. To address your question, I don't think we have a STDIN; maybe you would be more interested to have OSSEC receive the syslog directly instead of "buffering" it through the regular syslogd. thanks; Rick On Monday, December 8, 2014 5:26:05 PM UTC-5, Eero Volotinen wrote: > > > > >> I'm looking to avoid having to worry about disk space for this sort of >> config. >> >> > You must be joking? Disk space is _very_ cheap nowadays and it's also > possible to use compression .. > > -- > Eero > > -- --- You received this message because you are subscribed to the Google Groups "ossec-list" group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ossec-list] Juniper SSG > OSSEC via syslog
On Mon, 8 Dec 2014, Rick McClinton wrote: David, Eero is right that disk space is relatively quite inexpensive these days; I think lots of us are more concerned with log retention against future audit needs than with disk usage. Anyway, it's pretty easy to set up cron scripts for log file cleanups. disk space is cheap, but I have something else archiving the logs, I don't need to do it on the ossec box as well. This just ends up causing additional I/O and eating additional cpu for no benefit. To address your question, I don't think we have a STDIN; maybe you would be more interested to have OSSEC receive the syslog directly instead of "buffering" it through the regular syslogd. the question is, do I trust the OSSEC implementation of syslog or the rsyslog implementation of syslog? :-) I know that rsyslog can keep up with several hundred thousand logs/sec (well past gig-E wire speed). I'd rather have rsyslog handling the full stream and only feed the portion that needs to go to OSSEC to the ossec process. I'm coming from the point of view that I have a very large volume of logs and have farms of servers processing them, with different sets of servers for different types of work. David Lang
Re: [ossec-list] Juniper SSG > OSSEC via syslog
On Tue, 9 Dec 2014, Eero Volotinen wrote: I'm looking to avoid having to worry about disk space for this sort of config. You must be joking? Disk space is _very_ cheap nowadays and it's also possible to use compression .. Unless you are using "enterprise class" datacenter storage systems. you would be horrified at what NetApp and EMC are able to charge for storage. David Lang
[ossec-list] Src IP first character truncated
Hey all, bit of a strange issue here.. If I log in/out of a server the event will be logged into the alerts.log file perfectly fine, but when viewing the logs in a browser through the web interface the Src IP field lists the username but it does so incorrectly, it appears that the first character is always truncated and does not display. This only happens when outputting to the web page, the name in full correctly displays in the alerts.log file so I'm thinking it's to do with the parsing/regex of the alerts.log file, though I am not sure where and have not been able to see where Src IP is doing this? I thought it'd have been srcuser displayed but the name with the first letter missing always shows on Src IP? -- --- You received this message because you are subscribed to the Google Groups "ossec-list" group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[ossec-list] Windows login failure event 4625 not logging
I'm having an issue getting failed logins to Windows servers to log correctly to alerts.log. I've created a log in fail and confirmed the Windows event logs show this as ID 4625. Checking in the rules directory on the OSSEC server this appears within the field of the msauth rule file (ID 18106), however it doesn't actually seem to detect or log it to alerts.log. What needs to be changed? When I run ossec-logtest and put the ID 4625 in it says that no rules have been applied, despite there already being one that appears to match it. -- --- You received this message because you are subscribed to the Google Groups "ossec-list" group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
