Right, I'm pointing out here that there is a line limitation on ossec
emailing of result output. You're saying that the rule processing must
have a limitation shorter as permissions on files beginning with D are
not alerting.

I added it to the thread because it is relevant that there are several
"line number limitations" (your subject line) around command output
monitoring.

Hope that adds clarity to those watching.

On Jan 4, 5:58 am, alsdks <als...@gmail.com> wrote:
> BP9906 I do not have an issue with a netstat command . Please read
> again my first post .
> I was asking if there is a limitation to a command's output in how
> many lines can it be .
>
> The conclusion is that there is definetelly a line number limitation
> which restricts the use of commands that their output is big.Whether
> this limitation can be
> modified or not , I do not know .
>
> Anyway if you want to continue your case with netstat email output
> please open another thread.
>
> Thank you
>
> On Jan 4, 3:30 pm, "dan (ddp)" <ddp...@gmail.com> wrote:
>
>
>
>
>
>
>
> > On Tue, Jan 3, 2012 at 6:21 PM, BP9906 <crazi...@gmail.com> wrote:
> > > Try putting this into your agent.conf file on the ossec server for
> > > your Windows machine(s). Its a good test if you do it against a
> > > machine with many ports open. Perhaps you could setup a Windows DC to
> > > test with?
>
> > That's out of my budget at the moment.
>
> > >  <localfile>
> > >    <log_format>full_command</log_format>
> > >    <command>netstat -anp tcp | find "LISTEN" | find /V "127.0.0.1"</
> > > command>
> > >  </localfile>
>
> > > Use this rule in your local_rules.xml:
>
> > >  <rule id="140001" level="7">
> > >    <if_sid>530</if_sid>
> > >    <regex>ossec: output:\.*netstat -an</regex>
> > >    <check_diff />
> > >    <description>Listened ports have changed.</description>
> > >  </rule>
>
> > > For internal-options.conf, I have the following maild options set:
>
> > > maild.strict_checking=1
> > > maild.groupping=0
> > > maild.full_subject=1
>
> > > Thank you.
>
> > > On Dec 22 2011, 5:49 am, "dan (ddp)" <ddp...@gmail.com> wrote:
> > >> On Thu, Dec 22, 2011 at 4:59 AM, alsdks <als...@gmail.com> wrote:
> > >> > Hi Dan,
>
> > >> > So it seems that the output is chopped off before it gets to the
> > >> > manager .The limitation on ossec agent ?
>
> > >> > Thank you
>
> > >> There are conflicting reports on this, so it's up to me to test it.
> > >> When I find time and interest.
>
> > >> > On Dec 20, 11:34 pm, BP9906 <crazi...@gmail.com> wrote:
> > >> >> Ah yes, I see what you're talking about now, but I can see from the
> > >> >> alerts.log file that it does contain the whole output current and
> > >> >> previous. Seems like email isnt getting the whole thing in the body.
>
> > >> >> On Dec 20, 11:09 am, "dan (ddp)" <ddp...@gmail.com> wrote:
>
> > >> >> > On Tue, Dec 20, 2011 at 1:57 PM, BP9906 <crazi...@gmail.com> wrote:
> > >> >> > > So what does logall do? How does that relate to the email getting
> > >> >> > > chopped off?
>
> > >> >> > The idea was to see if the output is chopped off before it gets to 
> > >> >> > the
> > >> >> > manager or after.
>
> > >> >> >http://www.ossec.net/doc/syntax/head_ossec_config.global.html#element...
>
> > >> >> > > On Dec 20, 9:01 am, "dan (ddp)" <ddp...@gmail.com> wrote:
> > >> >> > >> On Tue, Dec 20, 2011 at 11:52 AM, BP9906 <crazi...@gmail.com> 
> > >> >> > >> wrote:
> > >> >> > >> > The alerts.log contains both the output and previous output. 
> > >> >> > >> > The email
> > >> >> > >> > does not.
>
> > >> >> > >> > Whats the log_all option you refer to? I couldnt find any 
> > >> >> > >> > reference to
> > >> >> > >> > it online.
>
> > >> >> > >> I meant logall. I apparently get those mixed up.
>
> > >> >> > >> > On Dec 19, 4:36 pm, "dan (ddp)" <ddp...@gmail.com> wrote:
> > >> >> > >> >> On Mon, Dec 19, 2011 at 6:46 PM, BP9906 <crazi...@gmail.com> 
> > >> >> > >> >> wrote:
> > >> >> > >> >> > When I get email alerts for mine, I only get back 20 lines 
> > >> >> > >> >> > back. Seems
> > >> >> > >> >> > to be hard coded.
>
> > >> >> > >> >> > As an example, monitoring listened ports:
>
> > >> >> > >> >> > ossec: output: 'netstat -anp tcp | find "LISTEN" | find /V
> > >> >> > >> >> > "127.0.0.1"':
> > >> >> > >> >> >  TCP    0.0.0.0:80             0.0.0.0:0              
> > >> >> > >> >> > LISTENING
> > >> >> > >> >> >  TCP    0.0.0.0:135            0.0.0.0:0              
> > >> >> > >> >> > LISTENING
> > >> >> > >> >> >  TCP    0.0.0.0:443            0.0.0.0:0              
> > >> >> > >> >> > LISTENING
> > >> >> > >> >> >  TCP    0.0.0.0:445            0.0.0.0:0              
> > >> >> > >> >> > LISTENING
> > >> >> > >> >> >  TCP    0.0.0.0:513            0.0.0.0:0              
> > >> >> > >> >> > LISTENING
> > >> >> > >> >> >  TCP    0.0.0.0:2201           0.0.0.0:0              
> > >> >> > >> >> > LISTENING
> > >> >> > >> >> >  TCP    0.0.0.0:2481           0.0.0.0:0              
> > >> >> > >> >> > LISTENING
> > >> >> > >> >> >  TCP    0.0.0.0:3588           0.0.0.0:0              
> > >> >> > >> >> > LISTENING
> > >> >> > >> >> >  TCP    0.0.0.0:3389           0.0.0.0:0              
> > >> >> > >> >> > LISTENING
> > >> >> > >> >> >  TCP    0.0.0.0:5657           0.0.0.0:0              
> > >> >> > >> >> > LISTENING
> > >> >> > >> >> >  TCP    0.0.0.0:8779           0.0.0.0:0              
> > >> >> > >> >> > LISTENING
> > >> >> > >> >> >  TCP    0.0.0.0:9871           0.0.0.0:0              
> > >> >> > >> >> > LISTENING
> > >> >> > >> >> >  TCP    0.0.0.0:47001          0.0.0.0:0              
> > >> >> > >> >> > LISTENING
> > >> >> > >> >> >  TCP    0.0.0.0:49152          0.0.0.0:0              
> > >> >> > >> >> > LISTENING
> > >> >> > >> >> >  TCP    0.0.0.0:49153          0.0.0.0:0              
> > >> >> > >> >> > LISTENING
> > >> >> > >> >> >  TCP    0.0.0.0:49154          0.0.0.0:0              
> > >> >> > >> >> > LISTENING
> > >> >> > >> >> >  TCP    0.0.0.0:49155          0.0.0.0:0              
> > >> >> > >> >> > LISTENING
> > >> >> > >> >> >  TCP    0.0.0.0:49163          0.0.0.0:0
> > >> >> > >> >> > Previous output:
>
> > >> >> > >> >> >  --END OF NOTIFICATION
>
> > >> >> > >> >> How many lines are passed back to the manager? (hint: use 
> > >> >> > >> >> log_all)
>
> > >> >> > >> >> > On Dec 16, 11:30 am, "dan (ddp)" <ddp...@gmail.com> wrote:
> > >> >> > >> >> >> How many lines do you get back exactly?
>
> > >> >> > >> >> >> On Tue, Dec 13, 2011 at 9:05 PM, alsdks <als...@gmail.com> 
> > >> >> > >> >> >> wrote:
> > >> >> > >> >> >> > Hello,
>
> > >> >> > >> >> >> > I have set up a command to monitor file permissions in 
> > >> >> > >> >> >> > Windows (Since
> > >> >> > >> >> >> > by default Ossec only supports POSIX ). The command for 
> > >> >> > >> >> >> > example is :
>
> > >> >> > >> >> >> > <localfile>
> > >> >> > >> >> >> >    <log_format>full_command</log_format>
> > >> >> > >> >> >> >    <command>icacls c:\WINDOWS\system32\*.exe</command>
> > >> >> > >> >> >> >    <alias>icacls</alias>
> > >> >> > >> >> >> >  </localfile>
>
> > >> >> > >> >> >> > Now the question: is there a limitation how many lines 
> > >> >> > >> >> >> > can OSSEC take
> > >> >> > >> >> >> > and process as the output of a command ?Because I seem 
> > >> >> > >> >> >> > to be getting
> > >> >> > >> >> >> > only up to  letter c of the executables located in that 
> > >> >> > >> >> >> > dir.
>
> > >> >> > >> >> >> > Thank you !

Reply via email to