Using the drawing from https://docs.zeek.org/en/current/cluster/ as
reference, I have some workers which are being used for other tasks. As
such, I would like to offload as much as I can to the proxies as I can
build them to fit my needs instead of just riding on an already running
server (the workers). How can I tune the analysis done at worker vs the
proxy to fit my need?
Hi,
I'm using Zeek for quite some time now and I must say that it is one of the
best IDSs out there today. Thanks a lot for a the hard work!!
I know and use Zeek's ability to extract mysql commands, users, rows count
and status from the network traffic. Is it possible to do the same for
PostgreSQL? If not, how complicated do you think it would be for me to
implement it?
Thanks in advance,
Yuval.
Hi all.
After update my Zeek 3.0.7 cluster to 3.0.8, when I try to make “zeekctl deploy” the following error is returned:
checking configurations ...
logger scripts failed.
fatal error in /opt/zeek/share/zeek/site/packages/__load__.zeek, line 4: can't find ./bro-doctor
manager scripts failed.
fatal error in /opt/zeek/share/zeek/site/packages/__load__.zeek, line 4: can't find ./bro-doctor
proxy scripts failed.
fatal error in /opt/zeek/share/zeek/site/packages/__load__.zeek, line 4: can't find ./bro-doctor
idps-prod-dmz scripts failed.
fatal error in /opt/zeek/share/zeek/site/packages/__load__.zeek, line 4: can't find ./bro-doctor
This error seems to be for 3.0.8, because in 3.0.7 works without problems. Comparing packages.zeek file between 3.0.7 and 3.0.8, there is one difference:
3.0.8:
# WARNING: This file is managed by zkg.
# Do not make direct modifications here.
@load ./add-node-names
@load ./bro-doctor
@load ./dovehawk
@load ./hassh
@load ./ja3
@load ./zeek-af_packet-plugin
@load ./zeek-community-id
3.0.7:
# WARNING: This file is managed by zkg.
# Do not make direct modifications here.
@load ./add-node-names
@load ./dovehawk
@load ./hassh
@load ./ja3
@load ./zeek-af_packet-plugin
@load ./zeek-community-id
As you can see there is no an entry for bro-doctor … And it makes sense … In zeek 3.1.4 packages.zeek is configured as in 3.0.7 …
Any idea?
Regards,
C. L. Martinez
Just a reminder that tomorrow's (29 July from 2-3pm Eastern) Zeek From Home
Webinar is about JA3 and will be hosted by Jeff Atkinson one of the authors
of JA3.
Jeff will be going over a review of JA3 TLS fingerprinting and how to use
it better. Reminders, warnings and applying the fingerprint technique to
SSH and Remote Desktop.
Registration link -
https://corelight.zoom.us/webinar/register/WN_Gjh6eHImT56SUHP6XSs7BA
Thanks,
~Amber
Hi everyone,
The move is now done and all functionality should work as before.
The user-interface for the mailing lists, and the archives are now
located at https://lists.zeek.org
If you notice anything amiss - please let me know.
Johanna
On 22 Jul 2020, at 11:36, Johanna Amann wrote:
> Hello everyone,
>
> We are going to switch the zeek.org mailing lists to a new provider on
> Monday the 27th. This change means that the domain-part of all
> zeek.org
> mailing lists is going to change from “zeek.org” to
> “lists.zeek.org”.
>
> What changes does this entail / what does this mean for you:
>
> * All zeek.org mailing list domains will switch to lists.zeek.org. So,
> “zeek(a)zeek.xn--org-9o0a will be “zeek(a)lists.zeek.xn--org-9o0a afterwards.
> However, you will still be able to send messages to the old list
> address for the foreseeable future - they will automatically be
> forwarded to the new address
> If you are using mailing list filters to automatically sort Zeek
> mailing lists into folders, you will probably have to update them.
>
> * The mailing list archives and administrative interface will move to
> https://lists.zeek.org/. The old interface at
> http://mailman.icsi.berkeley.edu/mailman/listinfo will no longer be
> available; archives will also no longer be available at the old
> address.
>
> * Your subscription will automatically move, you do not have to take
> any
> action.
>
> When will this happen:
>
> * This change will happen on Monday the 27th of July, starting at
> approximately 9am PDT/noon EDT/4pm GMT/5pm BST/6pm CEST.
> Messages sent to the Zeek mailing lists during this time will be
> held. We will try to make sure that any messages that happen to be
> sent
> during this timeframe will make it over after the migration, but your
> message will probably make it faster if you wait till we are done.
>
> * The change will take a few hours; I will send another message to the
> individual lists once migration is done.
>
> Why are we moving the mailing lists:
>
> The current setup that we are using is being retired and we have to
> switch to a new provider. We are switching to a new domain because
> this
> makes our setup easier to maintain.
>
> If you have any questions or concerns, please let me know.
>
> Johanna
> _______________________________________________
> Zeek-Announce mailing list
> Zeek-Announce(a)zeek.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/zeek-announce
files, our CPU utilization is generally 99%, and the packet filter seems
to be dropping a high percentage of packets.
We are going to re-design our Bro architecture and are seeking
recommendations for hardware and OS.
We are currently considering running FreeBSD 6.0 instead of RedHat if that
will provide better performance.
We are also considering splitting the collecting and initial log creation
from the subsequent log processing we perform to retain data in our
database. We suspect we will need stronger machines for the initial
collection/log creation than for the subsequent processing, which is
primarily parsing the various log files.
We are looking at Sun Fire X4100 servers with our existing SK-9844 cards
for the "collector" systems. However, it appears that we cannot run
FreeBSD on the X4100 machines due a lack of support for the LSI SAS
(serial attached SCSI) HBA. So, we would instead keep RedHat.
As an alternative, we could use Sun Fire X2100 servers with SK-9E92 cards
for the collectors, running FreeBSD, as long as these would provide
sufficient performance.
We may run 4 collector machines, each listening to its own tap.
We were also thinking of using the Sun Fire X2100s for the secondary log
parsing.
I suppose our questions are:
1) Which OS should we use - FreeBSD or RedHat?
2) Can anyone recommend using the Sun Fire X2100s or X4100s?
3) Does anyone have advice regarding the Syskonnect SK-9844 or SK-9E92 cards?
4) Is it reasonable to assume that the most intensive part of this process
is the initial collection and analysis by Bro which results in the various
Bro log files?
5) Are there other hardware or OS recommendations?
I'm sure I omitting something, but this is a good start.
Thanks in advance for your advice!
Joncarlo Ruggieri
University of CA, Davis
Data Center & Client Services
jruggieri(a)ucdavis.edu
The SACK option is advisory, in that, while it notifies the data
sender that the data receiver has received the indicated segments,
the data receiver is permitted to later discard data which have been
reported in a SACK option.
- Vern
