[SOLVED] How is remote attacker sneaking past iptables?
Linux - NetworkingThis forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
num pkts bytes target prot opt in out source destination
8 0 0 DROP all -- * * 195.22.0.0/16 0.0.0.0/0
9 0 0 DROP all -- * * 195.140.0.0/16 0.0.0.0/0
10 0 0 DROP all -- * * 155.132.0.0/15 0.0.0.0/0
11 0 0 DROP all -- * * 155.131.0.0/16 0.0.0.0/0
12 0 0 DROP all -- * * 195.22.0.0/16 0.0.0.0/0
13 4 160 DROP all -- * * 80.82.65.0/24 0.0.0.0/0
172 0 0 tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 multiport dports 1901:1914
195.22.126.131 and 155.133.82.18 are new since my last posting and were inserted into the iptables from the script we talked about.
Are we sure the multiport line goes AFTER the DROP?
What is that multiport line supposed to be doing? Since it has no target, the only effect of a packet matching it would be to increment that rule's byte and packet counts. In this particular case, all traffic (4 packets, 160 bytes), from 80.82.65.0/24 has already been dropped regardless of protocol or port (or perhaps ACCEPTed by one of the unseen rules 1-7), so traffic from that source could never reach that multiport rule.
OK, there is definitely something wrong with my iptables script. I've removed the multiport rule for ports 1901-1914 and I'm still getting the attempted breakins. Not only that, but I can access e.g. port 1906 from the outside. Therefore, these ports must be open by default. I don't know how. Here's my iptables script. I've removed the DROPs, but they would go where it says, ">>>> DROPs go here <<<<":
What is that multiport line supposed to be doing? Since it has no target, the only effect of a packet matching it would be to increment that rule's byte and packet counts. In this particular case, all traffic (4 packets, 160 bytes), from 80.82.65.0/24 has already been dropped regardless of protocol or port (or perhaps ACCEPTed by one of the unseen rules 1-7), so traffic from that source could never reach that multiport rule.
Sorry, posted my last message before reading yours.
The intention is to open those ports for access. However, as I noted in my previous post, those ports appear to be open anyway, regardless of the multiport line.
As to the line itself, I guess I need a "-j ACCEPT" at the end. I've not noticed that before as obviously access has been a given.
My desire is to have ALL ports on eth0 closed which are not otherwise specifically open via iptables rules. Apparently, I'm failing at that.
I thought the "iptables -P INPUT DROP" rule would do that.
Quote:
or perhaps ACCEPTed by one of the unseen rules
They are getting through, so there must be some rule ACCEPTing.
I haven't examined your iptables rules as others have but I noticed your use of two Ethernet interfaces and I have some "drive by" advice regarding iptables and multiple interfaces.
I've found that often when making rules with iptables that refer to multiple interfaces (eth0, eth1) the rules don't behave as expected due to ARP flux. Interface specific rules may depend upon whether a computer ARP response is host-based or interface-based.
ARP flux issues also involve how the Ethernet cables from different interfaces are connected to common or independent routers/switches etc.
That may not be the issue here but I mention it in case you might be depending upon the limitation of a rule to a specific interface which may not be acting as expected. You may want to review the thread linked above.
Meanwhile, still under attack. I'm getting between 100 and 200 attempts every 5 minutes. They are trying some valid user IDs, but so far incorrect passwords.
I can't figure out how to shut off access to port 1906!! I've removed the corresponding multiport rule and the DROP rules for these IPs apparently have no effect.
Another interesting tidbit, I can telnet to 1906 from remote hosts, but I cannot do so from a host on the local LAN. I thought I permitted ALL ports on the local LAN (eth1).
Is 192.168.0.52 the LAN address for this same machine? If not, then that DNAT rule is going to cause those packets to go through the FORWARD chain, and they won't be seen in the INPUT chain at all. The INPUT chain is strictly for packets going to processes on the local host.
If you have firewall rules that you want applied in both the INPUT and FORWARD chains, you should create a user-defined chain (I call mine "Incoming") and jump to it from both the INPUT and FORWARD chains.
Is 192.168.0.52 the LAN address for this same machine?
No, it's not.
Quote:
If not, then that DNAT rule is going to cause those packets to go through the FORWARD chain, and they won't be seen in the INPUT chain at all. The INPUT chain is strictly for packets going to processes on the local host.
I was suspecting something like that.
Quote:
If you have firewall rules that you want applied in both the INPUT and FORWARD chains, you should create a user-defined chain (I call mine "Incoming") and jump to it from both the INPUT and FORWARD chains.
Despite my possibly elaborate rules, for which I've mostly depended on the kindness of strangers, I'm no expert on iptables. Could you give me an example of how to "create a user-defined chain ... and jump to it from both the INPUT and FORWARD chains"?
iptables -N rdc_forward
iptables -A rdc_forward -s 195.22.126.0/16 -j DROP
iptables -A INPUT -i eth0 -j rdc_forward
and remove my "iptables -t filter -I INPUT 8 -s 195.22.126.0/16 -j DROP" rule from the INPUT chain, that should work?
What about also "jumping" to the new chain from the FORWARD chain, as rknichols mentioned? Do I also need:
Code:
iptables -A FORWARD -i eth0 -j rdc_forward
In fact, why do I need to "jump to" the INPUT chain at all if the IPs I want to block are FORWARDs? As rknichols wrote, "they won't be seen in the INPUT chain at all. The INPUT chain is strictly for packets going to processes on the local host."
iptables -N rdc_forward
iptables -A rdc_forward -s 195.22.126.0/16 -j DROP
iptables -A INPUT -i eth0 -j rdc_forward
and remove my "iptables -t filter -I INPUT 8 -s 195.22.126.0/16 -j DROP" rule from the INPUT chain, that should work?
What about also "jumping" to the new chain from the FORWARD chain, as rknichols mentioned? Do I also need:
Code:
iptables -A FORWARD -i eth0 -j rdc_forward
In fact, why do I need to "jump to" the INPUT chain at all if the IPs I want to block are FORWARDs? As rknichols wrote, "they won't be seen in the INPUT chain at all. The INPUT chain is strictly for packets going to processes on the local host."
You should move all of your "DROPs go here" rules to the rdc_forward chain and jump to that chain from the FORWARD chain. If you don't need that filtering for packets destined for the local machine, then you don't need to jump to rdc_forward from the INPUT chain, but I would. Since those DROPs are for known bad actors, why let them probe for other ports on the local machine?
Another advantage of putting those DROPs in a separate chain is that it's a heck of a lot easier to dynamically add new DROPs to rdc_forward than it is to figure out where they need to be inserted in the INPUT or FORWARD chains.
You should really have Oskar Andreasson's Iptables Tutorial. It's getting a bit dated, but it's still a good tutorial on iptables as well as packet handling in general. I keep a PDF version stored locally, and refer to it frequently.
Location: Geneva - Switzerland ( Bordeaux - France / Montreal - QC - Canada)
Distribution: Slackware 14.2 - 32/64bit
Posts: 609
Rep:
Sorry to insist but you really should try to understand the /XX notation... 195.22.126.0/16 is equivalent to 195.22.0.0/16 ...
/XX is the size of the bitmask TO THE LEFT. 16 bits = 2 bytes = 2 numbers of the IP address.
Sorry to insist but you really should try to understand the /XX notation... 195.22.126.0/16 is equivalent to 195.22.0.0/16 ...
/XX is the size of the bitmask TO THE LEFT. 16 bits = 2 bytes = 2 numbers of the IP address.
Yes, I know this. The automatic script searches for the CIDR, country, etc. based on xx.yy.zz.0/24 and uses that, together with the found CIDR to create the DROP. If there is no CIDR found it defaults to /16. That's as smart as the script gets.
Quote:
Originally Posted by rknichols
You should move all of your "DROPs go here" rules to the rdc_forward chain and jump to that chain from the FORWARD chain. If you don't need that filtering for packets destined for the local machine, then you don't need to jump to rdc_forward from the INPUT chain, but I would. Since those DROPs are for known bad actors, why let them probe for other ports on the local machine?
Another advantage of putting those DROPs in a separate chain is that it's a heck of a lot easier to dynamically add new DROPs to rdc_forward than it is to figure out where they need to be inserted in the INPUT or FORWARD chains.
You are definitely right about the pain figuring out where DROP rules need to be inserted. Every time I have to add a "boiler-plate" rule I have to adjust my script accordingly. I've never really dealt much with user defined chains before this thread; except for the logdrop chain, which I understand, but didn't set up on my own. I guess now's as good a time as any. So -- changing the chain name to bad_people, would the following be correct:
Code:
iptables -P INPUT DROP
iptables -N bad_people
iptables -A bad_people -s 195.22.0.0/16 -j DROP
# >> DROPs go here <<
iptables --table nat --append POSTROUTING --out-interface eth0 -j MASQUERADE
iptables --append FORWARD --in-interface eth1 -j ACCEPT
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 587 -j REDIRECT --to-port 25
# FORWARDS TO OTHER HOSTS
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 1906 -j DNAT --to-destination 192.168.0.52:xxxx
# more like above
iptables -A INPUT -i eth0 -j bad_people
iptables -A FORWARD -i eth0 -j bad_people
# THEN THE REST OF MY RULES
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -i eth1 -p tcp --syn -j ACCEPT
iptables -A INPUT -i eth1 -p udp -j ACCEPT
iptables -N logdrop
iptables -A logdrop -j LOG --log-level 6 --log-prefix "SSH Break-in attempt "
iptables -A logdrop -j DROP
iptables -N checkcount
iptables -A checkcount -m recent --set
iptables -A checkcount -m recent --rcheck --hitcount 12 -j logdrop
iptables -A checkcount -j RETURN
iptables -A INPUT -p icmp --icmp-type 8 -s 192.168.0.0/24 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -I INPUT -i eth0 -p tcp -m tcp -s $bu6500 --dport 22 -j ACCEPT
iptables -I INPUT -i eth0 -p tcp -m tcp -s $hostmon --dport 22 -j ACCEPT
iptables -A INPUT -p tcp --syn --dport 22 -i eth0 -j checkcount
iptables -A INPUT -p tcp --syn -m limit --limit 1/s --limit-burst 3 -i eth0 --dport 22 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --syn -m multiport --dports 25,80,143,443,587,993 -j ACCEPT
Then, my DROP script should add rules as follows:
Code:
iptables -t filter -I bad_people 8 -s 193.253.0.0/16 -j DROP
Right? Do I even need the "-t filter" bit any more?
Please give me some feedback critique on these rules and their order as I hesitate implement this without a thumbs up from someone more expert.
Quote:
You should really have Oskar Andreasson's Iptables Tutorial. It's getting a bit dated, but it's still a good tutorial on iptables as well as packet handling in general. I keep a PDF version stored locally, and refer to it frequently.
Yes, I will definitely read that and check out NoStressHQ's link as well as I've never really stumbled across a good reference yet that didn't require me to already have a significant level of expertise.
iptables -t filter -I bad_people 8 -s 193.253.0.0/16 -j DROP
Right? Do I even need the "-t filter" bit any more?
I typically just append new rules to the bottom. That's even easier. There's a small performance advantage to adding someone who is pounding on you right now at the top of the list, but any connection that does not get filtered is going to be tested by all the rules anyway,
You never did need "-t filter" since that's the default.
Quote:
Please give me some feedback critique on these rules and their order as I hesitate implement this without a thumbs up from someone more expert.
Nothing bad jumps out at me on a cursory examination.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
