Linux - SoftwareThis forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.
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.
I have one server that has Asterisk running. On front of that, I use DD-WRT router as gateway. As I have checked the log files, I saw that there is a specific IP Address that is continuously accessing the application and trying to authenticate to SIP with a series of extensions. This is like DoS attack for SIP. What I did was to block/drop the IP in DD-WRT using the iptables. I can see from the /proc/net/ip_conntrack that it is being "UNREPLIED". But my concern is that does it still uses a lot of bandwidth even though it is already being blocked? Thanks.
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
Posts: 3,541
Rep:
Save bandwidth, probably not (they're gonna whack at you no matter what). But you can cut 'em off at the knees... thus saving some bandwidth.
Two things you can do that make life better: stick the IP address of the offending site(s) in /etc/hosts.deny and they won't be able to connect. You can automate that if you install DenyHosts, http://denyhosts.sourceforge.net, which examines your log and automagically makes entries in /etc/hosts.deny for you. The entries look like this
Code:
# DenyHosts: Fri May 21 06:57:09 2010 | sshd: 66.154.118.135
sshd: 66.154.118.135
# DenyHosts: Fri May 21 06:57:09 2010 | sshd: 123.15.41.98
sshd: 123.15.41.98
# DenyHosts: Fri May 21 06:57:09 2010 | sshd: 200.87.126.117
sshd: 200.87.126.117
# DenyHosts: Fri May 21 06:57:09 2010 | sshd: 195.168.11.78
sshd: 195.168.11.78
and so on
There are other utilities that accomplish the same sort of thing; e.g., Fail2Ban, http://www.fail2ban.org, which is a little more sophisticated than DenyHosts (and a little more difficult to configure). Fail2Ban likes to use IPTABLES to block offenders although it will also use /etc/hosts.deny.
You can accomplish pretty much the same thing in IPTABLES as with /etc/hosts.deny, simply blocking the offender with entries of this form
Code:
# Country: CHINA
# ISO Code: CN
# Total Networks: 1,753
# Total Subnets: 248,528,384
iptables -A INPUT -s 1.24.0.0/13 -j DROP
iptables -A INPUT -s 27.8.0.0/13 -j DROP
iptables -A INPUT -s 27.16.0.0/12 -j DROP
iptables -A INPUT -s 27.36.0.0/14 -j DROP
iptables -A INPUT -s 27.40.0.0/13 -j DROP
iptables -A INPUT -s 27.50.128.0/17 -j DROP
and so on
You can get the IP values you need from whois.
I block at least China and Korea (where too much of this stuff originates) up to you what you block. I add additional country blocks to IPTABLES as I notice a pick-up of break-in attempts originating from them (Brazil is also a good candidate).
Thanks a lot for the useful information. I have just blocked the IP Addresses that have tried to penetrate my network. Now, it's worst because IP Addresses changes every now and then and I need to check the log files and drop it on the iptables. I cannot close the ports though because it is being used by my application. I guess I would need a IPCop with snort-inline to really resolve this problem. But for now, i think the iptables is still reliable.
I just cannot understand why they needed to do this and it is causing too much problem on my network. Anyway, your help was really appreciated..
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
Posts: 3,541
Rep:
You may really want to have a look at DenyHosts -- it automatically does the log looking and entry making for you (not IPTABLES but /etc/hosts.deny is fast and effective). It also maintains a world-wide data base of other DenyHosts' user experience and periodically downloads that data to your server for inclusion in your /etc/hosts.deny. I've been running it for years and there are just under 4,000 blocked addresses on my system (that I never had to do anything manually to enter).
You probably are aware that IPTABLES goes away when the power goes away (so you have to maintain a loadable file of addresses for each boot); /etc/hosts.deny does not go away and requires zero fiddling around. I kinda like that.
Bad actors have been around since we were still walking on our knuckles (the great apes? yeah, they steal from each other). That's why we have locks on the doors and, dammit, insurance policies, I suppose. They are not going to go away, governments, particularly China, sponsor this stuff trying to get technology for free and you do what you can to keep the bastards out of your pants. I like the automagic way...
Thanks again for some inputs. I would need to get a full blown PC with minimum power consumption to do this. Currently, I am using the DD-WRT as my front firewall/router and just do IPTables. I do maintain a file so that IPTables will be reinstated after reboot. I will try to work out a server that will be more reliable to do this. It's good to know that there is someone like you who really suggests on new things.
I have tried to block one IP address using the below command in iptables:
iptables -A INPUT -s x.x.x.x -j DROP
But when i try to check /proc/net/ip_conntrack, i can still see that the status is ASSURED. I can also check it is trying to login to my NATed machine from the /var/log/messages.
I have checked in iptables --list and found out that it is listed in the DROP state.
Two things you can do that make life better: stick the IP address of the offending site(s) in /etc/hosts.deny and they won't be able to connect.
That's a common misconception: a packet is delivered to the service. The application in turn needs to read /etc/hosts.{deny,allow} to determine if a connection is allowed or not. Netfilter resides in memory completely and blocking an IP address will not deliver the packet to the service.
* Also using /etc/hosts.{deny,allow} does not work for services whose applications have not been compiled with libwrap.
Quote:
Originally Posted by tronayne
You can accomplish pretty much the same thing in IPTABLES as with /etc/hosts.deny, simply blocking the offender with entries of this form (..)
# Country: CHINA
# ISO Code: CN
# Total Networks: 1,753
# Total Subnets: 248,528,384
(..)
and so on
The problem with this method is that networks are dynamic and discontinuous, meaning netblock assignments and re-assignments may be advertised at any time and any ranges may show gaps. So you need to find a trustworthy and current source to use information from.
Last edited by unSpawn; 07-18-2010 at 05:37 AM.
Reason: //more *is* more
when i try to check /proc/net/ip_conntrack, i can still see that the status is ASSURED. (..) I have checked in iptables --list and found out that it is listed in the DROP state. (..) Is this a bug in iptables?
No. When a connection is established (packet returned) and subject to connection tracking its state moves from [UNREPLIED] to [ASSURED]. Blocking (using fail2ban?) IP addresses or ranges using the iptables "PREROUTING" chain of the "raw" table prevents connection tracking and keeps your "filter" table clean for more important stuff.
Am I doing the correct command? I just want to drop the packet after recognizing its IP and should not be forwarded to the server behind the router. But right now, I am just surprised that it bypasses my iptables rules and still go on to the server even if its listed in the DROP policy.
If the iptables rule you listed in #6 is from your DD-WRT, then shouldn't you be using the FORWARD chain? Also take care to check rule order inside chains because if you first use a forwarding allow rule for say SIP ports to the server and you don't use an address mask then a drop rule added at the end of the chain probably won't do a thing.
~ # iptables --list
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT tcp -- anywhere anywhere tcp dpt:https
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
DROP udp -- anywhere anywhere udp dpt:route
DROP udp -- anywhere anywhere udp dpt:route
ACCEPT udp -- anywhere anywhere udp dpt:route
logaccept tcp -- anywhere DD-WRT tcp dpt:ssh
DROP icmp -- anywhere anywhere
DROP igmp -- anywhere anywhere
ACCEPT all -- anywhere anywhere state NEW
logaccept all -- anywhere anywhere state NEW
DROP all -- anywhere anywhere
DROP all -- mintaka.kitusa.net anywhere
DROP all -- 209.208.72.217 anywhere
DROP all -- 89-115-181-7.ct.ipv4ilink.net anywhere
DROP all -- erpbrain.com anywhere
Chain FORWARD (policy ACCEPT)
target prot opt source destination
ACCEPT gre -- 10.2.9.0/24 anywhere
ACCEPT tcp -- 10.2.9.0/24 anywhere tcp dpt:1723
ACCEPT all -- anywhere anywhere
logdrop all -- anywhere anywhere state INVALID
TCPMSS tcp -- anywhere anywhere tcp flags:SYN,RST/SYN tcpmss match 1461:65535 TCPMSS set 1460
lan2wan all -- anywhere anywhere
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT tcp -- anywhere 10.2.9.2 tcp dpt:14161
ACCEPT udp -- anywhere 10.2.9.2 udp dpt:14161
ACCEPT udp -- anywhere 10.2.9.5 udp dpt:4569
ACCEPT tcp -- anywhere 10.2.9.3 tcp dpt:www
ACCEPT udp -- anywhere 10.2.9.5 udp dpts:10000:20000
DROP udp -- anywhere 10.2.9.5 udp dpts:5060:5070
TRIGGER all -- anywhere anywhere TRIGGER type:in match:0 relate:0
trigger_out all -- anywhere anywhere
ACCEPT all -- anywhere anywhere state NEW
DROP all -- anywhere anywhere
I am not an iptables guru but from what I understand, right from the INPUT rule, those IPs or hostnames (i don't know why it was converted to NS) were already there and were instructed to be dropped. By that time, it should reach the FORWARD stage. But it seems to me that it is still being passed into FORWARD stage and is still reaching my server. Or do you think I should put another entry in FORWARD stage and drop it there? Another thing is that in DD-WRT, it will only allow you to put certain commands in GUI firewall and won't show you on its sequence and hierarchy thus I am unable to construct it. I just don't want this IPs to come into the server when I have allowed it to be dropped before being forwarded.
Another work around I wanted to know is whether there is a way I can secure my VOIP gateway to drop all packets when wrong authentication was done for 5 consecutive times? I have this VOIP appliance which doesn't even have iptables on it. That is why it makes me sick checking every now and then whether intruder doing a DoS attack and the IPs are changing every now and then. This causes my server to exhaust memory and hang.
Any help will be very much appreciated. Thanks a lot.
Note that 'iptables --list' behaves like 'iptables -t filter --list' so if you use other tables you have to set "-t".
Quote:
Originally Posted by depam
Anything missing perhaps?
I don't know but the FORWARD chain looks severely fscked up with "ACCEPT all anywhere anywhere" near the top. Do you use fwbuilder to configure your ruleset or you build it manually?
Quote:
Originally Posted by depam
I have put the drop rule at the end of the INPUT chains.
No. I did not use fwbuilder for this. This is predefined with DD-WRT and you can just add some firewall commands in the gui and it will save it there so that it will be present during startup. So basically, the rest of the entries are from the gui (port forwarding, port triggering, icmp blocking, etc.) and the DD WRT was the one constructed it. I don't know how "ACCEPT ALL anywhere anywhere" came from but I definitely did not do that.
If I am to mess around and use iptables, I should have used a full blown PC and not DD-WRT that has the mind of its own and restore configurations after reboot. But this leaves me no choice since I am using it as the primary router/firewall. It is good to know iptables and all of this stuff but I am hoping I will be able to manipulate DD-WRT to do what I want and how I want it to. Thanks.
I was able to drop the connection of the intruder by doing the following:
#iptables -I INPUT -s x.x.x.x -j DROP
#iptables -I FORWARD -s x.x.x.x -j DROP
#iptables -I OUTPUT -s x.x.x.x -J DROP
In this manner, all entries are listed on top of INPUT,FORWARD and OUTPUT policy. But I was thinking if this is the most effective way to do this. I would like to secure my SIP 5060 protocol as much as possible and it seems that all hackers are using different IPs from day to day. I mean, what will they gain on doing it even if they manage to brute force one of my extensions and gain access to it? Any other suggestion you can provide to stop this thing from happening again?
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.