Closed systemcrash closed 4 years ago
Hi @systemcrash, this looks like a very specific feature request and I'm not sure if it makes sense to include it for all. I will tag it as enhancement and if there is a demand for it I will maybe implement it. Beside that and if you really want this you can fork this project and implement it quite easily. You just need to edit this file: https://github.com/sipcapture/heplify-server/blob/master/metric/prometheus.go include your condition and write into method whatever you like.
Thanks for the tip.
I had a look through the code yesterday.
How do you define something that contains no cseq header, or in fact nothing other than the start-line? E.g.
400 Bad Request
Like I wrote above? Will this fail at the parse level?
@systemcrash Do you save the sip captures to mysql or postgresql? -- could you share what is saved in the database (if its in there.. then we can know that parsing was somehow successful).
are u able to provide the original pcap of this spam packets? I am curious on your Alarms and triggers. Are these using grafana default or you doing something more?
@systemcrash Do you save the sip captures to mysql or postgresql? -- could you share what is saved in the database (if its in there.. then we can know that parsing was somehow successful).
That's part of the problem - they're not parsed (by heplify).
are u able to provide the original pcap of this spam packets?
possibly - but it's just CRLF - 0xe 0xa
I am curious on your Alarms and triggers. Are these using grafana default or you doing something more?
Because they never ingress, they aren't accounted for. And the reply is not either. It lacks many headers - it's just a start-line:
SIP/2.0 400 Bad Request
Just for the record, many Bria UAs send exactly this (CRLF) when "Send SIP keep-alives" are enabled. Depending on which Proxy/SBC receives this, will determine what response type is sent (if any).
It's considered a hack, since this is not (implicitly) allowed via SIP/TCP, but Bria does it anyway.
See https://tools.ietf.org/html/rfc3261#section-7.5
and
after looking at the whole scenario again... i agree with negbie that this is very specific feature request and would not make sense to do it. As negbie suggested, https://github.com/sipcapture/heplify-server/blob/master/decoder/sip.go#L14 the parsing would probably fail here.. and will eventually also fail https://github.com/sipcapture/heplify-server/blob/master/decoder/sip.go#L16
You could probably add additional checking at https://github.com/sipcapture/heplify-server/blob/master/decoder/sip.go#L14, example to check the method response = 400 then output more info in the log. Then using other tool to convert that log to prometheus metrics. To minimse too much change from the original so that its easier to update.
Ok so let's close it here as it's too specific.
Some spam bots test SIP ports with a simple CR/LF. In this case, there is no method. If our IDS system doesn't catch this new bot endpoint, the proxy responds 400.
Prometheus query
heplify_method_response
probably only registers a concrete method vs response, but can it be made to handlemethod = <none>, response = 400
? I specifically write method is none, and not method is e.g. unknown (a new method which does not match the existing ones).Running
heplify_method_response{node_id="1",response="400"}
in grafana only revealswhere we know there have been only CR/LF data, and as a result only
400 Bad Request
(plus the garbage CR/LF) has ingressed in a HEP packet.My point is: heplify_method_response disregards these methodless CR/LF things. The packet content is:
So there is no CSeq. But I'd still like to track these, so I can set Alarms and triggers on them.
Can this be fixed?