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)" <[email protected]> wrote: > On Tue, Jan 3, 2012 at 6:21 PM, BP9906 <[email protected]> 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)" <[email protected]> wrote: > >> On Thu, Dec 22, 2011 at 4:59 AM, alsdks <[email protected]> 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 <[email protected]> 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)" <[email protected]> wrote: > > >> >> > On Tue, Dec 20, 2011 at 1:57 PM, BP9906 <[email protected]> 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)" <[email protected]> wrote: > >> >> > >> On Tue, Dec 20, 2011 at 11:52 AM, BP9906 <[email protected]> > >> >> > >> 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)" <[email protected]> wrote: > >> >> > >> >> On Mon, Dec 19, 2011 at 6:46 PM, BP9906 <[email protected]> > >> >> > >> >> 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)" <[email protected]> wrote: > >> >> > >> >> >> How many lines do you get back exactly? > > >> >> > >> >> >> On Tue, Dec 13, 2011 at 9:05 PM, alsdks <[email protected]> > >> >> > >> >> >> 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 !
