[pacificpendant]

I had regular emails from a security testing tool telling me that internal IP addresses were being exposed on a webpage, in reality the page was a forum post where someone had pasted some console output including an IP address they were working with. In the end I blocked the emails from the tool because I wasn't allowed to mark things as false positives.

If a tool wants to remain relevant it should try to minimise false positives, in some cases this might mean removing rules that are going to throw false positives significantly more often than true positives. Tools should also be run such that anyone that receive alerts should be able to flag false positives with minimal effort.

The response to this false positive could be to fix Prometheus, but if you end up having to fix lots of things it's more of a sign of a bad rule that is making you concentrate on things with a low value to the goal of improving security.

[tetha]

Oh, you remind me of that day when our IDS went bonkers. Something was hammering us with SQL injections, it said. Like, 1-2 SQL injections per minute. And it gave successful HTTP responses, and actual JSON responses. The sky must be falling! We must be doomed!

After a brief amount of panic, we figured out that we had a new customer for our knowledge base. This was an MSP and they were busy uploading their MSSQL and PostgreSQL runbooks into our knowledge base. Entirely beautiful documentation I have to say, clear steps, great instructions, smart queries to check, act and validate. We eventually had a good call about Postgres and such with those guys. But our IDS hated it.

[technion]

I keep referring to the situation where a supplier sold the Cisco select range. If you clicked the page on their site, select showed up in the url and their way blocked your connection.

[bombcar]

192.168.0.1

10.10.10.10

172.16.31.5

I've exposed internal IPs!

[Joker_vD]

Oh no! You should contact your localhost's administrator ASAP and tell him to change those!