How to filter requests by Atlassian Ecosystem Scanner

Jira Development Jira Cloud
,
1

We are operating a Connect app for Jira. We track all unexpected errors in service logs to investigate and find the root cause. Atlassian is using the Ecosystem Security Scanner to scan our service as well and the errors triggered by this scanner cause a lot of clutter in our error reports.

How can we 100% identify the requests made by this scanner so we can mark those errors as known errors and exclude them from our investigation lists?

I see requests made via an “Atlassian Http Client …” user_agent. Will filtering these out be enough?

1 Like
2

I filter by user agent that contain either Test or CSRT and mark those requests as eco system tests and excluded from any error triage.

3 Likes
3

Hi @emre.toptanci, We add the below header in all requests originating from our CSRT scanner:

'User-Agent': 'CSRT (github.com/atlassian-labs/connect-security-req-tester)'

You can find this line of code here - connect-security-req-tester/csrt_session.py at fc65b7157a28f6f2fdebfb6331684fd942fd7e29 · atlassian-labs/connect-security-req-tester · GitHub

So, thats one way to filter requests coming from CSRT.

You could also filter based on requests coming from certain IPs. If you see traffic from the below IPs, then its most likely from Atlassian. If it is not in this list, then it is most likely not from Atlassian. I hope this helps.

100.25.61.160
3.214.98.112  
3.221.51.2    
3.217.215.43  
35.174.235.12
34.211.197.111/32
50.112.197.134/32
52.42.55.113/32
54.68.221.42/32

Also, please note that CSRT is just one scanner we run as part of our Ecoscanner platform. There are other scanners as well. I don’t think we send custom headers from those scanners although I can log an item in our backlog to add that. Having said that, the IP list I provided above is an exhaustive list so thats probably the best way (as of now) to filter requests coming from Atlassian.

4

Thanks for adding the user-agent, that is really helpful. Unfortunately the IP address range isn’t of use, because we get lots of non-scanner traffic from Atlassian too (think webhooks).

5

@jmort I agree. We will continue to add the User-Agent in all our scanners. I have logged an item in our backlog and we will try to get it implemented for all the scanners asap. As for the IP ranges, if you were to troubleshoot traffic that looks like scanning traffic or sending malicious payloads, thats when I am hoping these ranges could come handy for investigation purposes.

1 Like
6

I can’t find documentation outlining what kind of requests can we expect on the server. We’ve been getting random get and post requests in the lifecycle events routes, whenever somebody tries to install our application. The requests reach the middleware in our application and fail because of an absent body in a post request or some other reason like 404. Can we do something about this?