Blocking incoming IP address immediately

I have a gaming server and am trying to create an IPTABLES firewall that
will allow me to "ban" an IP. I have been able to do this, but the ban only
takes place if I reboot the firewall pc. I need this to be something that
can take effect immediately. If I have a cheater/abuser in the game, I need
to be able to script something so that I can block all traffic from that
person's IP or IP Range. From what I've dug up, this should be doable with
a simple :

iptables -A INPUT -s 123.45.67.89 -j DROP

I've also seen where the -SYN option should be used and I've played with the
ESTABLISHED and RELATED options. ANY ideas on this will be greatly
appreciated. BTW, the game works fine, all the port forwarding and NAT
works great. I just need the ability to block IP's on the fly. If I can't
get this to work, I'd just as soon go back to the LinkSys I had in place
before :-/

Thanks

jf

Here is my current IPTABLES script. I know its simple, but while trying to
determine how to do this, I've stripped all the fluff out. I'll put it back
once I figure out my problem.

-------------------------------------------------------------
# Purging all existing tables

/sbin/iptables -F
/sbin/iptables -F -t nat
/sbin/iptables -X

# Enable IP Forwarding
echo "1" > /proc/sys/net/ipv4/ip_forward

# Enable NAT
/sbin/iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE

# Reject all ping packets
# /sbin/iptables -A INPUT -p icmp -j DROP -i eth1

# *********** Port Forwarding from this point *************

# Port Forwarding For Game
/sbin/iptables -t nat -A PREROUTING -i eth1 -p udp --dport 1234 -j
DNAT --to-des
tination 192.168.1.111
/sbin/iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 1234 -j
DNAT --to-des
tination 192.168.1.111

/sbin/iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 2345:2349 -j
DNAT --t
o-destination 192.168.1.111

/sbin/iptables -t nat -A PREROUTING -i eth1 -p udp --dport 2345:2349 -j
DNAT --t
o-destination 192.168.1.111


# Forward traffic to Roger Wilco
/sbin/iptables -t nat -A PREROUTING -p udp --dport 3783 -j
DNAT --to-destination
192.168.0.201

/sbin/iptables -t nat -A PREROUTING -p tcp --dport 3783 -j
DNAT --to-destination
192.168.0.201

"Jeff Franks" <jfranks1970@charter.net> writes:

> I have a gaming server and am trying to create an IPTABLES firewall that
> will allow me to "ban" an IP. I have been able to do this, but the ban only
> takes place if I reboot the firewall pc.

Yuck? WTF?

> I need this to be something that can take effect immediately. If I have a
> cheater/abuser in the game, I need to be able to script something so that
> I can block all traffic from that person's IP or IP Range. From what I've
> dug up, this should be doable with a simple :
>
> iptables -A INPUT -s 123.45.67.89 -j DROP

Well yeah, that should work. Does what it says on the tin - appends a rule
taking packets from that ip and drops them, to the end of the INPUT chain.

Now.

You might've wanted to REJECT them instead, for speed - up to you in this
case.

Depending on how many concurrent packets hitting your server are destined
for the game rather than other services, it might make sense to peel off a
chain and call it `abusers', so you check incoming packets first whether
they're for the game service (by port#), then you push them through the
game-specific abusers chain where naughty people are REJECTed/DROPped, or
otherwise if it's not for the game, it bypasses all that processing and
gets handled normally.

Second thought: depending on what else happens in your iptables `INPUT'
chain, you might find that appending or prepending the rule after
everything else is daft. This is where having a separate chain for abusers
makes sense because you can firmly stick the rule on either end of that
chain in the knowledge that it's not messing-up your firewall order any
further (e.g. the abuser should be able to send you a mail (25/tcp) saying
sorry).

I'm thinking in terms of my firewall script at
<http://spodzone.org.uk/packages/secure/iptables.sh> here, but with a few
extra lines:

iptables -N abusers # somewhere near the other -N lines

iptables -p tcp --dport 1234 -j abusers # deflect them through chain
iptables -p tcp --dport 1234 -j ACCEPT # otherwise let them past
...
iptables -j DROP

then a paragraph of lines like:
iptables -A abusers -s 123.45.67.89 -j REJECT
....etc.

> I've also seen where the -SYN option should be used and I've played with
> the ESTABLISHED and RELATED options. ANY ideas on this will be greatly
> appreciated.

I don't think you want to distinguish at all. It's enough that the
originator of the packet has been a Bad Boy, not whether it's a new one or
not. Reject them mid-connection, why not :)

[snip entire current script]

~Tim
--
Famous moments vanish without trace |piglet@stirfried.vegetable.org.uk
Trees grow tall, fields grow wheat |http://pig.sty.nu/

On Mon, 29 Nov 2004 09:32:41 -0600, Jeff Franks wrote:
> I have a gaming server and am trying to create an IPTABLES firewall that
> will allow me to "ban" an IP. I have been able to do this, but the ban only
> takes place if I reboot the firewall pc. I need this to be something that
> can take effect immediately. If I have a cheater/abuser in the game, I need
> to be able to script something so that I can block all traffic from that
> person's IP or IP Range. From what I've dug up, this should be doable with
> a simple :
>
> iptables -A INPUT -s 123.45.67.89 -j DROP
>
> I've also seen where the -SYN option should be used and I've played with the
> ESTABLISHED and RELATED options. ANY ideas on this will be greatly
> appreciated. BTW, the game works fine, all the port forwarding and NAT
> works great. I just need the ability to block IP's on the fly. If I can't
> get this to work, I'd just as soon go back to the LinkSys I had in place
> before :-/
>
> Thanks
>
> jf
>
> Here is my current IPTABLES script. I know its simple, but while trying to
> determine how to do this, I've stripped all the fluff out. I'll put it back
> once I figure out my problem.
>

you can use the route command
/sbin/route add -host $TARGET$ reject
or drop the IP in /etc/hosts.deny


--
Chaos, panic & disorder - my work here is done

http://beginnerslinux.org
http://repo.mine.nu

Jeff Franks wrote:

> I have a gaming server and am trying to create an IPTABLES firewall that
> will allow me to "ban" an IP. I have been able to do this, but the ban
> only
> takes place if I reboot the firewall pc. I need this to be something that
> can take effect immediately. If I have a cheater/abuser in the game, I
> need to be able to script something so that I can block all traffic from
> that
> person's IP or IP Range. From what I've dug up, this should be doable
> with a simple :
>
> iptables -A INPUT -s 123.45.67.89 -j DROP

Shouldn't you use iptables -I INPUT -s 123.45.67.89 -j DROP (or REJECT)

with -A you "a"dd the rule to the end of your chain, with -I you "i"nsert it
at the beginning of the chain...

prompt

Wow, thanks for the info. I'll give all this a try asap. I like the
"abusers" chain idea. Still, the problem is that when I run the command
listed, it doesn't immediately take effect. I had this exact same issue a
few months back, but it was on RedHat 7 and an olllld version of IPTABLEs.
This one is on RH 9 and the newest IPTABLES rpm. grrrrrr.

Thanks again,

jeff
"Tim Haynes" <usenet-20041129@stirfried.vegetable.org.uk> wrote in message
news:86y8gkr6mc.fsf@potato.vegetable.org.uk...
> "Jeff Franks" <jfranks1970@charter.net> writes:
>
>> I have a gaming server and am trying to create an IPTABLES firewall that
>> will allow me to "ban" an IP. I have been able to do this, but the ban
>> only
>> takes place if I reboot the firewall pc.
>
> Yuck? WTF?
>
>> I need this to be something that can take effect immediately. If I have a
>> cheater/abuser in the game, I need to be able to script something so that
>> I can block all traffic from that person's IP or IP Range. From what I've
>> dug up, this should be doable with a simple :
>>
>> iptables -A INPUT -s 123.45.67.89 -j DROP
>
> Well yeah, that should work. Does what it says on the tin - appends a rule
> taking packets from that ip and drops them, to the end of the INPUT chain.
>
> Now.
>
> You might've wanted to REJECT them instead, for speed - up to you in this
> case.
>
> Depending on how many concurrent packets hitting your server are destined
> for the game rather than other services, it might make sense to peel off a
> chain and call it `abusers', so you check incoming packets first whether
> they're for the game service (by port#), then you push them through the
> game-specific abusers chain where naughty people are REJECTed/DROPped, or
> otherwise if it's not for the game, it bypasses all that processing and
> gets handled normally.
>
> Second thought: depending on what else happens in your iptables `INPUT'
> chain, you might find that appending or prepending the rule after
> everything else is daft. This is where having a separate chain for abusers
> makes sense because you can firmly stick the rule on either end of that
> chain in the knowledge that it's not messing-up your firewall order any
> further (e.g. the abuser should be able to send you a mail (25/tcp) saying
> sorry).
>
> I'm thinking in terms of my firewall script at
> <http://spodzone.org.uk/packages/secure/iptables.sh> here, but with a few
> extra lines:
>
> iptables -N abusers # somewhere near the other -N lines
>
> iptables -p tcp --dport 1234 -j abusers # deflect them through chain
> iptables -p tcp --dport 1234 -j ACCEPT # otherwise let them past
> ...
> iptables -j DROP
>
> then a paragraph of lines like:
> iptables -A abusers -s 123.45.67.89 -j REJECT
> ...etc.
>
>> I've also seen where the -SYN option should be used and I've played with
>> the ESTABLISHED and RELATED options. ANY ideas on this will be greatly
>> appreciated.
>
> I don't think you want to distinguish at all. It's enough that the
> originator of the packet has been a Bad Boy, not whether it's a new one or
> not. Reject them mid-connection, why not :)
>
> [snip entire current script]
>
> ~Tim
> --
> Famous moments vanish without trace
> |piglet@stirfried.vegetable.org.uk
> Trees grow tall, fields grow wheat |http://pig.sty.nu/

>
> Shouldn't you use iptables -I INPUT -s 123.45.67.89 -j DROP (or REJECT)
>
> with -A you "a"dd the rule to the end of your chain, with -I you "i"nsert
> it
> at the beginning of the chain...

Thanks for the reply. I did change this in the last test I did last night.
The script does read "-i" now instead of -a. It appeared to have no effect
on the blocking of the traffic though.

Thanks again,

jeff

"Jeff Franks" <jfranks1970@charter.net> writes:

>> Shouldn't you use iptables -I INPUT -s 123.45.67.89 -j DROP (or REJECT)
>>
>> with -A you "a"dd the rule to the end of your chain, with -I you "i"nsert
>> it
>> at the beginning of the chain...
>
> Thanks for the reply. I did change this in the last test I did last night.
> The script does read "-i" now instead of -a. It appeared to have no effect
> on the blocking of the traffic though.

There's something screwy here. -I would have the effect of prepending the
rule right at the top of the INPUT chain, so effects should be immediate.
How do you know your other firewall rules are taking effect? Do you have
any regular rule-replacement happening, e.g. through cron? Are you getting
any error messages running that? What does `iptables -nL' show immediately
afterwards?

How are you interacting with redhat's firewall rules, too? Traditionally
they keep a version in /etc/sysconfig/ somewhere, that is used on system
startup. However, my own preference is to have a master script such as
/root/iptables.sh, which I run and use to update the system-wide version.
(I'm normally on Gentoo, so it's /var/lib/iptables/rules-save to me, but
something under /etc/sysconfig/ to you.)

~Tim
--
zsh % perl -ce 'more or less' |piglet@stirfried.vegetable.org.uk
-e syntax OK |http://pig.sty.nu/Pictures/

"Jeff Franks" <jfranks1970@charter.net> writes:

]Wow, thanks for the info. I'll give all this a try asap. I like the
]"abusers" chain idea. Still, the problem is that when I run the command
]listed, it doesn't immediately take effect. I had this exact same issue a
]few months back, but it was on RedHat 7 and an olllld version of IPTABLEs.
]This one is on RH 9 and the newest IPTABLES rpm. grrrrrr.

I suppose you could always stop and restart iptables. There should be a
/etc/init.d script to do so.

> There's something screwy here. -I would have the effect of prepending the
> rule right at the top of the INPUT chain, so effects should be immediate.
> How do you know your other firewall rules are taking effect? Do you have
> any regular rule-replacement happening, e.g. through cron? Are you getting
> any error messages running that? What does `iptables -nL' show immediately
> afterwards?

an 'iptables -L' shows the new rule in effect. (at the first with a '-i' or
at the end with a '-a').

The way I have tested this is to start the firewall and get another person
to help me by either joining the game or Roger Wilco. Then I try the
commands. If it were to take effect immediately, I'd expect it to bump him
off of whatever connection he has. It doesn't. Even if I restart the
iptables service, it continues to let him stay in. Once I restart the
entire computer (which kills all connections) it will block them. Like I
mentioned before, this is the second clean build of RedHat that I have tried
this on. On this firewall, I installed RH9, updated relevant rpms
(including iptables), and setup this script. The OP contains my ENTIRE
script as of now. ARGH!??!?!?!

>
> How are you interacting with redhat's firewall rules, too? Traditionally
> they keep a version in /etc/sysconfig/ somewhere, that is used on system
> startup. However, my own preference is to have a master script such as
> /root/iptables.sh, which I run and use to update the system-wide version.
> (I'm normally on Gentoo, so it's /var/lib/iptables/rules-save to me, but
> something under /etc/sysconfig/ to you.)

I am running this from a script called /etc/rc2.d/rc.firewall. All the
rules show up in the iptables -L list and until I run the rc.firewall
script, port forwarding does not work. So, I'm confident that it is
executing correctly. While testing I have been saving my iptables to the
"permanent" setup using the 'iptables-save > /etc/sysconfig/iptables'
command. This does the same thing as your rules-save command, i think (puts
all effective rules in the "system" script). and if I leave the
/etc/sysconfig/iptables file intact (not removed) when I reboot, the
firewall automatically starts.

thanks again for your help. this is confusing what little I know about
iptables :-/

jf

"Jeff Franks" <jfranks1970@charter.net> writes:

[snip]
> The way I have tested this is to start the firewall and get another
> person to help me by either joining the game or Roger Wilco. Then I try
> the commands. If it were to take effect immediately, I'd expect it to
> bump him off of whatever connection he has. It doesn't.

What command exactly are you typing?

Are you using --syn at all? (Don't, as you want to be rejecting all packets
from them.)

You would only expect it to disconnect if it sent a REJECT back to the
source that prompted a complete disconnection. Such a reject should really
be `--reject-with tcp-reset', too.

> Even if I restart the iptables service, it continues to let him stay in.
> Once I restart the entire computer (which kills all connections) it will
> block them.

How about if you
nohup /etc/init.d/network restart
? Actually, doing an ifconfig eth0 down ; ifconfig eth0 up might fix it
(but not from a remote shell lest you want to lose access altogether ;)

[snip]

~Tim
--
Tell me where oh where has summer gone |piglet@stirfried.vegetable.org.uk
It hasn't come this year |http://spodzone.org.uk/cesspit
You always cry when swallows fly |
With doubts in search of dreams |