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
Related
I'm used to working with user-uploaded files to the same server, and transferring my own files to a remote server. But not transferring user-uploaded files to a remote server.
I'm looking for the best (industry) practice for selecting a transfer protocol in this regard.
My application is running Django on a Linux Server and the files live on a Windows Server.
Does it not matter which protocol I choose as long as it's secure (FTPS, SFTP, HTTPS)? Or is one better than the other in terms of performance/security specifically in regards to user-uploaded files?
Please do not link to questions that explain the differences of protocols, I am asking specifically in the context of user-uploaded files.
As long as you choose a standard protocol that provides (mutual) authentication, encryption and message authentication, there is not much difference security-wise. If all of this is provided by a layer of TLS in your chosen protocol (like in all of your examples), you can't make a big mistake on a design level (but implementation is key, many security bugs are bugs of implementation, and not design flaws). Such protocols might differ in the supported list of algorithms for different purposes though.
Performance-wise there can be quite significant differences, it depends on what you want to optimize for. If you choose HTTPS, you won't be able to keep a connection open for a long time, and would most probably have to bear the overhead of the whole connection setup with authentication and everything, for every transmitted file. (Well, you can actually keep a https connection open, but that would be quite a custom implementation for such file uploads.) Choosing FTPS/SFTP you will be able to keep a connection open and transmit as many files as you want, but would probably have to have more complex error handling logic (sometimes connections terminate without the underlying sockets knowing about it for a while and so on). So in short I think HTTPS would be more resilient, but secure FTP would be more performant for many small files.
It's also an architecture question, by using HTTPS, you would be able to implement all of this in your application code, while something like FTP would mean dependence on external components, which might be important from an operational point of view (think about how this will actually be deployed and whether there is already a devops function to manage proper operations).
Ultimately it's just a design decision you have to make, the above is just a few things that came to mind without knowing all the circumstances, and not at all a comprehensive list of things to consider.
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 am building a relatively simple program to gather and sort data input by the user. I would like to use a local server running through a web browser for two reasons:
HTML forms are a simple and effective means for gathering the input I'll need.
I want to be able to run the program off-line and without having to manage the security risks involved with accessing a remote server.
Edit: To clarify, I mean that the application should be accessible only from the local network and not from the Internet.
As I've been seeking out information on the issue, I've encountered one or two remarks suggesting that local servers have their own security risks, but I'm not clear on the nature or severity of those risks.
(In case it is relevant, I will be using SWI-Prolog for handling the data manipulation. I also plan on using the SWI-Prolog HTTP package for the server, but I am willing to reconsider this choice if it turns out to be a bad idea.)
I have two questions:
What security risks does one need to be aware of when using a local server for this purpose? (Note: In my case, the program will likely deal with some very sensitive information, so I don't have room for any laxity on this issue).
How does one go about mitigating these risks? (Or, where I should look to learn how to address this issue?)
I'm very grateful for any and all help!
There are security risks with any solution. You can use tools proven by years and one day be hacked (from my own experience). And you can pay a lot for security solution and never be hacked. So, you need always compare efforts with impact.
Basically, you need protect 4 "doors" in your case:
1. Authorization (password interception or, for example improper, usage of cookies)
2. http protocol
3. Application input
4. Other ways to access your database (not using http, for example, by ssh port with weak password, taking your computer or hard disk etc. In some cases you need properly encrypt the volume)
1 and 4 are not specific for Prolog but 4 is only one which has some specific in a case of local servers.
Protect http protocol level means do not allow requests which can take control over your swi-prolog server. For this purpose I recommend install some reverse-proxy like nginx which can prevent attacks on this level including some type of DoS. So, browser will contact nginx and nginx will redirect request to your server if it is a correct http request. You can use any other server instead of nginx if it has similar features.
You need install proper ssl key and allow ssl (https) in your reverse proxy server. It should be not in your swi-prolog server. Https will encrypt all information and will communicate with swi-prolog by http.
Think about authorization. There are methods which can be broken very easily. You need study this topic, there are lot of information. I think it is most important part.
Application input problem - the famose example is "sql injection". Study examples. All good web frameworks have "entry" procedures to clean all possible injections. Take an existing code and rewrite it with prolog.
Also, test all input fields with very long string, different charsets etc.
You can see, the security is not so easy, but you can select appropriate efforts considering with the impact of hacking.
Also, think about possible attacker. If somebody is very interested particulary to get your information all mentioned methods are good. But it can be a rare case. Most often hackers just scan internet and try apply known hacks to all found servers. In this case your best friend should be Honey-Pots and prolog itself, because the probability of hacker interest to swi-prolog internals is extremely low. (Hacker need to study well the server code to find a door).
So I think you will found adequate methods to protect all sensitive data.
But please, never use passwords with combinations of dictionary words and the same password more then for one purpose, it is the most important rule of security. For the same reason you shouldn't give access for your users to all information, but protection should be on the app level design.
The cases specific to a local server are a good firewall, proper network setup and encription of hard drive partition if your local server can be stolen by "hacker".
But if you mean the application should be accessible only from your local network and not from Internet you need much less efforts, mainly you need check your router/firewall setup and the 4th door in my list.
In a case you have a very limited number of known users you can just propose them to use VPN and not protect your server as in the case of "global" access.
I'd point out that my post was about a security issue with using port forwarding in apache
to access a prolog server.
And I do know of a successful prolog injection DOS attack on a SWI-Prolog http framework based website. I don't believe the website's author wants the details made public, but the possibility is certainly real.
Obviously this attack vector is only possible if the site evaluates Turing complete code (or code which it can't prove will terminate).
A simple security precaution is to check the Request object and reject requests from anything but localhost.
I'd point out that the pldoc server only responds by default on localhost.
- Anne Ogborn
I think SWI_Prolog http package is an excellent choice. Jan Wielemaker put much effort in making it secure and scalable.
I don't think you need to worry about SQL injection, indeed would be strange to rely on SQL when you have Prolog power at your fingers...
Of course, you need to properly manage the http access in your server...
Just this morning there has been an interesting post in SWI-Prolog mailing list, about this topic: Anne Ogborn shares her experience...
Is it a huge security flaw to allow user to connect to your server via Remote Desktop? Right now i have a setup where i only allow a couple of ip-addresses to connect via the RDP port but i am thinking of removing this and allow all IP's to connect so i can RDP with my iPhone if there is some problem when I'm not at home.
So as long as i have a secure password do you guys think this is a bad idea? Is there anything else i can do to make it a bit more secure but still be able to connect from "wherever"? Is it for example possible to setup a page that i must visit that "allow anyone to login for 2 hours". Some kind of security by obscurity thingy?
Thankful for any help i can get.
Maybe you should post this question to serverfault. But anyway.
If you are using only user/password as the access method. Then it will be very easy for an attacker to lock your user ( or all users, thay don't even have to have terminal access rights ). So yes, it will be a huge security flaw. There are lots of way to protect from this treat and make rdp available from wherever. But I am not familiar with any of them.
It's very common to implement two-factor authentication for any remote access to corporate servers. In many companies you'll see the RSA tokens used as a second factor, albeit I prefer to use SMS --- it doesn't matter as long as you have two factors in play: something you know, something you have, something you are.
If your company doesn't want to implement a second factor then I still wouldn't recommend a publicly exposed RDP interface. It's open to brute force attacks, OS exploits or just plain old Denial of Service (if I blast your public interface with traffic then it will slow down legitimate machine use within your company). At a minimum I would look into tunneling over SSH, maybe with a client-side certificate authentication, or I would implement port knocking to get at the server interface in the first place.
It is a security flaw, but not so huge. Traffic is encrypted and reading user or password from it is not immediate as in text based protocols as in say ftp. It is just a little bit less secure than ssh.
It obviously has the same flaws as any other remote access (possible brute force or DOS attack). You should also use non a default account name to avoid simplifying task for attackers.
Your idea of opening access only after visiting some page is not bad either. Looks like it's a variant of the classical port knocking mechanism (but beware avoid opening a bigger hole).
What security best-practices would you strongly recommend in maintaining a Linux server? (i.e. bring up a firewall, disable unnecessary services, beware of suid executables, and so on.)
Also: is there a definitive reference on Selinux?
EDIT: Yes, I'm planning to put the machine on the Internet, with at least openvpn, ssh and apache (at the moment, without dynamic content), and to provide shell access to some people.
For SELinux I've found SELinux By Example to be really useful. It goes quite in-depth into keeping a sever as secure as possible and is pretty well written for such a wide topic.
In general though:
Disable anything you don't need. The wider the attack domain, the more likely you'll have a breach.
Use an intrusion detection system (IDS) layer in front of any meaningful servers.
Keep servers in a different security zone from your internal network.
Deploy updates as fast as possible.
Keep up to date on 0-day attacks for your remotely-accessible apps.
The short answer is, it depends. It depends on what you're using it for, which in turn influences how much effort you should put into securing the thing.
There are some handy hints in the answers to this question:
Securing a linux webserver for public access
If you're not throwing the box up onto the internet, some of those answers won't be relevant. if you're throwing it up onto the internet and hosting something even vaguely interesting on it, those answers are far too laissez-faire for you.
There's an NSA document "NSA Security Guide for RHEL5" available at:
http://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf
which is pretty helpful and at least systematic.
Limit the software to the only ones you really use
Limit the rights of the users, through sudo, ACLs, kernel capabilities and SELinux/AppArmor/PaX policies
Enforce use of hard passwords (no human understandable words, no birthday dates, etc.)
Make LXC countainers, chroot or vserver jails for the "dangerous" applications
Install some IDS, e.g. Snort for the network traffic and OSSEC for the log analysis
Monitor the server
Encrypt your sensible datas (truecrypt is a gift of the gods)
Patch your kernel with GRSecurity : this add a really nice level of paranoïa
That's more or less what I would do.
Edit : I added some ideas that I previously forgot to name ...
1.) Enabling only necessary and relevant ports.
2.) Regular scan of the network data in - out
3.) Regular Scan of ip addresses accessing the server and verify if any unusual data activity associated with those ip address as found from logs/traces
4.) If some some critical and confidential data and code, needs to be present on the server , may be it can be encrypted
-AD
Goals:
The hardest part is always defining your security goals. Everything else is relatively easy at that point.
Probing/research:
Consider the same approach that attackers would take, ie network reconnaissance (namp is pretty helpful for that).
More information:
SELinux by example is a helpful book, finding a good centralized source for SELinux information is still hard.
I have a small list of helpful links that I find useful time to time http://delicious.com/reverand_13/selinux
Helpful solution/tools:
As with what most people will say less is more. For an out of the box stripped down box with SELinux I would suggest clip (http://oss.tresys.com/projects/clip). A friend of mine used it in an academic simulation in which the box was under direct attack from other participants. I recall the story concluded very favorably for said box.
You will want to become familiar with writing SELinux policy. Modular policy can also become helpful. such tools as SLIDE and seedit (have not tried) may help you.
Don't use a DNS Server unless you have to . BIND has been a hotspot of security issues and exploits.
Hardening a Linux server is a vast topic and it primarily depend on your needs.
In general, you need to consider the following groups of concern (I'll give example of best practices in each group):
Boot and Disk
Ex1: Disable booting from external devices.
Ex2: Set a password for the GRUB bootloader - Ref.
File system partitioning
Ex1: Separate user Partitions (/home, /tmp, /var) from OS Partitions.
Ex2: Setup nosuid on partitions – in order to prevent privilege escalation with the setuid bit.
Kernel
Ex1: Update security patches.
Ex2: Read more in here.
Networking
Ex1: Close unused ports.
Ex2: Disable IP forwarding.
Ex3: Disable send packet redirects.
Users / Accounts
Ex1 : Enforce strong passwords (SHA512).
Ex2: Set up password aging and expiration.
Ex3: Restrict Users to Use Old Passwords.
Auditing and logging
Ex1: Configure auditd - ref.
Ex2: Configure logging with journald - ref.
Services
Ex1: Remove unused services like: FTP, DNS, LDAP, SMB, DHCP, NFS, SNMP, etc'.
EX2: If you're using a web server like Apache or nginx - don't run them as root - read more here.
Ex3: Secure SSH ref.
Software
Make sure you remove unused packages.
Read more:
https://www.computerworld.com/article/3144985/linux-hardening-a-15-step-checklist-for-a-secure-linux-server.html
https://www.tecmint.com/linux-server-hardening-security-tips/
https://cisofy.com/checklist/linux-security/
https://www.ucd.ie/t4cms/UCD%20Linux%20Security%20Checklist.pdf
https://www.cyberciti.biz/faq/linux-kernel-etcsysctl-conf-security-hardening/
https://securecompliance.co/linux-server-hardening-checklist/
Now specifically for SELinux:
First of all, make sure that SELinux is enabled in your machine.
Continue with the following guides:
https://www.digitalocean.com/community/tutorials/an-introduction-to-selinux-on-centos-7-part-1-basic-concepts
https://linuxtechlab.com/beginners-guide-to-selinux/
https://www.computernetworkingnotes.com/rhce-study-guide/selinux-explained-with-examples-in-easy-language.html