I'm having a bit of an issue with a Virtual Machine (VM) I have. Basically, I was trying to log into FTP on my web-server, but forgot the logins. As such, it has now blocked the VM's IP. I found it with:
iptables -L -n --line | grep "xxxxx"
Turns out it was blocked in the ALLOWIN and ALLOWOUT chains. So, I removed it with:
iptables -D ALLOWIN -s x.x.x.x -j DROP
iptables -D ALLOWOUT -s x.x.x.x -j DROP
The saved the config:
service iptables save
I even tried a reboot , using:
/etc/init.d/iptables restart
Then I try it on the VM, but it times out:
D:\Users\Andy>ping chambresdhotes.org
Pinging chambresdhotes.org [216.38.63.234] with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 216.38.63.234:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
I'm at a bit of a loss as to what else I can try. Any suggestions are much appreciated.
FWIW, I have also done an:
iptable -L | grep 123.123.123.123
..but it gives no results (which I assume means there are no matching rules!)
Ok, I'm deciding if I should delete this question or not - but think it may be good to leave up, in case anyone else has a similar issue.
I found the problem. The VM is with Amazon, so I thought I'd just do a search for "amazon" in the iptable -L. Turned out there was an IP that was blocked:
LOGDROPOUT all -- anywhere ec2-52-210-49-189.eu-west-1.compute.amazonaws.com
I removed that one from both the DENYIN and DENYOUT, saved + restarted iptables, and voila... it works now!
Related
When I'm teleworking, I need to access some internal web servers. I use ssh -f -N -D 4000 someserver.mywork.com on my home computer to setup local dynamic port forwarding. Then, I configure my web browser to use localhost port 4000 as a SOCKS host, and everything works great, even with HTTPS.
The problem is that the proxy stops working every couple of days. When this happens, the ssh process prints messages like the following:
accept: Too many open files
In this scenario, I have to kill the ssh process and restart it in order to get it working again. Based on my research into this error message, I could increase the limit on the number of open files, but that doesn't seem like a permanent or an ideal solution.
I was hoping autossh might be able to monitor the connection and restart it automatically. Is that possible?
I have tried the following command:
autossh -f -M 0 -N -D 4000 someserver.mywork.com
But it didn't work. The proxy stopped working, and autossh did not restart it. Any suggestions or alternative solutions to automatically restarting my ssh proxy?
Let me explain my very strange problem. I have one server (Linux Debian Jessie) which had access to my git repository on gitlab.com
Two days ago, I tried to pull some modifications on this server with a simple git pull. I received an error message :
ssh: connect to host gitlab.com port 22: Connection timed out
Si I have done some tests
1. TELNET
To understand why, I have tried a telnet on 22 port = TIMEOUT
2. IPTABLES
I checked my iptables to be sure that SSH port was allowed. It is. If I try a telnet on another service for example like github.com, it works. So I'm allowed in OUTPUT on this port.
3. PING
I thought a ip translation problem. I have done a ping, I obtain this message :
PING 104.210.2.228 (104.210.2.228) 56(84) bytes of data.
--- 104.210.2.228 ping statistics ---
87 packets transmitted, 0 received, 100% packet loss, time 86534ms
4. FAIL2BAN
I use fail2ban, so I have checked if gitlab was in jail address, but it seems not.
So my problem is that I can't reach gitlab.com
If I try from my local machine or from another server, I don't have this problem. It works.
I can't reach gitlab.com only from this server but I don't know why. Maybe someone has an idea which cans be very precious to help me ?
Probably some modification of firewall caused this. For a quick solution use http protocol instead of ssh. Change your url in the git config file to http.
git config --local -e
change entry of
url = git#gitlab.com:username/repo.git , to
url = https://gitlab.com/username/repo.git
You need to give your username and password to authenticate yourself while making a push or pull though as it's http based.
I have a GCE Instance a Debian 1v CPU & 1.7GB. Then I followed the below tutorial and installed webmin on it.
https://www.howtoforge.com/tutorial/how-to-install-webmin-on-ubuntu-15-04/
The installation went successfully. Then I Created a Firewall exception on using the UFW and allowed port 10000.
sudo ufw allow 10000/tcp
But I was not able to access Webmin through the browser.
https://my-gce-instance-ip-address:10000.
Then i created firewall exception using the Google Cloud Console. Again tried the url it didnt work.
Then i thought this might be because of webmin is https mode. So i open the /etc/webmin/miniserv.conf and changed ssl=0. After that i restarted the webmin.
/etc/init.d/webmin restart
Then I tried the the url with Http, still I can't access.
I tried below command and checked the output. Accordingly Webmin is correctly running and listening on port 10000.
netstat -tulpn | grep :10000.
I can't seem to think what I am doing wrong. I have now spent several days on this without and solution in sight. Hope someone can kindly help me?
try this ... it's working for me
iptables -I INPUT 1 -p tcp --dport 10000 -j ACCEPT
service iptables save
/etc/init.d/iptables restart
open both link in Browser
https://your-IP:10000
and
http://your-IP:10000
you need to allow port 10000 from iptables
sudo iptables -A INPUT -p tcp -m tcp --dport 10000 -j ACCEPT
this work for me
i'm using ubuntu 16.04
You don't need to do any firewall configuration in the instance itself. All firewall configuration is done in the Google Cloud console.
The steps I typically follow, as you show to have figured out in your comment, are:
Create the firewall rule, in it opening the particular port you need (10000 in the case of Webmin) for ingress TCP traffic, accepting connections from some IP range (e.g. 0.0.0.0/0), and specifying target tags to be later assigned to instances to which that rule shall apply.
Add one of those tags to the "network tags" section of some particular instance.
This alone should work, opening the port for your instance in the firewall.
I was almost creating another question here on SO when yours was suggested as a possible duplicate. I had followed the steps above on my Webmin machine, and yet the machine refused to connect on port 10000. As I kept writing the question, I figured out my particular problem: in the firewall rule, in the source IP range filter, I set the single meta-address 0.0.0.0 instead of the range 0.0.0.0/0. So, to anyone who has followed the steps above and still can't connect to their webmin installation, do check if your source range filter is correctly set.
We have just moved our web apps to a self hosted site on digital ocean, vs our previous web host. The instance is getting hammered by rpm's according to New Relic but we are seeing very few page views. Throughput RPM's are around the 400rpm stage where as we only have about 1 page view per minute.
When i look at the access log it is getting hammered with what i am guessing is spambots, trying to access the non existant downloads folder. Its causing my CPU to run at 95%, even though nothing is actually happening.
How can i stop this spamming access??
So far i have created a downloads folder and put a Deny All in a htaccess file in it. That appeared to cool things down but now its getting worse again (hence the desperate post)
Find a pattern of malevolent requests and restrict the IP they are coming from.
Require a hashed headrt to be provided for each request to verify the identity of the person/group wanting access.
Restrict more than N downloads to any IP over M time threshold.
Distribute traffic load via DNS proxying to multiple hosts/web servers.
Switch to NGINX. NGINX is more performant than Apache in most cases with "high-levels" of requests. See Digital Ocean's article --> https://www.digitalocean.com/community/tutorials/apache-vs-nginx-practical-considerations.
Make sure your firewall employs a whitelist of hosts/ports. NOT *
I'd use tables to drop any connection from the spam bot ip address.
Find which ips are connected to your apache server:
netstat -tn 2>/dev/null | grep :80 | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head
You should get something like:
20 49.237.134.0
10 31.187.6.0
15 166.137.246.0
Once you find the bot ip addresses (probably the ones with higher number of connections), use iptables to DROP further connections:
iptables -A INPUT -s 49.237.134.0 -p tcp --destination-port 80 -j DROP
iptables -A INPUT -s 31.187.6.0 -p tcp --destination-port 80 -j DROP
iptables -A INPUT -s 166.137.246.0 -p tcp --destination-port 80 -j DROP
Note:
Make sure you're not dropping connections from search engine bots like google, yahoo, etc...
You can use www.infobyip.com to get detailed information about a specific ip address.
I am running Fedora 18 with KDE. I opened port 5900 via the GUI yesterday and was using VNC just fine, but then tried to open the port for SMTP via a couple of different methods and now the VNC connection is "closing unexpectedly."
That's a vague error but I'm thinking it is a firewall issue. The problem is that I don't have any graphical way to access the firewall now, just via ssh. I tried adding an IPTABLES line, iptables -A INPUT -p tcp --dport 5900 -j ACCEPT, but that didn't seem to make a difference and when I tried iptables --List there was nothing that appeared to be about port 5900. Did I do the iptables line wrong? Should it be OUTPUT instead of INPUT? -I instead of -A? udp instead of tcp?
I would also like to know why "iptables --List" did not seem to have anything about port 5900 in it. Is it possible that Fedora 18 no longer uses iptables?
Anyone have suggestions? It's been hours since I've had no GUI access and I'm getting desperate... :-)
/sbin/service iptables restart
was the missing ingredient to this puzzle. For some reason /sbin/service firewall restart did not work...
Did you save the iptable before you restarted it with
/sbin/service iptables save