I am new to quickbuild.
The company has a quickbuild server installed in-house.
I need to run some workflows directly on the cloud. So I installed an agent. but I could not get the server to recognize the agent. I assume the following:
the communication's direction is from agent to server. The agent registers itself in the server because I cannot find a way to tell the server where the agent is, but I can define the server's location in the agent.
the company's firewall blocks communication from agent to server.
So my question is how do I make it work? I am investigating several paths to resolve this and would appreciate someone with experience to help me advance on the issue.
Here are the solutions I thought about and their problems:
Is there a configuration that I can tell the server where the agent is and so the communication is from the server to agent and then I won't experience firewall issues? I tried looking for it, but couldn't find such configuration. If there is a way to do this, how can I prevent others to use this agent?
To convince the IT team to remove firewall restrictions to quickbuild, I must provide some sort of a secured method for this. For example - give the agent a secret key which is defined in the server. kinda like when you want an application to use your google account - so you go to security and get a one-time key. Is there anything similar in quickbuild?
The quickbuild server is a crucial part of our development cycle, and we cannot replace it with other solutions such as Travis CI, so please don't suggest that. Thanks.
We are using quickbuild 4.
Thanks.
Related
Is ngrok a safe tool to use? I was reading a tutorial which recommended to use ngrok test API responses that I make to outside services that need to connect to my endpoints also.
There is no source code available for Version 2.0, considering it started as an open source project in 2014. I am suspect of any code that opens a tunnel to my localhost from the cloud. Pretty scary stuff especially without source code!
It opens up a tunnel to your dev machine, which is partially secured by obscurity (a hard to guess subdomain), and can be further secured by requiring a password. But you're still opening yourself up to ngrok itself, and the company is completely opaque (no address, no employees, no business name, no LinkedIn presence; all I can find is that it has 1-10 employees and is private; not even sure what country its based in). On top of that the code is not open-sourced. No reason to think they're not legit, but not a lot of information available to build trust.
You may be able to use ngrok and other local tunnel services with more security by encrypting the traffic. See https://security.stackexchange.com/questions/177280/end-to-end-encryption-for-localtunnel-ngrok-setup/177357#177357 for more information.
I found good rating, but vacuous information here:
http://www.scamadviser.com/is-ngrok.com-a-fake-site.html
The kicker for me is
https://developer.atlassian.com/blog/2015/05/secure-localhost-tunnels-with-ngrok/
where the Atlassian folks recommend it highly.
I think I am going to use it.
If anyone is concerning compromising their development environment, you can use Docker. There are many ngrok/docker projects but here is the one I chose: https://github.com/gtriggiano/ngrok-tunnel
for macOS, use "TARGET_HOST=docker.for.mac.localhost"
They now offer a service where you locally run only ssh, no need to run any of their code on your machine.
You run something like ssh -R 80:localhost:8501 tunnel.us.ngrok.com http. This connects to one of their hosts and forwards connections they receive back to your machine and the service you run on localhost:8501.
This seems secure to me, the only thing is that you don't know what information they collect and who is connecting to your exposed service. They print all connections, but it's their binary that does this and someone might well listen in without you noticing. You can check connections on your end, but you cannot be sure who it is that connects.
Ngrok is a convenient and highly secure utility for creating tunnels to locally hosted applications via a reverse proxy. This is a utility for publishing locally hosted applications on the web. style="letter-spacing: 0px;">Simply put, any locally hosted application provides a publicly accessible web URL to the . H. Either a Spring Boot or Nodejs based web application, or a webhook for a chat application, etc.
Few questions in one. I'm a mobile developer, and as a pet project I've set up a small server (on a raspberry pi) that I use as my backend development sever
I think I have set up the server fairly securely and have avoid the common blunders.
The problem is when it comes to security I'm completely neurotic, not because I have something to hide, but because I don't want to be victim of my own naivety / stupidity.
Currently I check my apache2 logs daily to find out what traffic (bar my own) has hit the server. Every day there seems to be between 4-5 hits from random ip's looking for directories that dont exist. Am I correct in assuming there are servers that randomly trawl through ip's searching for known weaknesses in sever software?
My main question is, is there a way for me to log every hit to the server in an sql database? That way I can see if somebody is really trying to get in by querying the number of hits from that ip without trawling through the logs manually.
Secondly, anybody got any more obscure security tips / things I should do on a daily basis?
Thanks for your time!
Edit: - Also, are their any good automatic penetration tools out there that can tell me if I have any vulnerability?
Am I correct in assuming there are servers that randomly trawl through ip's searching for known weaknesses in sever software?
Yes.
My main question is, is there a way for me to log every hit to the server in an sql database?
You could use mod_log_sql: http://www.outoforder.cc/projects/apache/mod_log_sql/
anybody got any more obscure security tips / things I should do on a daily basis?
you could setup a firewall, use port knocking, expose services only locally and connect via VPN, ...
I have a special user, called udpate, whose shell is a special command that fetches any pending updates to our system.
I'd like to be able to open an ssh session with this user without any kind of authentication (password or ppk, or anything), so if anyone wants to update a system, they could do "ssh update#<>", without having to know a password, or have a pre-shared public key on the box.
Insecure, I know, but this is over a VPN, so it should not be a problem, and they will only run the update, and then be thrown out.
Can this be done?
VPN is not a good reason to avoid authentification when using ssh. Even if there is a way to do this, you shouldn't use it. Use a ssh-key is the best way to do it. If you really want to do thing like this, use the same key and distribute it on each box.
What did you do if the local network of your box is compromised ? You just have a security hole.
as this rfc points out, there is support for host based authentication https://www.ietf.org/rfc/rfc4252.txt
So using it carefully should be possible by following this tutorial https://en.wikibooks.org/wiki/OpenSSH/Cookbook/Host-based_Authentication#Server_Configuration_for_host-based_authentication.
That may not be a final solution, but helping finding one.
But really, you should not do it for this usecase... Just offer a basic web endpoint which does only start the update process on the next cron run. I know, its not so "simple" but its a lot more secure.
Or if they have access to this server anyway, add a script with super user bit set which triggers the update.
Also, if you have a central server in your company, where everyone has access too, you can use this as step in between to host the key pair, so you dont need to manage X keys for everyone.
Or you use a more modern setup with puppet or anything, or you just configure the server to always update without user interaction needed....
I'm working at an IT company where we have used Perforce for years as our code repository system, in our internal company network. Because we are starting to work with an offsite company we are looking into ways of making our Perforce server accessible via the internet.
The most obvious way for me to do this is setup a VPN server on our linux gateway server and allow access through that. Obviously this works but seems very unsafe. If a VPN key of a certain user falls in the wrong hands they can access our code-repository AND our complete internal network.
My first thought was to create a Perforce proxy server (they supply software for this) and host this behind another gateway, with a VPN server. This shields the real Perforce server and our network better. The obvious problem here is that the proxy needs access to our perforce server, meaning the two networks needs to be connected anyway.
Our company is rather small, so taking into account we don't have a huge resource pool to spend on this, how would you approach this?
thanks a lot in advance,
Fred.
Instead of modifying the behavior and configuration of your current internal server, perhaps you should set up a second Perforce server, and use that server only for the interactions between your team and your offsite partner.
Include explicit steps in your workflow to periodically "publish" code from your internal server to your external server, and similar steps to periodically "consume" the offsite company's work by copying their changes back to your internal server and re-submitting them there.
Additionally, there are companies which offer a hosted Perforce service, so you don't even have to operate this external Perforce server yourself; you can let the hosting company manage the operational aspects of this code-sharing server.
One option is to put the official Perforce server in an outside locked-down server. That is to say, everyone accesses Perforce at the outside server, which has Perforce and only Perforce on it.
This is a very generic question that popped up in my mind. The reason has been that I came across a website dev server which leaked sensitive information about a database connection due an error. I was stunned at first and now I wonder why someone puts a development server out in the internet and make it accessible to everyone?
For me there is no reason for doing this.
But it certainly did not happen by accident that a company created a subdomain (dev.example.com) and pushed development code to it. So what could be the reason to ignore the fact of high security risk?
A quick search did not bring up any information about this. I'm interested in any further readings about this specific topic.
Thank you in advance
There is no reason for your dev servers to be accessible by the general public.
As a customer I just had an experience with a private chef site where I spent time interacting with their dev server because it managed to get crawled by Bing. Everything was the same as the live site but I got increasingly frustrated because paying a deposit failed to authorise. The customer support team had no idea I was on the wrong site either. The only difference was the URL. My e-mail address is now in their test system sending me spam every night when they do a test run.
Some options for you to consider, assuming you don't want to change the code on the page:
IP Whitelisting is the bare minimum
Have a separate login page that devs can use that redirects to the dev site with the correct auth token - bonus points for telling stray users that this is a test side and the live site is at https://.....
Use a robots.txt to make sure you don't get indexed
Hide it all behind a VNET - this really isn't an issue anymore with VPNs or services like Bastion.
Also consider the following so your devs/testers don't accidentally use the wrong site:
Have a dev css to make it obvious its a test system (this assumes you do visual testing later in your pipeline)
Use a banner to make it clear this is a dev site
Note that this would be a dev server. If you are using ringed/preview/progressive deployment then these should work just as well as the live site because they are the live site.
It's extremely common for a development environment or any "lower level" environment for that matter to be exposed to the pubic internet. Today, especially with more and more companies working in the public cloud and having remote team members, it's extremely more productive to have your development team or UAT done without having the need to set up a VPN connection or a faster more expensive direct connections to the cloud from your company's on premise network.
It's important to mention that exposing to the public internet does not mean that you shouldn't have some kind of HTTP Authentication in these environments that hides the details of your website. You can also use a firewall with an IP address whitelist. This is still very important so you don't expose your product and lose a possible competitive advantage. It's also important because lower level environments tend to be more error prone and important details about the inner workings of your application may accidentally show up.