How do you filter external connections to a specific service, running on Docker? Specifically, how do you filter incoming requests down to a static list of whitelisted IPs?
This answer assumes that:
The container will always listen on the same host:port.
The container will always be bound on the same network card interface, if ever several are available. This is easily done by using the option -p hostIp:hostPort:containerPort within the docker run command.
Stemming from these two assumptions, it can then be assumed that the service running in the container will always listen on the same host socket defined as hostIp:hostPort.
Now, all you have to do is firewalling which is independent from docker.
I am not an expert and did not test theses lines! Be warned before executing them.
# DROP every packets coming from every sources sent to the port $PORT
iptables -A INPUT -p tcp --dport $PORT -j DROP
# ACCEPT every packets coming from source xx.xx.xx.xx sent to port $PORT
iptables -A INPUT -p tcp -s xx.xx.xx.xx --dport $PORT -j ACCEPT
# Repeat the last command if needed, you can also specify a network, such as 192.30.252.0/22 instead of xx.xx.xx.xx
These rules are to be set in this precise order. A whitelist can be likened to a blacklist with expection.
Related
We would like to give access to a specific mailadress on our server (postfix and dovecot) only from a specific ip address. My idea was to use fail2ban for that.
How could a filter look like for that?
give access to a specific mailadress on our server (postfix and dovecot)
Why you need fail2ban for that?
Write simple script (systemd-unit) creating a rules or new chain which would allow expected IPs and add reject/drop default policy for this mail ports,
and start it at boot time, for example:
chain=INPUT
for p in smtp smtps pop3 pop3s imap imaps; do
for ip in 192.0.2.1 192.0.2.2 192.0.2.3; do
iptables -A $chain -i $device -m state --state NEW -p tcp --dport "$p" -s "$ip" -j ACCEPT
done
iptables -A $chain -i $device -m state --state NEW -p tcp --dport "$p" -j REJECT
done
If you need some dynamic allowance (e. g. by port- or http-url-knowcking etc), you can indeed do this with fail2ban.
Take a look at example jail pass2allow-ftp or at related RFE #1112.
How could a filter look like for that?
How the filter does look is depending on what exactly will be monitored (for instance by url-knocking which http-server access-log format, e. g. of nging or apache, you'd have) or on what exactly you need to react to allow the IP. An example of log in such case is necessary to answer the question properly.
Also you may read wiki :: Best practice # Reduce parasitic log traffic to provide sane implementation for such "jail".
I have a service listening to customer traffic on ports 80 and 443 of eth1. The servers hosting my service also host other admin/privileged access content on eth0 and localhost
I am trying to setup iptable rules to lock down eth1 on servers which is on same network as clients (block things like ssh through eth1/ accessing internal services running on port 9904 etc.) I also want to make sure that the rules dont forbid regular access to eth1:80 and eth1:443. I have come up with below rules but wanted to review with iptable gurus on possible issues with this rule.
-A INPUT -i eth1 -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -i eth1 -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -i eth1 -j DROP
Do the rules above suffice
How does above differ from the rules found when googling
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-A INPUT -i eth1 -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -i eth1 -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -i eth1 -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j DROP
-A INPUT -i eth1 -p tcp -j ACCEPT
-A INPUT -i eth1 -j DROP
thanks i got this answered in https://serverfault.com/questions/834534/iptable-rules-to-restrict-eth1-access-to-ports-80-and-443 , adding it here for completeness
The first set of rules first allow all incoming packets on your ports
80 and 443. Then it drops ALL other incoming packets (except those
already accepted).
The second set of rules first allow all incoming packets on ports 80
and 443. Then it drops incoming connections (excluding 80 and 443 that
are already accepted), which are packets with only the SYN flag set.
Then it allows all incoming packets.
The difference here is what happens to your OUTGOING connections. In
the first ruleset, if you attempt to connect to another server, any
packets that server sends in response will be dropped so you will
never receive any data. In the second case, those packets will be
allowed since the first packet from the remote server will have both
SYN and ACK set and therefore pass the SYN test, and any following
packets will not have SYN set at all, and therefore pass the test.
This has been traditionally done using conntrack which requires the
kernel to keep track of every connection in the firewall, with a
command like
-A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
that matches the incoming packet either to an existing connection, or
a connection related to some other existing connection (eg FTP data
connections). If you aren't using FTP or other protocols that use
multiple random ports, then the second ruleset achieves basically the
same result without the overhead of tracking and inspecting these
connections.
I have been hired to fix hacking issue for a server, I found that ip 37.187.253.240 and some other ips can connect to specific port, while they are not allowed !.
csf firewall is installed in the server, and that port is not open for all in csf.conf.
only some ips are added in list csf.allow .
current iptables status by iptables -L is :
INPUT Chain (DROP policy), with ACCEPT only for some ips. and this ip 37.187.253.240 hasn't any rule.
to make sure that the csf isn't the cause if I stop csf by csf -x and flush the iptables rules by iptables -F , then added only a DROP rule iptables -A INPUT -p tcp -s 37.187.253.240 -j DROP for that ip , I see it can connect also via netstat
tcp 0 0 server_ip:port 37.187.253.240:16132 ESTABLISHED
Ubuntu 14.04.3 LTS
, hosted in vmware.com.
what are the probabilities of this case ?
Just to make a test, with your CSF firewall disabled and with the iptables rules flushed try this:
ip route add blackhole 37.187.253.240
This will discard all packets received from 37.187.253.240 or sent from your server to 37.187.253.240.
Then check with netstat and see if you still see any connection to or from ip address.
Since the server was hacked it might be possible that there is a process running on the server that previously established a connection to that ip address somehow and that connection remained active.
You could do a lsof -i | grep 16132 and see exactly which process is using that port. If a website from that server was hacked you could restart the httpd/apache service just to kill the connection.
new to setting up a load balancer:
I am working with the google compute engine.
Set up 3 servers running on 3 different ports: 5010, 5011 and 5012.
sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8080 -j REDIRECT --to-port 5010/11/12.. on each specific server
set up a health check to port 8080 . let's call it example-health-check
set up a target pool that contains the health check and all the 3 instances. let's call it example-target-pool
Set up a forwarding rule with tcp:5010-5012 and linked it target pool to the example-target-pool
when I go to the lb ip in each one of the ports the connection is very weird. it works but very slow in most of the requests but once in a while a request is very fast to pass..
any ideas ?
I have X-Wrt based on OpenWrt 8.09 on my router
I have home LAN of few computers on which I have some network servers (SVN, web, etc). For each of service I made forwarding on my router (Linksys wrt54gl) to access it from the Internet (<my_external_ip>:<external_port> -> <some_internal_ip>:<internal_port>)
But within my local network this resources by above request is unreachable (so I need make some reconfiguration <some_internal_ip>:<internal_port> to access).
I added some line to my /etc/hosts
<my_external_ip> localhost
So now all requests from local network to <my_external_ip> forwards to my router but further redirection to appropriate port not works.
Advise proper redirection please.
You need to install an IP redirect for calls going out of the internal network and directed to the public IP. Normally these packets get discarded. You want to reroute them, DNATting to the destination server, but also masqueraded so that the server, seeing as you, its client, are in its same network, doesn't respond directly to you with its internal IP (which you, the client, not having sent the packet there, would discard).
I found this on OpenWRT groups:
iptables -t nat -A prerouting_rule -d YOURPUBLICIP -p tcp --dport PORT -j DNAT --to YOURSERVER
iptables -A forwarding_rule -p tcp --dport PORT -d YOURSERVER -j ACCEPT
iptables -t nat -A postrouting_rule -s YOURNETWORK -p tcp --dport PORT -d YOURSERVER -j MASQUERADE
https://forum.openwrt.org/viewtopic.php?id=4030
If I remember correctly OpenWrt allows you to define custom DNS entries. So maybe simply give a proper local names to your sources (ie. svnserver.local) and map them to specific local IPs. This way you do not even need to go through router to access local resources from local network.