How do I block direct access to Nexus except for localhost? - reverse-proxy

I have a Nexus standalone install (2.7.0) that is fronted with an IHS reverse proxy. I want to block direct access to the Nexus instance so that users are forced to use the IHS front end.
How do I configure this in Nexus?

By default Nexus listens on all network interfaces.
You can change this by editing $NEXUS_HOME/conf/nexus.properties and changing this line:
application-host=0.0.0.0
Set it to an address on a restricted subnet, such as the loopback address:
application-host=127.0.0.1

You would configure that in your reverse proxy simply not allowing e.g. port 8081 through.

Related

Apache and Yarn ports

I want to configure both apache and yarn servers on the same machine. Default web port is 80 and 443 for ssl as far as I know.
Is that possible for both services to share the same ports? What I need is:
http(s)://example1.com - go to apache server
http(s)://example2.com - go to yarn
I know I can configure it so I call:
http(s)://example1.com:3000 or other port. It's not intuitive for users however.
Or... make htaccess rule to redirect example1.com:80 to example1.com:81 for example? Or somehow internally redirect from apache to yarn...? :)
I'm pretty newbie in configuring servers... I always used default settings and vhosts and it was just enough. In fact I've never work with yarn at all so any advices will be appreciated.
Solved:
apache in vhosts configuration is redirecting specific domain traffic from :80 to :3000 and node is run on 3000 port.
In my opinion you can using haproxy or squid proxy, to loading balancing, or you can set on domain server to set pointing the domain, but you must set other port on of app, on this case we must try to easy access without type the port on the address bar

Apache HTTP ProxyPass inside Docker container linked to other containers: Wrong remote IP interpreted by linked container

I am migrating an Apache configuration from plain host-based Ubuntu to container-based CoreOS. I have only one instance of CoreOS for exploratory purposes and personal use, so I don't really need a cloud infrastructure compatible solution for this task. Assume all containers are running on the same physical machine.
That Apache configuration was a virtual host ProxyPass with ProxyPreserveHost On. On Ubuntu with an Apache installed on the host machine and no Docker, all is well. The objective is to host multiple web services on the same machine, with each web service being on its own subdomain, on port 443.
For instance, I currently have on my CoreOS installation:
example.com (website)
gitlab.example.com (gitlab)
jenkins.example.com (jenkins)
sonar.example.com (sonar)
monitoring.app.example.com (python)
event.api.example.com (java)
legacy.api.example.com (php)
Every one of these web services are running in separate containers, and their ports are NOT published (not accessible from the Internet). As for Apache, it's running on its own container, and its ports are exposed.
I am using container linking to achieve the virtual hosts to ProxyPass behavior: --link gitlab:gitlab \ and ProxyPass / https://gitlab:443/
I am now facing a problem: If I watch the Apache Logs, I can see incoming connections are logging with the expected client IP address. However, the recorded incoming connections seen by the target containers are a container's IP address i.e. 172.17.0.1.
Due to the diversity of the target container web services (gitlab, python, java, php...), I am NOT able to tweak the implementation of these web services so that they pick the IP from another location let's say X-Forwarded-For.
What would be a way to make it so the target containers see the desired IP address they would have seen if they weren't running in Docker? I am open to solutions that involve throwing away Apache HTTP as long as the desired use case is accomplished (port 443 exposed to Internet: one domain -> one webservice, client IP preserved).
Please note that I was not able to use --net=host on the Apache server, because this option is incompatible with container links.
Links are legacy technology which is being phased out, but you are right, container sharing host network cannot be connected to any other network type.
# docker network connect bridge container
Error response from daemon: Container sharing network namespace with another container or host cannot be connected to any other network
Use pipework to connect your apache to the outside network. Put apache and all other containers in the bridge network to provide internal connectivity.
Keep an eye on macvlan driver which you should use instead of pipework once it comes out of "experimental" build.

Cannot access JBoss using localhost in my machine but working fine with loopback IP and HostName even in Remote Machine

I am using JBoss Server with Maven plugin and I cannot access the JBoss Application using localhost:8080. But using loopback ip(127.0.0.1) or HostName is working fine. I can even access it in other machines in my network using hostname. But using localhost in my machine is not working.
I am using JBoss-7.1.1 on a windows7 machine.
This sounds like a network problem and not a JBoss issue.
Make sure that the loopback IP (127.0.0.1) is correctly set in your host file.
Also check the configured interfaces of JBoss.
https://docs.jboss.org/author/display/AS7/Interfaces+and+ports

How do ensure that Apache AJP to Tomcat connection is secure/encrypted?

We want to front-end our Tomcat instance with an Apache instance (running on the same machine) that will be serving everything on HTTPS and connect Apache to Tomcat using AJP. When using AJP, do we need to do anything to make sure that the connection between Apache and Tomcat is secure? (We dont want passwords to be sniffable on the network between Apache and Tomcat). The O/S is Red Hat Enterprise Linux 6.3
You are saying
Tomcat instance with an Apache instance (running on the same machine)
and later you are saying
We dont want passwords to be sniffable on the network between Apache and Tomcat
This just contradicts each other.
EDIT: AJP is not designed to be secure, if you need security, use mod_proxy_http and proxy over https, or create SSH tunnel. Needless to say, you will have to pay for this overhead.
When using AJP you cannot do anything to ensure it is secure. It isn't. There is no SSL version. You would have to use HTTPS. AJP is designed for the usual case where HTTPD and Tomcat are in the same private LAN and security isn't an issue.

SVN: remote access isn't working

I've installed subversion and apache on my pc. I can access to my repository using followinf url
http://localhost/svn/repos/
Now I want other members of my group to access the project files I've put in my repository. As it's my first time using svn I looked for the solutions and I think I'm a bit lost.
I read about port forwarding in my router so I opened my router interface. I went to NAT/PAT section of my router configuration and added a new rule with following caracteristics:
Application: svn
External port:3690
Internal port:80
protocol : TCP
equipment: myPC
And Checked the option "Active". But I think I'm missing something.
I read in an article that to verify if the remote access is working i have to go to
svn://83.200.108.71
While it doesn't work. "unable to connect.."
Can someone please help me .
Wait... You can access your repository via http://? Why not let others access the repository using http://?
Don't do anything with your router. Don't muck with ports. Apache httpd is serving your repository just fine off of Port 80. Tell your users to simply access your repository via http://<machineName>/svn/repos. That's all there is to it.
svn:// is a completely different protocol than http://. Port 3690 just happens to be the default port of svn://, but that doesn't mean if you reroute your http:// protocol there, everything will work.
Most of the time, people who first use Subversion set up the svnserve server instead of Apache httpd because it's easier than using Apache http. Here's how you setup a repository to use svn://:
$ svnadmin create my_repos #
$ vi my_repos/conf/svnserve.conf #Need to denop 'password-db=passwd' line
$ vi my_repos/conf/passwd #Need to setup user accounts
$ svnserve -r my_repos -d
And that's it. Now your users can access the repository via svn://<machineName>.
Although svnserve is simpler and easier than Apache (and faster), there are many reasons to use Apache httpd over svnserve:
Port 80 is likely not blocked by network while port 3690 maybe blocked
You can let Apache httpd use LDAP for authentication (which can also allow Windows Active Directory authentication)
Apache httpd can service multiple repositories while svnserve can only service a single repository on port 3690.