[Oisf-users] Suricata using 35% cpu with no load?
Duane Howard
duane.security at gmail.com
Fri Jul 31 17:39:42 UTC 2015
Just build 2.1beta4 and it's the same thing.
On Fri, Jul 31, 2015 at 10:22 AM, Duane Howard <duane.security at gmail.com>
wrote:
> yaml sent off list. This is the only machine I've tried on right now, and
> I can't use the other one that is similarly configured because it's being
> used for other stuff at the moment. I did pretty extensive experimentation
> with 2.0.6 a while back on hardware and didn't see this issue. I'll try
> installing 2.1 and playing with it later today to see if I can reproduce
> that way.
>
> On Fri, Jul 31, 2015 at 6:47 AM, Peter Manev <petermanev at gmail.com> wrote:
>
>> On Thu, Jul 30, 2015 at 11:27 PM, Duane Howard <duane.security at gmail.com>
>> wrote:
>> > strace only shows the process doing constant:
>> > nanosleep({0, 10000000}, NULL) = 0
>> > nanosleep({0, 10000000}, NULL) = 0
>> > nanosleep({0, 10000000}, NULL) = 0
>> > nanosleep({0, 10000000}, NULL) = 0
>> > nanosleep({0, 10000000}, NULL) = 0
>> > nanosleep({0, 10000000}, NULL) = 0
>> > ....
>> >
>>
>> Hmm strange. I have not experianced that before.
>> Does this happen on any VM or just this one in particular?
>> Can you switch to 2.1beta4 and see if any difference. Please feel free
>> to send me your suricata.yaml if you would like - I can see if this is
>> enough to reproduce the issue.
>>
>> thanks
>>
>>
>> >
>> > On Thu, Jul 30, 2015 at 2:17 PM, Duane Howard <duane.security at gmail.com
>> >
>> > wrote:
>> >>
>> >> I can reproduce. I ran it on a single low volume real NIC with the same
>> >> result. Nothing terribly interesting in suricata.log with -vv enabled:
>> >> Here's the logs after rule and config loading:
>> >>
>> >> 30/7/2015 -- 21:14:06 - <Info> - Core dump size set to unlimited.
>> >> 30/7/2015 -- 21:14:06 - <Info> - Unified2-alert initialized: filename
>> >> suricata.u2, limit 128 MB
>> >> 30/7/2015 -- 21:14:06 - <Info> - Syslog output initialized
>> >> 30/7/2015 -- 21:14:06 - <Info> - Unable to find af-packet config for
>> >> interface "eth0" or "default", using default value
>> >> 30/7/2015 -- 21:14:06 - <Info> - Going to use 1 thread(s)
>> >> 30/7/2015 -- 21:14:06 - <Info> - Enabling zero copy mode
>> >> 30/7/2015 -- 21:14:06 - <Info> - RunModeIdsAFPWorkers initialised
>> >> 30/7/2015 -- 21:14:06 - <Notice> - all 1 packet processing threads, 3
>> >> management threads initialized, engine started.
>> >> 30/7/2015 -- 21:14:06 - <Info> - Using interface 'eth0' via socket 7
>> >> 30/7/2015 -- 21:14:06 - <Info> - All AFP capture threads are running.
>> >> 30/7/2015 -- 21:14:06 - <Info> - Thread AFPacketeth01 using socket 7
>> >> 30/7/2015 -- 21:14:06 - <Info> - Starting to read on AFPacketeth01
>> >> ^C30/7/2015 -- 21:15:27 - <Notice> - Signal Received. Stopping engine.
>> >> 30/7/2015 -- 21:15:27 - <Info> - 0 new flows, 0 established flows were
>> >> timed out, 0 flows in closed state
>> >> 30/7/2015 -- 21:15:28 - <Info> - time elapsed 81.925s
>> >> 30/7/2015 -- 21:15:28 - <Info> - (AFPacketeth01) Kernel: Packets 3372,
>> >> dropped 0
>> >> 30/7/2015 -- 21:15:28 - <Info> - (AFPacketeth01) Packets 3345, bytes
>> >> 1318862
>> >> 30/7/2015 -- 21:15:28 - <Info> - Stream TCP processed 2723 TCP packets
>> >> 30/7/2015 -- 21:15:28 - <Info> - (AFPacketeth01) Alerts 0
>> >> 30/7/2015 -- 21:15:28 - <Info> - Alert unified2 module wrote 0 alerts
>> >> 30/7/2015 -- 21:15:28 - <Info> - host memory usage: 390144 bytes,
>> maximum:
>> >> 16777216
>> >> 30/7/2015 -- 21:15:28 - <Info> - cleaning up signature grouping
>> >> structure... complete
>> >> 30/7/2015 -- 21:15:28 - <Notice> - Stats for 'eth0': pkts: 3372,
>> drop: 0
>> >> (0.00%), invalid chksum: 0
>> >>
>> >>
>> >> On Thu, Jul 30, 2015 at 2:02 PM, Peter Manev <petermanev at gmail.com>
>> wrote:
>> >>>
>> >>>
>> >>> On 30 jul 2015, at 21:50, Duane Howard <duane.security at gmail.com>
>> wrote:
>> >>>
>> >>>
>> >>> Can you reproduce this problem at will? Anything in verbose mode in
>> >>> Suricata.log?
>> >>>
>> >>> Can you narrow it down to a relation of a single interface
>> configuration
>> >>> (as you mention in your initial mail)?
>> >>>
>> >>> Thanks
>> >>>
>> >>>
>> >>> This is Suricata version 2.0.8 RELEASE
>> >>> Features: PCAP_SET_BUFF LIBPCAP_VERSION_MAJOR=1 PF_RING AF_PACKET
>> >>> HAVE_PACKET_FANOUT LIBCAP_NG LIBNET1.1 HAVE_HTP_URI_NORMALIZE_HOOK
>> >>> SIMD support: none
>> >>> Atomic intrisics: 1 2 4 8 byte(s)
>> >>> 64-bits, Little-endian architecture
>> >>> GCC version 4.6.3, C version 199901
>> >>> compiled with -fstack-protector
>> >>> compiled with _FORTIFY_SOURCE=2
>> >>> L1 cache line size (CLS)=64
>> >>> compiled with LibHTP v0.5.17, linked against LibHTP v0.5.17
>> >>> Suricata Configuration:
>> >>> AF_PACKET support: yes
>> >>> PF_RING support: yes
>> >>> NFQueue support: no
>> >>> NFLOG support: no
>> >>> IPFW support: no
>> >>> DAG enabled: no
>> >>> Napatech enabled: no
>> >>> Unix socket enabled: no
>> >>> Detection enabled: yes
>> >>>
>> >>> libnss support: no
>> >>> libnspr support: no
>> >>> libjansson support: no
>> >>> Prelude support: no
>> >>> PCRE jit: no
>> >>> LUA support: no
>> >>> libluajit: no
>> >>> libgeoip: yes
>> >>> Non-bundled htp: yes
>> >>> Old barnyard2 support: no
>> >>> CUDA enabled: no
>> >>>
>> >>> Suricatasc install: yes
>> >>>
>> >>> Unit tests enabled: no
>> >>> Debug output enabled: no
>> >>> Debug validation enabled: no
>> >>> Profiling enabled: no
>> >>> Profiling locks enabled: no
>> >>> Coccinelle / spatch: no
>> >>>
>> >>> Generic build parameters:
>> >>> Installation prefix (--prefix): /usr
>> >>> Configuration directory (--sysconfdir): /etc/suricata/
>> >>> Log directory (--localstatedir) : /var/log/suricata/
>> >>>
>> >>> Host: x86_64-pc-linux-gnu
>> >>> GCC binary: gcc
>> >>> GCC Protect enabled: no
>> >>> GCC march native enabled: no
>> >>> GCC Profile enabled: no
>> >>>
>> >>>
>> >>> On Thu, Jul 30, 2015 at 1:41 PM, Peter Manev <petermanev at gmail.com>
>> >>> wrote:
>> >>>>
>> >>>>
>> >>>>
>> >>>> On 30 jul 2015, at 20:58, Duane Howard <duane.security at gmail.com>
>> wrote:
>> >>>>
>> >>>> When closing suri it reports 0 packets for the interface I'm mainly
>> >>>> concerned with. There's also nothing in fast or other logs to
>> indicate
>> >>>> traffic.
>> >>>>
>> >>>> 30/7/2015 -- 19:58:41 - <Notice> - Stats for 'bond0': pkts: 0,
>> drop: 0
>> >>>> (-nan%), invalid chksum: 0
>> >>>>
>> >>>>
>> >>>> What is the output of suricata --build-info ?
>> >>>>
>> >>>> If you have perf tools installed have a look at what in Suricata uses
>> >>>> the most CPU -
>> >>>> perf top -p pidofsuri
>> >>>>
>> >>>> Thanks
>> >>>>
>> >>>>
>> >>>> On Thu, Jul 30, 2015 at 12:57 PM, Alan Wanderley dos Santos
>> >>>> <alan.santos at rnp.br> wrote:
>> >>>>>
>> >>>>> Didi you see the fast.log and others logs?
>> >>>>>
>> >>>>> Maybe there are some traffic (icmp or broadcast for example) coming
>> to
>> >>>>> virtual machine, even little being data, can generated a lot of
>> logs and
>> >>>>> degree the performance.
>> >>>>>
>> >>>>> I had a similar situation on a VM of testing.
>> >>>>>
>> >>>>> Just a shot into darkness rsrs
>> >>>>>
>> >>>>> Regards,
>> >>>>>
>> >>>>> -----------------------------------------------
>> >>>>> Alan Santos
>> >>>>> Analista de Segurança
>> >>>>> Centro de Atendimento a Incidentes de Segurança (CAIS)
>> >>>>> Rede Nacional de Ensino e Pesquisa (RNP)
>> >>>>> (19) 3787-3314 | alan.santos at rnp.br
>> >>>>>
>> >>>>> ________________________________
>> >>>>> De: "Duane Howard" <duane.security at gmail.com>
>> >>>>> Para: "oisf-users" <oisf-users at openinfosecfoundation.org>
>> >>>>> Enviadas: Quinta-feira, 30 de julho de 2015 16:50:51
>> >>>>> Assunto: [Oisf-users] Suricata using 35% cpu with no load?
>> >>>>>
>> >>>>> I've got a random virtual testing machine, and I'm seeing Suricata
>> >>>>> sitting at about 35% CPU load, even though there's absolutely no
>> traffic
>> >>>>> heading to it at the moment. Is there an easy way to get Suricata
>> to tell me
>> >>>>> what it's doing that would cause this? It occurs on real interfaces
>> with low
>> >>>>> traffic, loopback, as well as bonds where there's no trafic.
>> >>>>> ./d
>> >>>>>
>> >>>>> _______________________________________________
>> >>>>> Suricata IDS Users mailing list:
>> oisf-users at openinfosecfoundation.org
>> >>>>> Site: http://suricata-ids.org | Support:
>> >>>>> http://suricata-ids.org/support/
>> >>>>> List:
>> >>>>> https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users
>> >>>>> Suricata User Conference November 4 & 5 in Barcelona:
>> >>>>> http://oisfevents.net
>> >>>>
>> >>>>
>> >>>> _______________________________________________
>> >>>> Suricata IDS Users mailing list:
>> oisf-users at openinfosecfoundation.org
>> >>>> Site: http://suricata-ids.org | Support:
>> >>>> http://suricata-ids.org/support/
>> >>>> List:
>> >>>> https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users
>> >>>> Suricata User Conference November 4 & 5 in Barcelona:
>> >>>> http://oisfevents.net
>> >>>
>> >>>
>> >>
>> >
>>
>>
>>
>> --
>> Regards,
>> Peter Manev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-users/attachments/20150731/363ecdcc/attachment-0002.html>
More information about the Oisf-users
mailing list