Re: [Bro-Dev] current_time() vs network_time()
> On Nov 19, 2015, at 6:12 PM, Vern Paxson wrote:
>
> In any case, I agree that Craig's proposed fix is a good way to deal
> with this. In addtion, I think this points up the utility of Bro
> providing cron-style event scheduling in addition to relative-time
> scheduling.
I actually have a plugin mostly working that does this called approxidate.
https://github.com/sethhall/bro-approxidate
It lets you write code like this...
schedule approxidate("tomorrow at 8pm EDT”) { some_event() };
.Seth
--
Seth Hall
International Computer Science Institute
(Bro) because everyone has a network
http://www.bro.org/
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
Re: [Bro-Dev] current_time() vs network_time()
For the script you sent me, the 1-second skips aren't that surprising. Bro's "schedule" sets a minimum time in the future for when the event will occur. The actual time will be a tad later, depending on how long it takes the event engine to process the buffer of packets that leads to the clock advancing past the scheduled time. So for example if at network time 1.95 you schedule an event for one second in the future, that won't be looked at until a set of packets arrives for which one of them has a network time of >= 2.95. Those packets will first be processed before doing the scheduled event. In addition, network-time will lag current-time by an amount proportional to the packet capture buffer. If the buffer is a few hundred msec's worth, then you will not infrequently get a mismatch regarding times of one-second granularity. OTOH, this: > Report time is 1447869607.383869, report hour is 10:0:7 > Report time is 1447869617.52706, report hour is 10:0:17 <- big jump is definitely not good. I'm not seeing how your script could lead to that behavior other than the event engine going away (= spending time processing packets) for around 10 seconds. Regarding this: > Report time is 1447869618.188414, report hour is 10:0:18 > Report time is 1447869619.04252, report hour is 10:0:19 <- stall ? > Report time is 1447869619.733979, report hour is 10:0:19 <--- stall ? I can at least construct a theory. Suppose the event was supposed to happen at 10:0:18.8. A packet comes in with that network time, so the event fires, but only 200 msec later, so current-time shows 10:0:19. The script schedules based on network-time rather than current-time, so it'll set the next event for 10:0:19.8. When that packet arrives, there's less to process, so the script runs before the current-time advances to 10:0:20. In any case, I agree that Craig's proposed fix is a good way to deal with this. In addtion, I think this points up the utility of Bro providing cron-style event scheduling in addition to relative-time scheduling. Vern ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
Re: [Bro-Dev] current_time() vs network_time()
> I'm not sure what you have available but to generate the unix timestamp
> I would use localtime() or gmtime() (using gmtime() avoids daylight
Here is the function I am now using (sharing - might be useful to improve upon)
Index: ../../all-check.bro
===
--- ../../all-check.bro (revision 819)
+++ ../../all-check.bro (working copy)
+function next_report_time():time
+{
+ local kv_splitter: pattern = /[\ \t]+/;
+local one_space: string = " ";
+ local _report_hours: vector of count = {0, 10, 12, 14, 16, 23};
+
+ local t = current_time();
+ local _now_h = to_count(strftime("%H", t));
+
+ local _next_report_hour : count = 0 ;
+
+ for (h in _report_hours)
+ {
+ print fmt ("now_h is %s, H is %s", _now_h, _report_hours[h]) ;
+ if (_now_h < _report_hours[h])
+ {
+ _next_report_hour = _report_hours[h] ; break;
+ }
+ }
+
+ local t_year = strftime("%Y",t);
+ local t_zone = strftime("%Z",t);
+ local zone_year_month_day = strftime("%Z %Y %b %d", t);
+
+ local _hour = _next_report_hour ;
+ local _min = "00" ;
+ local _sec = "00" ;
+
+ local _t_string = fmt ("%s %s:%s:%s", zone_year_month_day,
_hour,_min,_sec );
+
+ local _next_report_time = fmt ("time is : %s, %s", strftime("%Z %Y %b
%d %T", t), _t_string) ;
+
+ local parse_string: string = "%Z %Y %b %d %H:%M:%S";
+ local date_mod = fmt("%s", _t_string);
+ local date_mod_p = gsub(date_mod, kv_splitter, one_space);
+ local ret_val = strptime(parse_string, date_mod_p);
+
+ return ret_val ;
+}
+
And then basically:
event bro_init() &priority=10
{
+ nrt = next_report_time() ;
}
event report_allcheck()
{
+ #if((report_hour == 0 || report_hour == 10 || report_hour == 12 ||
report_hour == 14
+ ##|| report_hour == 16 || report_hour == 23) &&
report_min == 0 && report_sec == 0)
+
+if (current_time() > nrt)
{
+ nrt = next_report_time();
}
}
On Wed, Nov 18, 2015 at 11:34:39AM -0800, Craig Leres wrote:
> On 11/18/2015 10:58 AM, Aashish Sharma wrote:
> > So, I am trying to have bro send me report/alerts at specific timeslots.
> >
> > Given current_time is the wall-clock time, I am relying on current_time()
> > function to get time and then, my code is : if (hh:mm:ss == desired time),
> > run a report.
>
> My recommendation for how to implement this would be to calculate a unix
> timestamp (seconds since 1970) that corresponds to the next time you
> want send a report and then poll for when time() is >= this value. After
> sending the report, calculate the next timestamp.
>
> I'm not sure what you have available but to generate the unix timestamp
> I would use localtime() or gmtime() (using gmtime() avoids daylight
> saving time issues) to break out the fields, set the H, M and S to the
> desired values and then use mktime() (or timegm()) to convert back to a
> unix timestamp.
>
> Craig
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
[Bro-Dev] [JIRA] (BIT-1511) BroControl unable to recognize adr in ifconfig
[ https://bro-tracker.atlassian.net/browse/BIT-1511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=22904#comment-22904 ] Nicolas Merle commented on BIT-1511: eth0 Link encap:Ethernet HWaddr 00:22:19:5a:65:7d inet adr:192.168.102.238 Bcast:192.168.102.255 Masque:255.255.255.0 adr inet6: fe80::222:19ff:fe5a:657d/64 Scope:Lien UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:3432444 errors:0 dropped:0 overruns:0 frame:0 TX packets:3434353 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 lg file transmission:1000 RX bytes:302265646 (288.2 MiB) TX bytes:848376555 (809.0 MiB) eth1 Link encap:Ethernet HWaddr 00:22:19:5a:65:7f inet adr:192.168.103.200 Bcast:192.168.103.255 Masque:255.255.255.0 UP BROADCAST RUNNING NOARP PROMISC MULTICAST MTU:1500 Metric:1 RX packets:16163355404 errors:0 dropped:85 overruns:0 frame:0 TX packets:8297 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 lg file transmission:1000 RX bytes:13468131399162 (12.2 TiB) TX bytes:3867134 (3.6 MiB) eth2 Link encap:Ethernet HWaddr 00:15:17:b2:5f:d8 BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 lg file transmission:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) Interruption:16 Mémoire:fc3e-fc40 eth3 Link encap:Ethernet HWaddr 00:15:17:b2:5f:d9 BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 lg file transmission:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) Interruption:17 Mémoire:fc3a-fc3c eth0.111 Link encap:Ethernet HWaddr 00:22:19:5a:65:7d inet adr:192.168.111.238 Bcast:192.168.111.255 Masque:255.255.255.0 adr inet6: fe80::222:19ff:fe5a:657d/64 Scope:Lien UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:2 errors:0 dropped:0 overruns:0 frame:0 TX packets:2940 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 lg file transmission:0 RX bytes:92 (92.0 B) TX bytes:286263 (279.5 KiB) loLink encap:Boucle locale inet adr:127.0.0.1 Masque:255.0.0.0 adr inet6: ::1/128 Scope:Hôte UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:65514313 errors:0 dropped:0 overruns:0 frame:0 TX packets:65514313 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 lg file transmission:0 RX bytes:168200729284 (156.6 GiB) TX bytes:168200729284 (156.6 GiB) > BroControl unable to recognize adr in ifconfig > -- > > Key: BIT-1511 > URL: https://bro-tracker.atlassian.net/browse/BIT-1511 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BroControl >Affects Versions: 2.3 > Environment: Linux 3.16.0-4-amd64 #1 SMP Debian > 3.16.7-ckt11-1+deb8u6 (2015-11-09) x86_64 GNU/Linux Debian Jessie >Reporter: Nicolas Merle > Labels: broctl, ifconfig > > Since recently, ifconfig in debian show ip address starting with "adr" and > not "addr" as before and so when using ''BroCtl check'' in a local cluster > configuration, it doesn't work and you get the error : "Error: must run > broctl only on manager node broctl check" -- This message was sent by Atlassian JIRA (v7.0.0-OD-08-005#70107) ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
[Bro-Dev] Brokerization of iSSHD
I’m checking to see if anyone is already working on converting the ssllogmux script used by iSSHD to use Broker? I don’t think the corresponding bro scripts will need to be updated unless they are using &synchronized, right? :Adam -- Adam J. Slagell Chief Information Security Officer Director, Cybersecurity Division National Center for Supercomputing Applications University of Illinois at Urbana-Champaign www.slagell.info "Under the Illinois Freedom of Information Act (FOIA), any written communication to or from University employees regarding University business is a public record and may be subject to public disclosure." ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
[Bro-Dev] [JIRA] (BIT-1511) BroControl unable to recognize adr in ifconfig
[ https://bro-tracker.atlassian.net/browse/BIT-1511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=22903#comment-22903 ] Daniel Thayer commented on BIT-1511: I've just updated to debian 8.2, and I cannot reproduce this problem. What does the output of "/sbin/ifconfig -a" look like on your system? > BroControl unable to recognize adr in ifconfig > -- > > Key: BIT-1511 > URL: https://bro-tracker.atlassian.net/browse/BIT-1511 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BroControl >Affects Versions: 2.3 > Environment: Linux 3.16.0-4-amd64 #1 SMP Debian > 3.16.7-ckt11-1+deb8u6 (2015-11-09) x86_64 GNU/Linux Debian Jessie >Reporter: Nicolas Merle > Labels: broctl, ifconfig > > Since recently, ifconfig in debian show ip address starting with "adr" and > not "addr" as before and so when using ''BroCtl check'' in a local cluster > configuration, it doesn't work and you get the error : "Error: must run > broctl only on manager node broctl check" -- This message was sent by Atlassian JIRA (v7.0.0-OD-08-005#70107) ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
[Bro-Dev] [Auto] Merge Status
Open Merge Requests === IDComponentReporter Assignee Updated For Version PrioritySummary --- - -- - -- - BIT-1489 [1] BroControl Daniel Thayer Justin Azoff 2015-10-07 2.5 Normal topic/dnthayer/ticket1396 [2] Open GitHub Pull Requests = IssueComponentUser Updated Title --- --- -- #46 [3] bro albertzaharovits [4] 2015-11-03 HTTP Content-Disposition header updates filename field in HTTP::Info [5] #1 [6] broctl J-Gras [7]2015-10-24 Added support for Pcap options [8] #2 [9] btestfabaff [10] 2015-11-15 Update to match PEP3110 [11] [1] BIT-1489 https://bro-tracker.atlassian.net/browse/BIT-1489 [2] ticket1396 https://github.com/bro/brocontrol/tree/topic/dnthayer/ticket1396 [3] Pull Request #46 https://github.com/bro/bro/pull/46 [4] albertzaharovits https://github.com/albertzaharovits [5] Merge Pull Request #46 with git pull --no-ff --no-commit https://github.com/albertzaharovits/bro.git master [6] Pull Request #1 https://github.com/bro/broctl/pull/1 [7] J-Gras https://github.com/J-Gras [8] Merge Pull Request #1 with git pull --no-ff --no-commit https://github.com/J-Gras/broctl.git topic/jgras/pcap-config [9] Pull Request #2 https://github.com/bro/btest/pull/2 [10] fabaff https://github.com/fabaff [11] Merge Pull Request #2 with git pull --no-ff --no-commit https://github.com/fabaff/btest.git master ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
