This question has been asked several times but none of the answers works for me. This is very simple, I want to block some IP access to a server
I tried this:
.htaccess
Order Deny,Allow
Deny from 151.101.52.84
iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
DROP all -- 151.101.52.0/24 anywhere
REJECT tcp -- 151.101.52.84 anywhere tcp reject-with icmp-port-unreachable
DROP all -- 151.101.52.84 anywhere
DROP all -- 151.101.52.84 anywhere
DROP tcp -- 151.101.52.84 anywhere
ACCEPT tcp -- anywhere anywhere tcp dpt:http limit: avg 100/min burst 200
/etc/hosts.deny
ALL : 151.101.52.84
netstat -te | grep 151.101
tcp 0 1 ip-*-*-*-*.us-we:51181 151.101.52.84:http SYN_SENT apache 800352623
Already restarted httpd
Even I blocked the IP via Amazon EC2 VPC
Need to restart entire server? Need something else with iptables?
Have you tried Fail2Ban?
sudo apt-get install fail2ban
Related
I'm trying to allow only certain IP addresses to access ports exposed by docker containers on the host. All the rest external IPs should not be able to access them (even if I expose a port on 0.0.0.0). There is a plenty of workarounds across the internet how to achieve that - starting with disabling iptables management for docker and manage all the iptables rules manually (which is not so cool, especially if you have to deal with docker swarm ingress routing etc.), till dirty solutions with resetting iptables rules with cronjobs and custom scripts. But hey, we have a DOCKER-USER chain, which seems to be suitable for such kind of stuff?
The Docker-vs-Firewall Problem
As we know, upon startup docker adds some iptables chains and rules in order to do its networking magic. The thing is that it adds these chains at the very top of the FORWARD chain on every docker service restart, which means that all your predefined rules with rejects on that chain become completely useless. Docker documentation suggests to use its DOCKER-USER chain for such kind of things (rules in this chain stay persistent from docker's perspective and are executed before any other docker rules).
From the example in docker documentation we see that we can allow access for one IP (and deny for others) using
-I DOCKER-USER -i eth0 ! -s 1.2.3.4 -j DROP
This command kind of works and only IP 1.2.3.4 can access docker's exposed ports. But the problem is that in this case containers aren't able to connect to Internet.
So the situation is...
With
Chain DOCKER-USER (1 references)
target prot opt source destination
RETURN all -- 0.0.0.0/0 0.0.0.0/0
everything works and all the external traffic is allowed, and with:
Chain DOCKER-USER (1 references)
target prot opt source destination
DROP all -- !1.2.3.4 0.0.0.0/0
RETURN all -- 0.0.0.0/0 0.0.0.0/0
only IP 1.2.3.4 is allowed to access docker's exposed services (which is nice!), but there's no Internet connection from inside containers. That's a problem. No other iptables rules are added - only docker's default + this one custom DROP in DOCKER-USER chain. I was trying to RETURN internal IP ranges like 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16 in this chain (some of forum threads suggested to try that), so my chain had looked like:
Chain DOCKER-USER (1 references)
target prot opt source destination
RETURN all -- 192.168.0.0/16 0.0.0.0/0
RETURN all -- 172.16.0.0/12 0.0.0.0/0
RETURN all -- 10.0.0.0/8 0.0.0.0/0
ACCEPT all -- 1.2.3.4 0.0.0.0/0
DROP all -- 0.0.0.0/0 0.0.0.0/0
but still no success - docker's exposed ports are accessible only from 1.2.3.4 (which is nice again), but still no Internet connection from the container.
Any ideas on why is this happening and how could I allow containers to communicate with outside world while restricting inbound traffic?
Thanks in advance!
*filter
:DOCKER-USER - [0:0]
-A DOCKER-USER -m state --state RELATED,ESTABLISHED -j ACCEPT
-A DOCKER-USER -s A.B.C.D -j ACCEPT
-A DOCKER-USER -i MY_WAN_INTERFACE_NAME -j DROP
I am new to ssh and Centos 6.4 and I want to run nodejs on port 80. But couldn't make it to work external.
When I type netstat -anp | grep 8080 I can see that my node listening.
tcp 0 0 0.0.0.0:8080 0.0.0.0:* LISTEN 7976/node
But it is not going external.
I tried to add settings to iptables and result is same again. It is not working.
[root#culturalinfluences ~]# iptables --list
Chain INPUT (policy ACCEPT)
target prot opt source destination
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 tcp dpt:http
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:http /* node.js port */
ACCEPT tcp -- anywhere anywhere tcp dpt:http
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:webcache /* node.js port */
Chain FORWARD (policy ACCEPT)
target prot opt source destination
REJECT all -- anywhere anywhere reject-with icmp-host-prohibited
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Here is my nodejs
var port = 8080;
app.listen(port, "0.0.0.0" ,function() {
console.log("Listening on " + port);
});
Thank you four understand cause I am really new into linux and its iptables system. I am sure people like me will search the same issue and I hope they will find answer from this question.
Thank you for your helps.
You have a
REJECT all -- anywhere anywhere reject-with icmp-host-prohibited
right before the "http" ports you're allowing, so those rules will never be reached. Move the REJECT all rule to the bottom of the list instead.
Additionally you may want to use -n on the iptables command line to make sure the port numbers are right and aren't 80 instead of 8080 for example.
I have installed snmpd on my Ubuntu server via apt-get install snmpd snmp. Then I changed the line in /etc/default/snmpd
SNMPDOPTS='-Lsd -Lf /dev/null -u snmp -g snmp -I -smux -p /var/run/snmpd.pid 0.0.0.0'
After that, I restarted the snmpd server(/etc/init.d/snmpd restart). However, when I ran netstat -an | grep "LISTEN ", I don't see snmpd is listening on port 161.
I don't have any firewall which blocks that port.
$ 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
User "nos" is correct; UDP bindings do not show up as "LISTEN" under "netstat". Instead, you will see a line or two like the following, showing that "snmpd" is indeed ready to receive data on UDP port 161:
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
udp 0 0 0.0.0.0:161 0.0.0.0:* 1785/snmpd
udp6 0 0 ::1:161 :::* 1785/snmpd
The "netstat" manpage has this to say about the "State" column:
The state of the socket. Since there are no states in raw mode and usually no states used in UDP, this column may be left blank.
Thus, you would not expect to see the word "LISTEN" here.
From a practical perspective, however, there is one more thing that I'd like to note. Often, the default Net-SNMP "snmpd.conf" configuration file limits incoming connections to only local processes.
Default /etc/snmp/snmpd.conf
# Listen for connections from the local system only
agentAddress udp:127.0.0.1:161
# Listen for connections on all interfaces (both IPv4 *and* IPv6)
#agentAddress udp:161,udp6:[::1]:161,tcp:161,tcp6:[::1]:161
Usually, the point of setting up "snmpd" is so that another machine can monitor it. To accomplish this, make sure that the first line is commented out and that the second line is enabled.
Looks like it is listening on 161/UDP. From the man page:
By default, snmpd listens for incoming SNMP requests on UDP port 161 on all IPv4 interfaces. However, it is possible to modify this behaviour by specifying one or more listening addresses as arguments to snmpd. A listening address takes the form: [<transport-specifier>:]<transport-address>
Read the man page for more details
I'm struggling to understand why I can't open port 61616 by adding IPTABLES rule. Here is the listing of all rules, obtained via IPTABLES -L command.
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT tcp -- anywhere anywhere tcp dpt:61616
ACCEPT udp -- anywhere anywhere udp dpt:cslistener
ACCEPT tcp -- anywhere anywhere tcp dpt:cslistener
ACCEPT tcp -- anywhere anywhere tcp dpt:webcache
ACCEPT tcp -- anywhere anywhere tcp dpt:smtp
RH-Firewall-1-INPUT all -- anywhere anywhere
Chain FORWARD (policy ACCEPT)
target prot opt source destination
RH-Firewall-1-INPUT all -- anywhere anywhere
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain RH-Firewall-1-INPUT (2 references)
target prot opt source destination
ACCEPT tcp -- anywhere anywhere tcp dpt:61616
ACCEPT tcp -- anywhere anywhere tcp dpt:http
ACCEPT all -- anywhere anywhere
ACCEPT icmp -- anywhere anywhere icmp any
ACCEPT esp -- anywhere anywhere
ACCEPT ah -- anywhere anywhere
ACCEPT udp -- anywhere 224.0.0.251 udp dpt:mdns
ACCEPT udp -- anywhere anywhere udp dpt:ipp
ACCEPT tcp -- anywhere anywhere tcp dpt:ipp
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh
REJECT all -- anywhere anywhere reject-with icmp-host-prohibited
As much as I'm ignorant about IPTABLES, what confuses me is that http port is visible from the outside, yet port 61616 still isn't. For me, the rules look the same. Anyways, all help's appreciated.
Best
Maybe you try to open port for host in the network behind the CentOS host (CentOS host is firewall for network)?
If so, you must add rule for chain FORWARD of table filter, and you should
add rule for DNAT to some IP in network x.x.x.x
iptables -A FORWARD -p tcp --dport 61616 -j ACCEPT
iptables -A PREROUTING -t nat -p tcp --dport 61616 -j DNAT --to-destinanion x.x.x.x
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I'm writing a bash script to add simple firewalling for Xen.
Here's the actual firewall configuration :
Chain INPUT (policy ACCEPT)
target prot opt source destination
RH-Firewall-1-INPUT all -- anywhere anywhere
Chain FORWARD (policy ACCEPT)
target prot opt source destination
RH-Firewall-1-INPUT all -- anywhere anywhere
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain RH-Firewall-1-INPUT (2 references)
target prot opt source destination
ACCEPT all -- anywhere anywhere
ACCEPT icmp -- anywhere anywhere icmp any
ACCEPT esp -- anywhere anywhere
ACCEPT ah -- anywhere anywhere
ACCEPT udp -- anywhere 224.0.0.251 udp dpt:mdns
ACCEPT udp -- anywhere anywhere udp dpt:ipp
ACCEPT tcp -- anywhere anywhere tcp dpt:ipp
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT udp -- anywhere anywhere state NEW udp dpt:ha-cluster
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:http
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:https
REJECT all -- anywhere anywhere reject-with icmp-host-prohibited
I'd like to add a new chain for each of my virtual machines (each of them has a virtual interface called vif1.0, vif2.0, etc). Output interface (bridge) is xenbr0.
Here's what I do (for example to block ping 'in'to domU1, vif1.0) :
iptables -N domUFirewall
iptables -I FORWARD -j domUFirewall
iptables -I INPUT -j domUFirewall
iptables -A domUFirewall -i vif1.0 -p icmp -j DROP
But .. it doesn't work, i'm still able to ping in/out the domU.
Must be something really 'dumb' but I can't find out what's wrong.
Any clues ?
Thx
Since you're using XEN with bridged networking, packets are being intercepted at a level before ordinary iptables commands can influence them. Thus, you'll probably need to use the ebtables command to influence packet routing in the way that you want to.
ebtables/iptables interaction on a Linux-based bridge
ebtables(8) - Linux man page
Xen Wiki * XenNetworking
Original answer left below that will work for other configurations, but not for XEN with bridged networking.
I am going to pretend for the sake of example that the IP address of vif1.0 is 192.168.1.100.
I would redo the logic to not check the input device, but to instead check by IP Address. At the input chain, the packet is coming from (say) device eth0, not from vif1.0. Thus, this rule:
iptables -I INPUT -i vif1.0 -j domUFirewall
that I previously proposed will never match any packets. However, if you do the following, it should do what you want:
iptables -I INPUT -d 192.168.1.100 -j domUFirewall
where in this case the chain domUFirewall is set up by:
iptables -N domUFirewall
iptables -F domUFirewall
iptables -A domUFirewall -p icmp -j DROP
If a given chain is for a single device, then you want to make this check before jumping into the chain, on a rule with the "-j chainName" action. Then, in the chain itself, you never have to check for the device or IP Address.
Second, I would always flush (empty) the chain in your script, just in case you're re-running the script. Note that when you rerun the script, you may get complaints on the -N line. That's OK.
There are other ways you could do this, but to give a different example, I would need to know specifically how your VM is set up -- bridged networking? NAT? Etc. But the example I gave here should work in any of these modes.
Here are some useful links for the future:
Quick HOWTO, Ch14: Linux Firewalls Using iptables
Sandbox a VMware Virtual Machine With iptables