I'm using CouchdDB on MacOSX El Captain and trying to use https. Adaptations in the local.ini file are:
[ssl]
verify_ssl_certificates = false
ssl_certificate_max_depth = 1
cert_file = /opt/local/etc/couchdb/certs/localhost.crt
key_file = /opt/local/etc/couchdb/certs/localhost.key
port = 6984
But in how far can I prevent access through the 5984 port?
Under [daemons], remove (if it is there, or comment it out):
httpd={couch_httpd, start_link, []}
and put in,
httpsd = {couch_httpd, start_link, [https]}
Then, restart couchdb.
You can disable access to the http port 5984 via your firewall.
For example, in CentOS,
iptables --append INPUT --protocol tcp --sport 5984 --dport 5984 --jump DROP
Same idea can be applied to every OS. In MacOS, you can block the port using the System Preferences > Security > Firewall user interface.
Related
I have a problem with my gitea version 1.15.5 running on my raspberry pi. I appears that the built in ssh server is not starting:
ssh -p 2222 git#myaddress.com
ssh: connect to host myaddress.com port 2222: Connection refused
I already assured that "myaddress.com" points to the correct machine and that the firewall rules are adapted. The web interface works just fine.
When I checked, if the port is actually used by gitea, I realized the built-in ssh server is not running:
sudo lsof -i -P -n | grep LISTEN
sshd [...] root [...] TCP *:22 (LISTEN)
sshd [...] root [...] TCP *:22 (LISTEN)
[...]
gitea [...] git [...] TCP *:3000 (LISTEN)
As you can see, there is no process listening on port 2222.
I have an internal sshd server running on that machine at port 22 and I would like to keep those two seperate, if possible. Or is the problem lying there and you can't use the built-in gitea ssh server together with an sshd server?
Here is an excerpt of my app.ini configuration:
APP_NAME = gitea
RUN_USER = git
RUN_MODE = prod
[server]
SSH_DOMAIN = myaddress.com
DOMAIN = myaddress.com
HTTP_PORT = 3000
ROOT_URL = https://myaddress.com/
DISABLE_SSH = false
SSH_PORT = 2222
After some more googling, I found the solution myself:
If there is an sshd server running, gitea does not automatically start its built-in ssh server. Instead, you have to force it by adding this line under [server] in the app.ini configuration:
[server]
START_SSH_SERVER = true
Since, according to the gitea config cheat sheet:
START_SSH_SERVER: false: When enabled, use the built-in SSH server.
I've posted this, in case anyone ever runs into the same problem.
I have the following settings in my /etc/ssh/ssh_config file:
Host serverA
User idA
Host serverB
User idB
ProxyJump serverA
I’ve also copied the public keys, so if I locally run ssh serverB I’m correctly connected to serverB as idB through serverA.
Now, here’s my runner configuration in /etc/gitlab-runner/config.toml:
[[runners]]
name = "ssh-runner-1"
url = "http://my-cicd-server"
token = "xxxxxxxxxxxxxxxx"
executor = "ssh"
[runners.custom_build_dir]
[runners.cache]
[runners.cache.s3]
[runners.cache.gcs]
[runners.cache.azure]
[runners.ssh]
user = "idB"
host = "serverB"
identity_file = "/home/gitlab-runner/.ssh/id_ed25519"
When I run a CI/CD job on this runner I get a « connection refused » error:
ERROR: Preparation failed: ssh command Connect() error: ssh Dial() error: dial tcp xxx.xxx.xxx.xxx:22: connect: connection refused
I conclude that the ProxyJump configuration is not applied, and since the machine with the runner can’t directly connect to serverB, I get denied access.
How can I configure the runner to apply the proxy jump configuration?
The GitLab runner uses a Go-based SSH client. It does not respect your system SSH configuration and does not have the same configurability as the standard ssh (usually OpenSSH) packages you typically find installed in operating system distributions or similar packages.
The Go client does not support the ProxyJump configuration.
Your best bet would probably be to configure a tunneled connection where your entrypoint does not require SSH configuration options that are not supported.
Local port forwarding
One way might be to open a local port-forwarding tunnel, then in your GitLab configuration, specify the host as localhost and port as the forwarded port.
For example:
Open the tunnel -- local port 2222 forwards to port 22 on ServerB via ssh connection through ServerA
ssh -L 2222:ServerB:22 -N ServerA
Configure runner to use the tunnel:
...
[runners.ssh]
host = "localhost"
port = 2222
...
With this approach, you may have to write some automation on your server to restore the tunnel connection in the event it is broken. How you might do this depends on your operating system and preferred service manager. Or use a tool like autossh
This is basically how the ProxyJump configuration works under the hood.
IP/Port forwarding system
A similar approach would be to have your jump system automatically forward connections to the desired destination. This might be something like a software firewall rule (e.g. using iptables routing rules). That way the forwarding occurs transparently. Then simply tell the runner to target ServerA and the traffic will be transparently moved to ServerB.
This approach is more reliable, since you won't have to do anything to keep the tunnel alive if it ever drops. However, the configuration is much more complex and requires a static IP for ServerB.
For example, on ServerA, assuming the IP of ServerB is 10.10.10.10 the following iptables configuration could be used:
iptables -t nat -A PREROUTING -p tcp --dport 2222 -j DNAT --to-destination 10.10.10.10:22
iptables -t nat -A POSTROUTING -j MASQUERADE
reference.
Then the GitLab runner configuration:
...
[runners.ssh]
host = "ServerA"
port = 2222
...
Lastly, it may also be useful to know that disable_strict_host_key_checking is an undocumented configuration option for the runner as well, in the event you need this.
I have a webapp running on a Raspberry Pi, which is behind a NAT, and I'm trying to make a tunnel to the company's server so that I can access it from the web. Right now I've been able to establish a tunnel using ssh -fN -R 192.168.0.28:54321:localhost:443 username#192.168.0.28 (both the server and the RPi are in the same LAN at the time), and doing curl -k https://192.168.0.28:54321 returns the contents of the webpage hosted in the RPi, but only if I do it from the server. I have set GatewayPorts yes and AllowTcpForwarding yes (which anyway is the default).
It was the firewall on the server blocking the port. ¬¬
To open said port, the command is sudo iptables -I INPUT -p tcp --dport 54321 -j ACCEPT, which says that any connection comming to the TCP port 54321 must be accepted.
I want to make sure that the only network traffic on my linux CentOS server is my own.
All my server runs is a Tomcat instance with one servlet. This servlet takes a parameter, which is a URL to download. It will download from that url, and pass the contents back to the calling program through the usual http response.
I want to block all network traffic to this server except
1) Ability to ssh
2) Ability to download from host abc.xyz.com
3) Ability for server with IP 111.222.333.444 to download from me
Can someone please tell me the commands to do this in iptables? I tried finding this out myself but I was a bit out my depth with the lingo.
thanks
Configuring a firewall is simple, first of all select what ports you want to be open.
For example Webserver ports:
iptables -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
For example SSH port:
iptables -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
In any way your server is able to download files from other server/hosts.
3) Ability for server with IP 111.222.333.444 to download from me
I suppose that must be port 80, (or any port where the server is downloading from) if your uploading files to your website.
After these steps you need to look if the firewall is configured right:
iptables -L -n
If it's looking good then you're able to save your iptables, and restart the service.
If there is any problem configureren your firewall, please let me know.
Is it possible to access my Apache server from outside the VirtualBox on Google Chrome browser? Its running on CentOS 7 on VirtualBox.
I have tried connecting to the ip address of the CentOS virtual machine but it didn't work. Its using 'Bridged Adapter' networking in the VM settings and i checked the ip address using the 'ip addr' command. Thanks.
Of course you can. Though you need to add a tunnel to allow access to your Centos 7 machine web service from the host machine.
For example, my VM's bridge IP address (the interface that connects to the world) is 192.168.1.38 and its interface is enp0s3. Let's say I'm running the web service on my second interface, enp0s8 with IP 192.168.100.101 on port 8000. Here's how you create the tunnel:
iptables -t nat -A PREROUTING -p tcp -i enp0s3 --dport 80 -j DNAT --to-destination 192.168.100.101:8000
services iptables save
That's it. You should be able to go to your host's Chrome browser and type in the url 192.168.1.38 and be presented with your web service. If it's still not working I'd suggest looking into your iptables rules to see if any is blocking this traffic.