Wednesday, April 28, 2010

Iptables: Unblock / Delete an IP Address Listed in IPtables Tables

Iptables is used to set up, maintain, and inspect the tables of IP packet filter rules in the Linux kernel. You can delete one or more rules from the selected chain. There are two versions of this command: the rule can be specified as a number in the chain (starting at 1 for the first rule) or a rule to match.


List existing chains

Type the following command to list current IPs in tables:

iptables -L -n
iptables -L -n -v
iptables -L chain-name -n -v
iptables -L spamips -n -v


List existing chains with line number

To display line number along with other information, enter:

iptables -L INPUT -n --line-numbers
iptables -L OUTPUT -n --line-numbers
iptables -L OUTPUT -n --line-numbers | less
iptables -L spamips -n -v --line-numbers
iptables -L spamips -n -v --line-numbers | grep 202.54.1.2


Chain droplist (3 references)
num   pkts bytes target     prot opt in     out     source               destination
1 0 0 LOG 0 -- * * 116.199.128.0/19 0.0.0.0/0 LOG flags 0 level 4 prefix `LASSO DROP Block'
2 0 0 DROP 0 -- * * 116.199.128.0/19 0.0.0.0/0
3 0 0 LOG 0 -- * * 116.50.8.0/21 0.0.0.0/0 LOG flags 0 level 4 prefix `LASSO DROP Block'
4 0 0 DROP 0 -- * * 116.50.8.0/21 0.0.0.0/0
5 0 0 LOG 0 -- * * 128.199.0.0/16 0.0.0.0/0 LOG flags 0 level 4 prefix `LASSO DROP Block'
6 0 0 DROP 0 -- * * 128.199.0.0/16 0.0.0.0/0
7 0 0 LOG 0 -- * * 132.232.0.0/16 0.0.0.0/0 LOG flags 0 level 4 prefix `LASSO DROP Block'
8 0 0 DROP 0 -- * * 132.232.0.0/16 0.0.0.0/0
9 342 23317 LOG 0 -- * * 134.175.0.0/16 0.0.0.0/0 LOG flags 0 level 4 prefix `LASSO DROP Block'
10 342 23317 DROP 0 -- * * 134.175.0.0/16 0.0.0.0/0
11 0 0 LOG 0 -- * * 134.33.0.0/16 0.0.0.0/0 LOG flags 0 level 4 prefix `LASSO DR
You will get the list of all blocked IP. Look at the number on the left, then use number to delete it. For example delete line number 10 (subner 134.175.0.0/16), enter:

iptables -D INPUT 10

You can also use the following syntax to delete / unblock an IP use the following syntax:

iptables -D INPUT -s xx.xxx.xx.xx -j DROP
iptables -D INPUT -s xx.xxx.xx.xx/yy -j DROP
iptables -D spamlist -s 202.54.1.2 -d 0/0 -j DROP
iptables -D spamlist -s 202.54.1.2/29 -d 0/0 -j DROP


On a related note I recommend getting a good Linux command line and netfilter Firewall (iptables) book to understand all technical mumbo jumbo.

How to avoid dictionary attack on SSH? Secure your server now!

For this past few weeks, I've encountered a lot of attacks on my server coming from different IP's using automated scripts. They use brute force using dictionary attack to guess my root and other account password. Well, honestly I'm not really bothered by this attacks before because i do have my firewall up and enabled and I am confident enough that they wont guess my very super secured password :)

However, what annoyed me and makes me create this article is the email that I received from my cpanel account 3 times per day and spamming my personal inbox. The email says, 'Drive Warning: /dev/sda2 (/var) is 72% full' (dev/sda2 is my secondary disk where logs are located)

From 72% to 89% percent for just a couple of days.. it started to get my furious attention. WTH?! then i started the investigation and found out my btmp file (File btmp contains bad login entries for each invalid logon attempt) has reached a very huge 8Gb in file size. Whoa! its even larger than my GTA IV installer and to think that its only a txt file. Grrrrr.

And now to limit or end this script kiddie playtime,

1) Make passwords long & strong, stuff like: &^bV{-)wQ17HG*dzQK?X

2) Limit sshd's accessing domains you know you don't need in hosts.deny (sshd can be compiled w/hosts_access support or put in under xinetd/inet with -i option). For example, I know that no one from China should be logging into my sshd, so:

hosts.deny:

Code:
sshd: .cn, .cn.net, .cn.com, .jp, .jp.com

3) Add line

Code:
sshd: UNKNOWN

to hosts.deny. Surprisingly, this stops alot of them but hasn't stopped any of my legit users. You can combine this rule with #2 above.
4) Make use of the AllowUser, DenyUser tags in sshd_config. Make sure you list exactly who should and who should not login. IMO, never, ever allow root.

sshd_config:

Code:
# Explicitly set who can and who can not login by way of ssh
AllowGroups users
AllowUsers tom joe harry

# Everything that isn't above
DenyGroups root bin daemon sys adm tty disk lp mem kmem wheel floppy mail news uucp man games slocate utmp smmsp mysql rpc sshd shadow ftp nogroup console xcdwrite

DenyUsers root bin daemon adm lp sync shutdown halt mail news uucp operator games ftp smmsp mysql rpc sshd nobody test guest user admin apache www wwwrun httpd irc

5) Check into key-only ssh login. If someone doesn't have a valid key, it will be very hard to login with any password!

6) Turn up logging and watch logs carefully. Maybe limit access times too (with xinetd's port times). I completely drop traffic from known trouble networks/domains/netblocks, but this may be too extreme for some people. xinetd can do rate limit as well.

7) You can put sshd on another port, but this shouldn't be needed if all your other defense is in place. Stay up on patches and current security. Most intruders I've seen get local, then use kernel exploits like km3.c (ptrace) or do_brk(), mremap to gain root. Of those that did get root, they usually downloaded IRC stuff (bouncers, bots) and linux viruses OSF, and RST varient #2. The attackers were quite amatureuish, and left behind plenty of evidence, including bash history files, logs, and other records. Once a machine is compromised, they use it to do more. The most advanced tool that I've seen

came as a C source file, so the port could be changed. It had an extensive password list with dictionary type words. More words could be added. RST #2 contains its own backdoor. Rootkits T0rn, and SucKit were popular as well. Many of the tools came from the go.ro domain. In many cases, the admins of the attacking machines didn't know they were compromised. Several expressed gratitude when notified of the attempts, but unfortunately the norm seems to be no response (at least in the cases I've reported myself).

As far as using hosts based access for iptables, I'd say go for both: knock out as much trouble spots as you can with each tool, because they work slightly different. For example, I may not need to allow sshd login from a certain domain, but I do want to be able to send and receive mail with it; so I can't drop it completely. With hosts based access you can give rules to just one daemon, or all.

Most Viewed