I haven't really played around at all with iptables so I am quite clueless here. This MySQL server I'm currently working on rejects all connections except for whitelisted sources. I need to add a new IP but not sure how to duplicate the current rule
iptable -L lists this rule that i need to duplicate:
ACCEPT tcp -- 10.65.0.1 anywhere tcp dpt:mysql
How would I go about adding a new rule in for a different IP address?
edit: I guess I should add that I've been looking at different examples and instructions but before I try anything I just wanted to post the question here to see if anybody can provide the exact command to add the rule.
just for the record here's the answer:
iptables -A INPUT -p tcp -s $IP_ADDRESS -m tcp --dport 3306 -j ACCEPT
Related
I have setup OpenVPN on my R7800 router to connect to my VPN provider.
I want to bypass the tunnel for some sites.
For the sake of question let it be www.whatsmyip.com
I have two ip rules acting as kill switch for my VPN connection added to "Firewall" script:
iptables -I FORWARD -o $WAN_IF -m state --state NEW -j REJECT --reject-with icmp-host-prohibited
iptables -I FORWARD -o $WAN_IF -p tcp -m state --state NEW -j REJECT --reject-with tcp-reset
Actually a bit more complicated since I use Policy Based Routing (PBR), but it shouldn't matter. Reference
I have found that bypassing the tunnel for specific domain names is possible using the following commands:
allow-pull-fqdn
route www.whatsmyip.com 255.255.255.255 net_gateway
Reference
I have entered the above to "OpenVPN Client --> Additional Config" field.
The above seems to work, since the kill switch kicks in and forbids the connection and page is not loading.
So, I need to add a firewall rule to allow this connection.
The following rule is entered below the kill switch rules:
iptables -I OUTPUT -d whatsmyip.org -j ACCEPT
I came up to this reading this
Apparently, the rule I came up is not right.
How can I properly modify the above rule in order to bypass the kill switch successfully?
Thank you in advance.
I am posting the answer here for clarity.
iptables -I FORWARD -d whatsmyip.org -o $(get_wanface) -j ACCEPT
No need for allow-pull-fqdn, it is default in OpenVPN 2.4
My site now is under ddos-attack,
"ss -ant" shows a lot of FIN-WAIT-2 (and some FIN-WAIT-1) connections from one ip (and random ports), about 500-700 connections:
FIN-WAIT-2 0 0 ::ffff:MY_IP:443 ::ffff:ATTACKERS_IP:RANDOM_PORT
.... 500-700 times
Im trying to use
iptables -A INPUT -s ATTACKERS_IP -j DROP
and
iptables -A INPUT -p tcp -m tcp --tcp-flags FIN,RST RST -m limit --limit 1/s -j ACCEPT
and
echo "2" > /proc/sys/net/ipv4/tcp_fin_timeout
but it doesnt help - new connections are coming in with another random ports.
So, how to TOTALLY block specific IP by iptables (or maybe something else) to prevent FIN-WAIT-2 flood by ip which freezes the server?
It depends, there's a ton of ways to approach the problem. You could block the whole country if it's a foreign-language country (provided your website is not of international market or interest).
or
You could block an entire ip block
or
You could use cloudflare to pre-mitigate the problem
or
You could ....
I am currently trying to secure a little my server before its release to the world. For now, there is just a Discourse instance running, that uses Mandrill as email smtp server.
There is an nginx server in front of that Discourse.
With no iptables rules, everything works fine. When I apply my rules, it brokes. I am still able to reach the Discourse and even send posts and everything, expect sending email.
With ./launcher mailtest app, it works. The Discourse error, however, is the following : ERREUR - getaddrinfo: Name or service not known.
I really try to find out myself what I should use. But I couldn't.
First, I was thinking a simple iptables -A OUTPUT -p tcp --dport 587 -j ACCEPT was enough, but I was proved the contrary.
Some other inputs :
iptables -F
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
I set Discourse to use port 587 of Mandrill.
Okay, so I just released... This is not the right SE forum for that question. I'm sorry for that.
However, since I finally found a solution (it's always when you post your question that the question hits you in the face), let me share it.
I was missing a FORWARD rule between docker0 and eth0.
iptables -A FORWARD -i docker0 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o docker0 -j ACCEPT
Sorry for the inconvenient.
I'm receiving too many requests on my server from different ip addresses. I discovered, watching apache access.log, that all these ip addresses are requesting a specific file (teXeFe.php). I'd like to block the access to all these ip addresses. How can I do it?
How about using the iptables string match ?
Something like,
iptables -I INPUT 1 -m string --algo bm --string "teXeFe.php" -j DROP
I inserted the rule at position one just for testing since I had other rules that matched before this one if it was insterted furhter down the chain. Anyway, you get the concept. You could also be a little more specific in the rule (including the GET /full/url/path etc).
Here is page describing the string-matching filter,
- http://spamcleaner.org/en/misc/w00tw00t.html
And here's another stackoverflow-question about it,
- iptable rule to drop packet with a specific substring in payload
Hope that helps!
The provided solution did not work for me. Here is what did:
iptables -A INPUT -p tcp -m string --string "/path/to/file.php" --algo kmp -j REJECT
We have a number of iptables rules for forwarding connections, which are solid and work well.
For example, port 80 forwards to port 8080 on the same machine (the webserver). When a given webserver is restarting, we forward requests to another IP on port 8080 which displays a Maintenance Page. In most cases, this other IP is on a separate server.
This all worked perfectly until we installed bridge-utils and changed to using a bridge br0 instead of eth0 as the interface.
The reason we have converted to using a bridge interface is to gain access to the MAC SNAT/DNAT capabilities of ebtables. We have no other reason to add a bridge interface on the servers, as they don't actually bridge connections over multiple interfaces.
I know this is a strange reason to add a bridge on the servers, but we are using the MAC SNAT/DNAT capabilities in a new project and ebtables seemed to be the safest, fastest and easiest way to go since we are already so familiar with iptables.
The problem is, since converting to a br0 interface, iptables PREROUTING forwarding to external servers is no longer working.
Internal PREROUTING forwarding works fine (eg: request comes in on port 80, it forwards to port 8080).
The OUTPUT chain also works (eg: we can connect outwards from the box via a local destination IP:8080, and the OUTPUT chain maps it to the Maintenance Server IP on a different server, port 8080, and returns a webpage).
However, any traffic coming into the box seems to die after the PREROUTING rule if the destination IP is external.
Here is an example of our setup:
Old Setup:
iptables -t nat -A PREROUTING -p tcp --dport 9080 -j DNAT --to-destination $MAINTIP:8080
iptables -a FORWARD --in-interface eth0 -j ACCEPT
iptables -t nat -A POSTROUTING --out-interface eth0 -j MASQUERADE
echo 1 > /proc/sys/net/ipv4/ip_forward
New Setup: (old setup in various formats tried as well..., trying to log eth0 and br0 packets)
iptables -t nat -A PREROUTING -p tcp --dport 9080 -j DNAT --to-destination $MAINTIP:8080
iptables -a FORWARD --in-interface br0 -j ACCEPT
iptables -t nat -A POSTROUTING --out-interface br0 -j MASQUERADE
echo 1 > /proc/sys/net/ipv4/ip_forward
Before changing to br0, the client request would go to server A at port 9080, and then be MASQUERADED off to a different server $MAINTIP.
As explained above, this works fine if $MAINTIP is on the same machine, but if it's on another server, the packet is never sent to $MAINTIP under the new br0 setup.
We want the packets to go out the same interface they came in on, MASQUERADED, as they did before we switched to using a single-NIC bridge (br0/bridge-utils).
I've tried adding logging at all stages in iptables. For some reason the iptables TRACE target doesn't work on this setup, so I can't get a TRACE log, but the packet shows up in the PREROUTING table, but seem to be silently dropped after that.
I've gone through this excellent document and have a better understanding of the flow between iptables and ebtables:
http://ebtables.sourceforge.net/br_fw_ia/br_fw_ia.html
From my understanding, it seems that the bridge is not forwarding the packets out the same interface they came in, and is dropping them. If we had a second interface added, I imagine it would be forwarding them out on that interface (the other side of the bridge) - which is the way bridges are meant to work ;-)
Is it possible to make this work the way we want it to, and PREROUTE/FORWARD those packets out over the same interface they came in on like we used to?
I'm hoping there are some ebtables rules which can work in conjunction with the iptables PREROUTING/FORWARD/POSTROUTING rules to make iptables forwarding work the way it usually does, and to send the routed packets out br0 (eth0) instead of dropping them.
Comments, flames, any and all advice welcome!
Best Regards,
Neale
I guess you did, but just to be sure, did you add eth0 to the bridge?
Although, I am not sure what the problem is, I will give some debugging tips which might assist you or other when debugging bridge/ebtables/iptables issues:
Make sure that "/proc/sys/net/bridge/bridge-nf-call-iptables" is enabled (1)
This cause bridge traffic to go through netfilter iptables code.
Note that this could affect performance.
Check for packet interception by the ebtabels/iptables rules,
Use the commands:
iptables -t nat -L -n -v
ebtables -t nat -L –Lc
This might help you to understand if traffic is matched and intercepted or not.
Check that IP NAT traffic appears in the conntrack table:
conntrack –L (if installed)
Or
cat /proc/net/nf_conntrack
Check MAC learning of the bridge
brctl showmacs br0
Use tcpdump on the eth0 and on br0 to check if packets seen at both as expected
Use the –e option to see MAC address as well.
For debugging, try to put the bridge interface in promiscuous mode, maybe the bridge receives packets with different MAC address (in promiscuous mode it will accept different MAC as well)
Maybe set bridge forward delay to 0
brctl setfd br0 0
And disable stp (spanning tree protocol)
brctl stp br0 off
What is your routing table looks like?
Try adding specific or default route rule with "dev br0"
I hope it helps a bit…
Good luck
Well only 1.5 years old but could be useful for later lookups. Looking at your link just now, it says specifically there brouting will ignore the packet, if MAC is on same side of bridge (and not another port or the bridge itself (see fig 2.b in your link).
Adding to that, I simply quote from this link: http://wiki.squid-cache.org/ConfigExamples/Intercept/LinuxBridge
"... ebtables DROP vs iptables DROP
In iptables which in most cases is being used to filter network traffic the DROP target means "packet disappear".
In ebtables a "-j redirect --redirect-target DROP" means "packet be gone from the bridge into the upper layers of the kernel such as routing\forwarding" (<-- relevant bit!)
Since the ebtables works in the link layer of the connection in order to intercept the connection we must "redirect" the traffic to the level which iptables will be able to intercept\tproxy.
ANd therein is your answer (bet added for future visitors of course, unless you are still at it ,p)