New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
BitAccel IPTables ruleset works on another VPS (diff provider), but not on BitAccel (same setup).
Plus the exact same ruleset used to work on BitAccel, before they switched from VirtPanel to SolusVM, but now it blocks all access, except from MY_LOCAL_IP due the rules on lines 13/14
What would cause this? Would the main, non-virtual, server's nix build be the culprit?
For those thinking it is MY configuration or nix flavour difference, both setups use the same version (Ubuntu 13.10), same installed utilities and base apps (same apt repos in sources.list), and where installed (and re-installed) within hours of each other.
The exact same ruleset is used on a few other VPSes (Ubuntu 13.10 and 13.04), different providers, without any problems.
Here is a copy of the ruleset for reference:
*filter
-P INPUT DROP
-P FORWARD DROP
-P OUTPUT DROP
# Allows all loopback (lo0) traffic and drop all traffic to 127/8 that doesn't use lo0
-A INPUT -i lo -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
-A INPUT ! -i lo -d 127.0.0.0/8 -j REJECT
-A INPUT -s MY_LOCAL_IP -j ACCEPT
-A OUTPUT -d MY_LOCAL_IP -j ACCEPT
# Accepts all established connections
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
# Allows HTTP and HTTPS connections from anywhere (the normal ports for websites)
-A INPUT -p tcp -m multiport --dports 80,443 -m state --state NEW,ESTABLISHED -j ACCEPT
-A OUTPUT -p tcp -m multiport --sports 80,443 -m state --state ESTABLISHED -j ACCEPT
-A OUTPUT -p tcp -s VPS_IP -m multiport --dports 80,443 -j ACCEPT
# Harden SSH access
-A INPUT -p tcp --dport 999 -m state --state NEW,ESTABLISHED -j ACCEPT
-A OUTPUT -p tcp --sport 999 -m state --state ESTABLISHED -j ACCEPT
# Allow MYSQL access
-A OUTPUT -s VPS_IP -d SQL_IP -p tcp --dport 3306 -m state --state NEW,ESTABLISHED -j ACCEPT
-A INPUT -s VPS_IP -d SQL_IP -m state --state ESTABLISHED -j ACCEPT
# Allow SMTP from server ip to port 25 (sendmail/swiftmailer)
-A OUTPUT -s VPS_IP -p tcp --dport 25 -j ACCEPT
# Allow outbound DNS
-A OUTPUT -p udp --sport 1024:65535 --dport 53 -m state --state NEW,ESTABLISHED -j ACCEPT
-A INPUT -p udp --dport 53 -m state --state ESTABLISHED -j ACCEPT
-A OUTPUT -p tcp --sport 1024:65535 --dport 53 -m state --state NEW,ESTABLISHED -j ACCEPT
-A INPUT -p tcp --dport 53 -m state --state ESTABLISHED -j ACCEPT
-A INPUT -p udp -s 8.8.8.8 --sport 53 -d VPS_IP --dport 1024:65535 -j ACCEPT
-A INPUT -p tcp -s 8.8.8.8 --sport 53 -d VPS_IP --dport 1024:65535 -j ACCEPT
-A INPUT -p udp -s 8.8.4.4 --sport 53 -d VPS_IP --dport 1024:65535 -j ACCEPT
-A INPUT -p tcp -s 8.8.4.4 --sport 53 -d VPS_IP --dport 1024:65535 -j ACCEPT
# Allow git
-A OUTPUT -o venet0 -s VPS_IP -p tcp --dport 9418 -m state --state NEW,ESTABLISHED -j ACCEPT
-A INPUT -i venet0 -p tcp --sport 9418 -m state --state ESTABLISHED -j ACCEPT
# Help prevent DoS Attacks
-A INPUT -p tcp --dport 80 -m limit --limit 25/minute --limit-burst 100 -j ACCEPT
# Kill SYN attacks
-A INPUT -p tcp ! --syn -m state --state NEW -j DROP
# Drop fragments
-A INPUT -f -j DROP
# Drop XMAS packets
-A INPUT -p tcp --tcp-flags ALL ALL -j DROP
# Drop NULL packets
-A INPUT -p tcp --tcp-flags ALL NONE -j DROP
# Allow ping
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
# Logging CHAIN
-N LOGGING
-A INPUT -j LOGGING
-A OUTPUT -j LOGGING
-A LOGGING -m limit --limit 5/min -j LOG --log-prefix "IPT: " --log-level info
-A LOGGING -j DROP
COMMIT
Comments
Maybe some modules need to be activated and added to the container, but define not working. Error? No message? Firewall rule added but traffic not filtered?
Most likely missing iptables modules, e.g., multiport, causing ACCEPT rules to fail. Open a ticket, the provider has to fix this for OpenVZ.
To find where the problem is, change the first three rules to:
-P INPUT ACCEPT-P FORWARD DROP
-P OUTPUT ACCEPT
And remove this rule:
-A LOGGING -j DROPThen run the rules one by one in bash command line, with iptables in front of each one. Until you find a rule that gives you an error, that is the one not working.
this is common with ovz. can't do anything about it if host don't want to change anything.
I'll give this a try, thanks.
Hopefully, if it is on their side, they will be willing... if not, I definitely won't be renewing.
very rare host will change, because it may affect other clients. if iptables rules are very important, this is where kvm will excel. because you can control it
The thing is it worked on their previous system (VirtPanel), so other clients should also be experiencing this problem.
That aside, following hwdsl2's suggestion, I changed the -P INPUT/OUTPUT rules to ACCEPT, removed the LOGGING DROP rule, and added the remaining rules one by one.
All went well until I added the LOGGING DROP rule at the end, at which point system would freeze out all access. Not sure why.
let's hope
For some reason some of my SSH traffic is being dropped, according to this entry in my logs:
But it should have been accepted by this existing rule:
Any idea why this is happening?
iptables -L -n -v -x
You can see how many times each rule has matched.
@gutshotz You forgot the "RELATED".
-A INPUT -p tcp --dport 999 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPTBy the way, I have seen some weird things with IPTables on OpenVZ on a former (free) VPS provider. What happened is that this rule
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPTwill not match any packet, however, changing the state above to INVALID would match all traffic. Not sure what's going on there.
Here is the matched rules listing:
It appears everything is passing through and nothing is being DROPPED or REJECTED, probably due to my changing the -P INPUT/OUPTUT rules. I see that I forgot that fail2ban also created a chain, but it simply RETURNS all traffic that it hasn't temporarily banned.
I don't see this rule in your listing:
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPTBut anyway, judging from your OUTPUT rules, I see that your iptables does not recognize ESTABLISHED or RELATED traffic at all. Probably the same symptom as my previous post.
Perhaps an experienced OpenVZ hosting provider could enlighten on why this happens.
@gutshotz - Try this from command line
"iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT"
and
"iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT"
if you get
"iptables: No chain/target/match by that name"
Then kernel mods need to be added in your container's config. This will need to be added by provider
Edit:terrible grammar day