We switched from a publicly accessible reprepro Debian package repository (which was powered by an Apache web server) to the Sonatype Nexus Repository OSS, which is great piece of software. But we ran into one problem: When someone uploads a Debian package it's signed on the Nexus server, which we expose to our customers/the internet. In addition, the GPG key and passphrase is known to Nexus for package signing.
Or in other words: I am afraid of a similar situation like the SolarWinds supply chain attack. Scenario: Person attacks the publicly accessible Nexus server/Nexus itself, takes over Nexus, changes existing packages and resigns them with the GPG key/GPG passphrase. Then, malicious code is served to our customers.
I thought about exposing the file blob store directory as read only target to a publicly exposed web server and keep Nexus company internal. Sadly the internal file blob store layout is different, so that's not possible.
So my questions:
Is there a good way to expose the the blob storage in a Deb/RPM/Docker/etc. compatible format which can be served by a more protected, publicly accessible Apache server and consumed by tooks like dpkg/yum/dnf/Docker etc?
I also thought about a second read only Nexus server which is rsync'ed every 10 minutes or so. An attacker would then take over this server, but the package signing check (At least for DEB/RPM) prevents installation of the tampered package
Use an Apache reverse proxy with certificate based authentication (I guess the most secure but complex solution)
But maybe there is already such a feature/another way and I just missed it in the documentation?
In the end we came up with several steps to minimize the risk:
Use a proxy that filters via GeoIP (Repository access is only possible from the countries our customers reside)
Block all URIs except the following (Replace with name of your repo):
/service/rest/repository/browse/REPONAME/*>
/repository/REPONAME/*>
/static/css/nexus-content.css*>
/favicon.ico*>
/favicon-*.png>
Related
Is it possible to identify if the login is being made from a strange machine? Creating a list of machines recognized by login?
I have tried methods to capture data from the browser through .js, thus generating a fingerPrint but without success, because it is not possible to identify the machine if it is in a network for example.
Here's an example where Google or Microsoft do this, I logged into my account on a computer that I had never used, so I get the notification and I can administer the machines that are recognized for my login.
Is it possible to implement this without installing plug ins on the user's machine? through only my WEB application?
Examples:
you want to do something called fingerprinting. This is client side code
basically you are uniquely identifying the user, with all the possible information in which you believe is unique.
This could be a concatenation:
- using cookies
- ip address
- browser agent (which has os, and browser, and some plugins)
- java version (if installed)
- flash version (if installed)
- screen resolution
- all misc versions of information you can grab via javascript
take a look at
https://github.com/jackspirou/clientjs
https://github.com/Valve/fingerprintjs
There are couple of ways to achieve this.
If your clients are having static IPs then probably you can maintain a list of IPS (Kind of whitelist). Any other request can be treated as unintended request and you can write a logic to generate an alert. This is cumbersome method since static IP may be changed over a period of time.
If you have limited no of users, then probably you can generate a certificate and install it on clients machine. Other users who is not having the certificate can be treated as unintended users. They can't access your application since they don't have your certificate. This method is feasible only if your application is intended only for some small no of users since you need to install the certificate on your clients machine.
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.
I'm going to build a website for file manipulations. The idea is that the user will manage to upload his files to the website, and click the "manipulate" button, then he will get the resulted file. Also the user will have to pay in accordance with the amount of files he's trying to manipulate.
The code for the file manipulation is already written in JAVA.
The thing is, some of these files will probably be truly sensitive and private, so users will not be delighted to upload to my site over the internet.
I thought about making a local version of the website, and let the user download it (the local version) to his computer (and the only access the internet will be for the payment action).
But there seem to be two problems:
When i'll decide to change anything in my website, it will not affect the local users.
The local site will be very easy to "crack" in order not to pay...
This is my first website,
do you have any suggestions of how to solve one of these 2 problems?
Thanks!
Concerning question
(1) you would have to implement some update mechanism, for example your "local web site" (which might be a .jar file containing a web server) could check over the internet if a new version is available and then download and install it (however, you should generally ask for user's permission to do so, as many users are not delighted with silently auto-updating software). Concerning question
(2) you might use some code obfuscator to make your compiled java classes more difficult to decompile, and use an encrypted SSL connection for the transactions related to payment (while checking for server certificate to avoid man-in-the-middle attacks by the end user); however any software that a user can have on its computer will be eventually cracked by somebody. Therefore, the best solution is possibly to keep all on your server, while securing as much as possible the whole: use encrypted connections with SSL for everything, or even if the files are highly sensitive, provide a public key so users can encrypt their files with GPG (or similar software) before sending them to the site, and encrypt the files to be sent back to the user by using its public key (that he/she has to provide you and that is not critical at all to be transferred over the internet). Also carefully check the security of your web server and all the software running on it, to avoid bugs that might allow somebody to hack into it. Using the encryption with GPG/public keys and only storing encrypted data on your server might be already a good protection (but you have to make sure that it is impossible to get your private key in any way!).
Subversion has multiple server types:
svnserve daemon
svnserve via xinetd
svn over ssh
http-based server
direct access via file:/// URLs
Which one of these is best for a small Linux system (one to two users)?
http:
very flexible and easy for administration
no network problems (Port 80)
3rd party authentication (eg. LDAP, Active Directory)
Unix + Win native support
webdav support for editing without svn client
slow, as each action triggers a new http-action approx. 5-8 times slower than svn://
especially slow on history
no encryption of transferred data
https:
same as http
encryption of transferred data
svn:
fastest transfer
no password encryption in std. setup: pw are readable by admin
firewall problems as no std.port is used
daemon service has to be started
no encryption of transferred data
svn+ssh
nearly as fast as svn://
no windows OS comes with build in ssh components, so 3rd party tools are essentiell
no daemon service needed
encryption of passwords
encryption of transfer
1 of those options is definitely a 'worst' one: file access. Don't use it, use one of the server-based methods instead.
However, whether to use HTTP or Svnserve is entirely a matter of preference. In fact, you can use both simultaneously, the write-lock on the repo ensures that you won't corrupt anything if you use one and then use another.
My preference is simply to use apache though - http is more firewall and internet friendly, it is also easier to hook into ldap or other authentication mechanisms, and you get features like webdav too. The performance may be less than svnserve, but its not particularly noticeable (the transferring of data across the network makes up the bulk of any performance issues)
If you need security for file transfers, then svnserve+ssh, or apache over https is your choice.
Check out FLOSS Weekly Episode 28. Greg Stein is one of the inventors of the WebDAV protocol for SVN and discusses the tradeoffs. My takeaway is that SVN: is faster but the http/webdav implementation is just fine for almost all purposes.
I've always used XInetD and HTTP.
HTTP also had WebDAV going on, so I could browse the source online if I wanted (or you can require a VPN if you wanted encryption and a dark-net type thing).
It really depends on what restrictions (if any) you're under.
Is it only going to be on a LAN? Will you need access outside of your LAN?
If so, will you have a VPN?
Do you have a static IP address and are you allowed to forward ports?
If you aren't under any restriction, I would then suggest going with xinetd (if you have xientd installed, daemon if you don't) and then (if you need remote access) use http-based server if you need remote access (you can also encrypt using HTTPS if you don't want plain text un/pw sent across).
Most other options are more effort with less benefit.
It's an SVN Repo -- you can always pack your bags and change things if you don't like it.
For ease of administration and security, we use svn+ssh for anything that requires commit access. We have set up HTTP based access for anonymous (read only) access to some open-source code, and it is much faster; the problem with svn+ssh is that it has to start up an ssh connection and a whole new svnserve for each user for every operation, which can get to be pretty slow after a while.
So, I'd recommend:
http for anonymous connections
svn+ssh if you need something secure and relatively quick and easy (assuming your users already have ssh set up and your users have access to the server)
https if you need something faster, secure, and you don't mind the extra overhead of administering it (or if you don't already have ssh set up or don't want to deal with Unix permissions)
I like sliksvn runs as a service in Windows, 2mins to setup and then forget about it.
It also comes with the client tools but download tortoise as well.
If you are going to be using the server only on the local machine and understand unix permissions, using file:// urls will be fast, simple and secure. Likewise, if you understand unix permissions and ssh and need to access it remotely, ssh will work great. While I see somebody else mentions it as "worst", I'm pretty sure that's simply due to the need to understand unix permissions.
If you do not like or understand unix permissions, you need to go with svnserve or http. I would probably choose to run it in xinetd, personally.
Finally, if you have firewall or proxy issues, you may need to consider using http. It's much more complicated, and i don't think you're going to see the benefits, so I'd put it last on your list.
I would recommend the http option, since I'm currently using svn+ssh and it appears to be the red-headed stepchild of the available protocols: 3rd-party tool support is consistently worse for svn+ssh than it is for http.
I've been responsible for administering both svnserve and Apache+SVN for my development teams, and I prefer the http-based solution for its flexibility. I know next to little about system administration, I'm a software guy after all, and I liked being able to hand authentication and authorization over to Apache.
Both tines the teams were about 10~15 people and both methods worked equally well. If you're planning for any expansion in the future, you might consider the http-based solution. It's just as easy to configure as svnserve, and if you're not going to expose the server to the Internet then you don't have to worry too much about securing and administering Apache either.
As a user of SVN, I prefer the http-based integration with Apache. I like being able to browse the repository with my web browser.
I am curious why NOT FSFS?? Important information - I am managing Windows systems.
I have done many projects with SVN and almost all of them were running from FSFS. Biggest repository was around 70GB (extreme), biggest ammount of repositories was around 700.
We never had any issues, even though we hosted it on Windows, NetApp and many other storage systems. Most of the time when I asked why NOT using FSFS only problem was that people simply didn't trust it.
Advantages:
No backend required (or dedicated server)
Fast and reliable
Hook scripts are supported
NTFS permissions are used
Easy to understand, easy to support, easy to manage
Disadvantages:
Not so easy access from outside your network (VPN)
Permissions only on repository-level (Read, Read/Write)
Hook scripts are running under current user credentials (which is sometimes advantage, sometimes disadvantage)
Martin
What is the easiest free method of encrypting my web traffic? I'd like to be able to log in to sites on my web server without sending my password in plaintext.
Edit: My web server is running on the LAMP stack , although it is a shared host so I don't have root.
Get an X.509 certificate (for example, generating your own, or getting one free from StartSSL), and use it to set up SSL—a server-specific configuration task.
If you can't configure a new listener in your web server, there's not really a good option. In theory you could do a little hacking with some JavaScript crypto library, like JavaScrypt, and come up with something safe. I've toyed with several options but I don't know enough about it to come up with anything I feel confident about.
I don't know your circumstances, but if it were me, I'd consider another host.
https
Use a self-signed certificate.
Tell us your web server software for a detailed implementation description!
Since you don't have root your best bet is to contact your hosting provider and see what they can do for you. You may already have SSL access (try using https://yourdomain.com) using a self-certified key.
You should be able to talk them into installing a StartSSL key for you. This provides you with SSL encryption and browsers won't complain that it isn't signed by a valid Certificate Authority.
As stated above, publishing your own certification is free, however knowing more about your environment, may get you more specific answers. Are you running IIS? What will you be logging into that needs encryption? Are you using Windows Servers on the back end?
use Digest Authentication. Since you're on LAMP, you can configure it on Apache with mod_auth_digest.
Since you are trying to reduce costs, any ssl solutions will probably not be an option.
First it requires a signed certificate that cost a bit, the free ones is not always included in all web browsers.
Second to be able to utilize an ssl certificate your server ip must be dedicated to you. This is not the case in every cheap web hosting option. There are technologies that in the future will make it possible to host multiple ssl enabled sites on a single ip, but it's not here yet.
As mentioned before Digest Authentication is one option that doesn't require ssl certificate or dedicated ip.
It's a method of authentication that doesn't reveal your password even though everything else in the communication is unprotected.
In Apache this can be applied in individual directories by specific .htaccess files.
I'll repeat the previous link on mod_auth_digest.
This one is usually already installed on most servers so you won't have to ask you web hosting provider.
You don't always require root access to setup Apache to use SSL, but you will likely need to modify config files, which is either done thru your providers interface, or via files via a shell account. Either way you will need a server certificate; either self-signed, from a major company like Verisign, or one of the smaller free places like cacert.org. As noted by others, this does require a dedicated IP to your server or instance on the server.
I would recommend SSL first, but mod_auth_digest isn't a bad backup idea.