I'm doing some sort of school project where i have to make my vm (using virtualbox for hosting the vm) communicate with my host pc using port 6969.
The problem is that even after all the things I tried to open this particular port, the vm still says connection refused.
I'm using bridge adapter, the vm is a linux one, and my host is manjaro.
I cannot do any sudoer thing on the vm, it's mounted on an iso given by the school that is sure to be working fine (no one besides me had any problem with it) but is not giving me any admin rights.
Ssh connection are fine though, here are a few commands I ran on the vm :
$> nc -zvw10 192.168.1.40 6969
nc: connect to 192.168.1.40 port 6969 (tcp) failed: Connection refused
$> nc -zvw10 192.168.1.40 22
Connection to 192.168.1.40 22 port [tcp/ssh] succeeded!
And my opened and flushed iptables on host side :
$> sudo iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Any idea on things to try would help me so much.
Thanks for reading.
Related
I'm trying to get a basic Express application running on an AWS EC2 Ubuntu Linux instance.
On such systems, the server has to be run as a super user to listen to port 80. But that would be a bad practice, so instead you're supposed to listen to a different port (eg. 3000) and redirect traffic from port 80 to 3000.
To forward the port I tried using this command from another Stack Overflow answer, Node.js + Express: app won't start listening on port 80):
sudo iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-ports 3000
I've run that command (and re-run it to be sure), but even so it doesn't seem to be forwarding 3000 to 80, because I can only access my server on port 3000:
curl localhost:3000
*html*
curl localhost
curl: (7) Failed to connect to localhost port 80 after 0 ms: Connection refused
I have no idea what I did wrong, but I know nothing about iptables, so any help would be appreciated.
P.S. I've tried checking the iptables records with the command sudo iptables -L -n -v, but the results don't say anything about ports (and again, I don't know iptables), so I'm not sure if it's saying my command worked or not:
Chain INPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target
prot opt in out source destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target
prot opt in out source destination
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target
prot opt in out source destination
The reason your test doesn't work is because trying to access the service from localhost bypasses the NAT table. You need to test from a different host. It should then work presuming the rule is loaded correctly and there is no firewall or other rules interfering.
Note, there are multiple other, probably better ways, to get get a non-privileged process bound to a privileged port. There is a big discussion in Is there a way for non-root processes to bind to "privileged" ports on Linux? which includes the solution your using among others.
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 changed my ssh port (for security reason), and I added these lines to my file: /etc/fail2ban/jail.local
[sshd]
enabled = true
port = 18249
#port = ssh,sftp,18249
Now when I run this command:
sudo fail2ban-client status sshd
i get this result:
Status for the jail: sshd
|- Filter
| |- Currently failed: 0
| |- Total failed: 0
| `- File list: /var/log/auth.log
`- Actions
|- Currently banned: 0
|- Total banned: 0
`- Banned IP list:
Beautiful and fantastic, but it also seems too good to be true... (I have had periods when there were thousands of attempts to access ssh.), doubt comes.
Is there any other way to understand/confirm if the filter is working?
Or does it work, it's all right, it's all configured correctly, and I'm worrying about nothing?
(P.S. that's not my port)
You could connect to your server from another computer and intentionally fail the ssh login. Then, check your fail2ban logs in /var/log/fail2ban.log and expect something like this:
...
2006-02-13 15:52:30,388 fail2ban.actions: WARNING [sendmail] Ban XXX.66.82.116
2006-02-13 15:59:29,295 fail2ban.actions: WARNING [sendmail] Ban XXX.27.118.100
2006-02-13 16:07:31,183 fail2ban.actions: WARNING [sendmail] Unban XXX.66.82.116
2006-02-13 16:14:29,530 fail2ban.actions: WARNING [sendmail] Unban XXX.27.118.100
2006-02-13 16:56:27,086 fail2ban.actions: WARNING [ssh] Ban XXX.136.60.164
2006-02-13 17:11:27,833 fail2ban.actions: WARNING [ssh] Unban XXX.136.60.164
Taken from here.
I had the same concerns when configuring it for my server. What I did back then is reduce the ban time to 30s, make some wrong logins from another machine (you can even use an android phone with JuiceSSH) and check the logs. Remember to increase the ban time once it works as expected!
lets say our ssh port is 2222.
just manually ban any ip:
fail2ban-client set sshd banip 111.111.111.111
and verify if a new iptables rules became active:
iptables -n -L --line-numbers
there you should see something like this:
Chain INPUT (policy ACCEPT)
num target prot opt source destination
1 f2b-sshd tcp -- 0.0.0.0/0 0.0.0.0/0 multiport dports 2222
.
.
.
.
Chain f2b-sshd (1 references)
num target prot opt source destination
1 REJECT all -- 111.111.111.111 0.0.0.0/0 reject-with icmp-port-unreachable
okay, this doesn´t give you the confirmation, that the service itself is working correctly, at least it proves, that fail2ban is using the correct port and the process of "banip" is working as it should.
after checking the iptables rules, you can call the same fail2ban-command with unbanip to remove the test-ban. after that, you shouldn´t see 111.111.111.111 anywhere inside the iptables rules.
I am using Red Hat 4.4.7-4 . I have installed Apache Server using
yum install httpd
/etc/init.d/httpd start
/etc/init.d/httpd status
httpd (pid 1371) is running...
This machine can be accesses through a VPN client using ssh terminal. When I hit
http://ip address:80
in a browser, the page doesnt load. I get the following error:
This Page Cannot Be Displayed
The system cannot communicate with the external server ( 173.39.232.226 ). The Internet server may be busy, may be permanently down, or may be unreachable because of network problems.
Please check the spelling of the Internet address entered. If it is correct, try this request later.
If you have questions, or feel this is an error, please contact your corporate network administrator and provide the codes shown below.
Notification codes: (1, GATEWAY_TIMEOUT, 173.39.232.226)
Also, below is the output of iptables
[root#blended-services-demo html]# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT tcp -- anywhere anywhere tcp dpt:http
ACCEPT tcp -- anywhere anywhere tcp dpt:http
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
You probalby need to enable access to your server on port 80 as it is currently being blocked by iptables.
sudo /sbin/iptables -I INPUT -p tcp -m tcp --dport 80 -j ACCEPT
This will insert the rule into your iptables configuration at the start. Once you have done this and tested that it works then you should save the configuration so that it it is used next time the service starts,
sudo /sbin/service iptables save
this will write the current configuration to /etc/sysconfig/iptables.
if this dont solve your problem, i suggest you take a look here:
apache not accepting incoming connections from outside of localhost
I installed OpenStack on RHEL6 using DevStack and had it running nicely. One day one of our "system administrators" noticed that iptables was running on the system and decided to turn it off (chkconfig iptables off). He then restarted the server and didn't tell me for a couple days. After he told me I quickly checked to see if I could access my instances. While Horizon was accessible, since nothing is being blocked, and I could access my instances from the Console, these instances could not access the network. After this I tried to access the instances from the server via SSH. The private IP was not accessible.
I then tried to restart iptables, which came up... and blocked the horizon dashboard. So I then attempted to restart all the open stack services... still no access to Horizon or any of the instances, but at least now my IPTables was populated with nova rules
Chain INPUT (policy ACCEPT)
target prot opt source destination
nova-api-INPUT all -- anywhere anywhere
nova-network-INPUT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT icmp -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh
REJECT all -- anywhere anywhere reject-with icmp-host-prohibited
ACCEPT tcp -- anywhere anywhere multiport dports https
ACCEPT tcp -- anywhere anywhere multiport dports http
Chain FORWARD (policy ACCEPT)
target prot opt source destination
nova-filter-top all -- anywhere anywhere
nova-api-FORWARD all -- anywhere anywhere
nova-network-FORWARD all -- anywhere anywhere
REJECT all -- anywhere anywhere reject-with icmp-host-prohibited
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
nova-filter-top all -- anywhere anywhere
nova-api-OUTPUT all -- anywhere anywhere
nova-network-OUTPUT all -- anywhere anywhere
Chain nova-api-FORWARD (1 references)
target prot opt source destination
Chain nova-api-INPUT (1 references)
target prot opt source destination
ACCEPT tcp -- anywhere devcloud.camb.comdev.ca tcp dpt:8775
Chain nova-api-OUTPUT (1 references)
target prot opt source destination
Chain nova-api-local (1 references)
target prot opt source destination
Chain nova-filter-top (2 references)
target prot opt source destination
nova-api-local all -- anywhere anywhere
nova-network-local all -- anywhere anywhere
Chain nova-network-FORWARD (1 references)
target prot opt source destination
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
Chain nova-network-INPUT (1 references)
target prot opt source destination
ACCEPT udp -- anywhere anywhere udp dpt:bootps
ACCEPT tcp -- anywhere anywhere tcp dpt:bootps
ACCEPT udp -- anywhere anywhere udp dpt:domain
ACCEPT tcp -- anywhere anywhere tcp dpt:domain
Chain nova-network-OUTPUT (1 references)
target prot opt source destination
Chain nova-network-local (1 references)
target prot opt source destination
None of these rules allows allow remote access to Horizon, and they don't even allow local access to the instances that should be running. On top of that, before iptables was turned off I was able to allow Apache HTTPD to listen on any port, but that functionality seems to be stopped now as well.
Right now, the only thing I can think of is starting fresh because I don't have a clue where to look. I've been reading up on iptables and OpenStack and how they work together but haven't been able to find any solution. Can anyone point me in a direction that might help?
I had considered adding rules to the IPtables rules directly, but these would be overridden by nova anytime a change is made or it is restarted which would make this impossible to maintain.
I had same issue. I logged in the console and found that INPUT and FORWARD policies were set to drop. To fix this issue:
$ sudo iptables -A INPUT ACCEPT
$ sudo iptables -A FORWARD ACCEPT
then I could ssh and open the dashboard.