a month ago
I deployed a new service to EU and US-East. I have been seeing a lot of interesting requests... However an interesting find when I added region logging is that they are all, without exception in the EU region.
Is this expected railway behavior or should I put the site in under attack mode?
Some examples, these all seem to be very reasonable security scans... The question is are they coming from Railways security team or some... less friendly users
Method Path Status Time
POST / 404 10ms
GET /dump.sql 404 4ms
GET /config.xml 404 4ms
GET /storage/logs/laravel.log 404 10ms
GET /backup.sql 404 8ms
GET /config.php 404 11ms
GET /database.sql 404 9ms
GET /database_backup.sql 404 1ms
GET /wp-config.php 404 10ms
GET /backup.zip 404 9ms
GET /.svn/wc.db 404 2ms
GET /actuator/heapdump 404 17ms
GET /backup.tar.gz 404 2ms
GET /server.key 404 1ms
GET /_vti_pvt/service.pwd 404 2ms
GET /.ssh/id_ed25519 404 8ms
GET /wp-admin/setup-config.php 404 1ms
GET /.git/HEAD 404 1ms
GET /.env 404 1ms
GET /api/.env 404 10ms
GET /phpinfo.php 404 11ms
GET /docker-compose.yml 404 1ms
GET /user_secrets.yml 404 1ms
GET /.vscode/sftp.json 404 1ms
GET /secrets.json 404 3ms
GET /.npmrc 404 1ms
GET /.bash_history 404 1ms
GET /.env.production 404 2ms
GET /.ssh/id_rsa 404 2ms
Pinned Solution
a month ago
Railway doesn't scan endpoints for vulnerabilities, they're most likely automated internet crawlers and such scanning for vulnerabilities in websites. Don't worry, these are pretty much harmless as long as you follow basic security practices (such as not exposing anything sensitive externally). You're welcome to ignore it, a lot of websites see this sort of traffic
If it is bothering you though then I wouldn't recommend turning on under attack mode, I'm pretty sure that'll make each request run through a bot check - not just suspicious traffic. Instead you could put your domain behind CloudFlare with WAF security enabled (which will then only block suspicious traffic) or if they're coming from the same IPs you could consider just blocking those IPs outright via edge rules (service settings -> edge rules).
5 Replies
a month ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • about 1 month ago
a month ago
Railway doesn't scan endpoints for vulnerabilities, they're most likely automated internet crawlers and such scanning for vulnerabilities in websites. Don't worry, these are pretty much harmless as long as you follow basic security practices (such as not exposing anything sensitive externally). You're welcome to ignore it, a lot of websites see this sort of traffic
If it is bothering you though then I wouldn't recommend turning on under attack mode, I'm pretty sure that'll make each request run through a bot check - not just suspicious traffic. Instead you could put your domain behind CloudFlare with WAF security enabled (which will then only block suspicious traffic) or if they're coming from the same IPs you could consider just blocking those IPs outright via edge rules (service settings -> edge rules).
a month ago
Thanks @dev! I thought so but it was curious. The project is a dirt simple IPX handler that is only not a function so I can include it in my local dev stack. All of these requests just add logs and nothing more. I'm sure they will bug off soon enough.
The two traffic patterns that made me curious where
- All of the traffic was in one region, which is also my primary region.
- The traffic occurred instantly on a domain registered a week or two ago and only used today.
a month ago
Ah makes sense, glad I could clear that up 🙂
The traffic occurred instantly on a domain registered a week or two ago and only used today
And yea that tracks, those bots can detect when domains get registered
they then likely scan continuously whether the domain is used for anything or not
that or they check certificate transparency logs to see when your domain becomes active
which explains why your domain was targeted immediately
Status changed to Awaiting User Response Railway • about 1 month ago
Status changed to Solved dev • about 1 month ago
a month ago
Yup, the buggers upstream address is @upstreamAddress:http://[fd12:5a58:2689:1:b000:dd:1593:4e79]:8080 not even ipv4... looks a lot like a bot. Interesting that the edgeregion is the AWS data center though... not something closer to eastern europe, germany or paris... guess we got a local clanker 😂
Status changed to Awaiting Conductor Response Railway • about 1 month ago
mhornbacher
Yup, the buggers upstream address is `@upstreamAddress:http://[fd12:5a58:2689:1:b000:dd:1593:4e79]:8080` not even ipv4... looks a lot like a bot. Interesting that the edgeregion is the AWS data center though... not something closer to eastern europe, germany or paris... guess we got a local clanker 😂
a month ago
I believe that upstream address is actually Railway's proxy, what you're looking for is the srcIp field in the HTTP logs, that'll tell you where it's coming from
Status changed to Awaiting User Response Railway • about 1 month ago
a month ago
This thread has been marked as solved automatically due to a lack of recent activity. Please re-open this thread or create a new one if you require further assistance. Thank you!
Status changed to Solved Railway • 29 days ago