hi kwchang, Seems like a bug.. would you by any chance be able to provide a sample .pcap file that exhibit this problem? ... View more

hi kwchang, Seems like Splunk fails to parse this event, despite the event containing properly formatted JSON. I'd recommend opening a ticket in JIRA (SPL project) ... View more

Hi kwchang, I created a ticket to properly document the list of classified protocols; meanwhile please find the preliminary list below (please keep in mind that it's preliminary and subject to change, etc.): 8021q aim amqp bgp bittorrent cotp db2 dcerpc dhcp diameter dns drda ftp gmail google_gen gre http https http_tunnel ica imap informix ipx irc iscsi jabber krb5 ldap llc mapi mcs mq msn msrpc mount mysql netbios netflow nfs pop3 postgres radius rdp rip1 rip2 rpc rtp sip skype smb smpp smtp sna snmp socks4 socks5 ssh ssl stun syslog tcp tds telnet tftp tns tor udp wins ... View more

Hello Shisa, tcp_status=1 means that the server (dest_ip) sent RST packet in response to the SYN packet during TCP handshake tcp_status=2 means that the TCP handshake request (SYN packet) was ignored, i.e. the SYN packet wasn't answered and the flow timed out When you use source=“stream:tcp”, “refused” is not appeared? In my test environment, "refused" is only appeared on app protocol like "stream:http". This is a bug: you're correct, the "refused" field is only set for HTTP protocol (oops..) I created STREAM-2529 ticket to track this bug. Is it critical for you to get the "refused" field working? BTW, the field description is also incorrect - it should read "1 if the flow was terminated with RST, 0 if not" Is it right that “time_taken” means how long a Stream flow takes to complete? Depends on the protocol: generally it means "how long an event has taken to complete" where an event can be a HTTP/DNS request/response, MySql query/server response, etc. or the whole flow (stream:tcp and stream:udp source types) How do you calculate “missing_packets_out” and “missing_packets_in” values from the packet data We increment missing_packets_in/out counts every time Stream's TCP reassembly engine encounters a gap in TCP sequence it cannot reassemble (i.e. too many packets with higher TCP sequence have arrived, etc.) in the corresponding (ingress/egress) TCP stream. ... View more

Yes, it's in the backlog ... View more

Stream doesn't generate the exact Netflow/IPFIX data; the best approximation you can do is to create aggregated tcp and/or udp streams that have src_ip, src_port, dest_ip, dest_port (+any other fields) as key fields and bytes_in/bytes_out/packets_in/packets_out as value fields. That will generate events with NetFlow-like stats. The limitations are: only tcp and udp transport protocols supported; not all netflow fields are supported, etc. so it may or may not work based on your use case. ... View more

Hi kwchang, Stream replaces the proxy ip with the X-Forwarded-For value (but not the X-Cluster-IP one) for the src_ip field in HTTP events. See the src_ip field description in the http stream config page. HTH ... View more

hi kwchang, Stream has a configurable in-memory event queue - see MaxEventQueueSize parameter in the docs. For all other data forwarding tasks, Stream relies on UF to manage the data forwarding. If UF Stream runs with is not properly configured (disconnected from indexers, etc.), Stream starts dropping events once its event queue is full - you'll see messages like "event queue overflow; dropping NNN events" in stream log when it occurs. ... View more

hi kwchang, Not sure I understand the question: are you asking how we can detect that something other than the normal ssh traffic (shell commands, etc) is being transferred over an ssh connection? If so, I'm not sure it's technically possible - with Stream or any other passive network sniffer - since the connection is encrypted.. ... View more

hello kwchang, TOR is detected by analyzing SSL certificate and other SSL handshake data. We have no reported incidents of false positive or false negative TOR classification, but I suppose it's not technically impossible. My guess would be that false negative is more likely than false positive, but again - I'm just speculating here. HTH ... View more