Hi

My brother has started 'boosting' and it is quite annoying.. opens a few hundred connections to yahoo servers, whilst creating yahoo IDs. I believe he is probably trying to sell them online, to make money.. He wont give me a reason why he is creating thousands of similarly named yahoo game IDs, with high grades.

I don't wish to be responsible for the consequences, so am going to block him from using the program. I have found out that he "booster" connects to yogXX.games.scd.yahoo.com

Doing a 'host' on yogxx.games.scd.yahoo.com, shows them to be on the IP range

66.218.68.*

So would this suffice

iptables -A OUTPUT -o eth1 -s 192.168.0.3 -p tcp -d 66.218.68.0/8 -j DROP

? have i got the subnet right?

Is it best to block it outbound, or block it on the INPUT chain?

Thanks for your advice

Duncan

I would suggest you block it in both chains, as well as maybe the FORWARD chain, if he proxies through your linux box. Your rule looks good to me, but I am not sure about the subnet. Also a good idea to use DROP as you did, it will make him pull his hair out trying to figure out what happened. lol

Remember the golden rule of iptables.
1. Write the rules
2. implement the rules
3. test the rules
3.5 Pull hair out.
4. repeat until perfect or no hair left.

If he is using your pc, put a -j LOG rule in the nat table POSTROUTING chain to catch any of the extra ip numbers he may jump to,
then block them in the OUTPUT chain.

For your example...
iptables -A OUTPUT -o eth1 -s 192.168.0.3 -p tcp -d 66.218.68.0/8 -j DROP
...
don't worry about the -s source ip address if it is your pc,
the subnet will be 24 not 8,
do -I rather than -A to place it first in the rule list.
Rules should run from the most specific first to the most general last.

If he is FORWARDING through your pc from his pc, add the rule to the FORWARD chain.

good call. Check your /var/log/messages file to monitor it.

Cheers guys, sorted...

you say put the most general rules last, the specific ones first? .. i guess it makes sense. but isn't a packet more likely to be hit by a general rule, than a specific one??

I run iptables -vL | more, and usually always see that the rules are in correct order of packet count... so i must have them the right way round i think

I have the rules so that the ones with the highest packet count (shown by iptables -vL) are at the top .. regardless of the byte count? .. i take it this is the correct way to go

Cheers

Duncan

NO NO NO...

The logic of the rulesets...
As soon as a packet matches a rule, it follows the -j target.
If it is ACCEPT or DROP or SNAT or DNAT etc, the packet stops traversing the rules.
The first rule that matches, dumps the packet out of the rule set, (generally)...

It is very likely a packet won't match a specific rule but very likely it will match a general rule.
So if the general rule comes first, the specific rule is a waste of time...
The best example of a general rule is the chain POLICY... imagine if that came first...!

well .. here is my ruleset, so you can pick at it and tell me how to tweak?

# Clear those tablez
iptables -F
iptables -F -t nat
iptables -X

# Set default policies
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

# INPUT
iptables -A INPUT -i eth0 -j ACCEPT
iptables -A INPUT -i eth1 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -i eth1 -p tcp --dport 113 -j REJECT --reject-with tcp-reset
iptables -A INPUT -i eth1 -p icmp --icmp-type echo-request -j ACCEPT
#iptables -A INPUT -i eth1 -p tcp --dport 8000 -j ACCEPT
iptables -A INPUT -j REJECT

# FORWARD: Allow all connectionz out, but only existing and related ones
# back in
iptables -A FORWARD -i eth1 -o eth0 -m state --state ESTABLISHED,RELATED -j ACCE
PT
iptables -A FORWARD -i eth0 -o eth1 -j ACCEPT
#iptables -A FORWARD -j LOG --log-prefix "FORWARD: "
#iptables -A FORWARD -j REJECT

# Do the funky masquerading
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE


Apologies for the comments, i was having a weird day

Duncan

Never apologize for commenting. Commenting makes helping alot easier. It shows intent.

A tip to make future editing of the script a whole lot easier. Use variables. At the top of the script define variables like this

INTINT="eth0"
INTIP="192.168.0.1"
EXTINT="eth1"
EXTIP="62.134.23.112"


This way you can use $INTIP where you used to type the full ip address. Saves a lot of time as you can then just change the variable definition and it will effect all rules that use the variable.

Ok, I don't apologise

But don't i get any feedback? Is it obviously that damn good?

Duncan

They are ok, just missing many of the protection rules...

Have a read of this tutorial

You have not said yet, but I assume your brother has a pc on eth0?

protection rules? like what.. i think it is fairly well protected, with ESTABLISHED,RELATED doing most of the heavy work...

yes, my LAN is on eth0, cable modem is on eth1

Duncan

Take a look at the example scripts in the tutorial,
anti spoofing rules, flood rules, LOG rules, invalid packet rules, ACCEPT policies, you have an open FORWARD policy, module loading and sysctl settings as a minimum recommendation...

If someone scanned your system, they would discover a lot of information about what is/isn't open etc and you wouldn't know they were even looking...

I'm not being devil's advocate just because some extra rules are nice,
it's because they are necessary.
A good example would be blocking outward connections, especially ports 137-139 which you will find in a LOG file.

No Peter, if you look closely, i DO NOT have an open FORWARD rule.

The FORWARD rule's default POLICY is DROP. Therefore, anything not covered by my two FORWARD rules, is DROPPED by this default policy.

What's the point in blocking on the OUTPUT chain? nothing runs on the box itself, so there is little point.

The same applies to the INPUT rule, as does to the FORWARD rule. I can port scan myself from any box on the net, and it doesn't even know I exist.

Perhaps you don't fully understand the implimentation yourself.

I was trying to keep my ruleset to a bare minimum, so packets don't have even more crap to wade through, and take even more time.

Cheers

hi peter sorry if that reply sounded a bit rude/upfront, it was not meant to be.

So perhaps you could tell me the sysctl settings you would use on a linux router box? I thought the defaults were pretty sound?

I dont know how safe it is to ignore broadcasts, bogus error responses etc...

I certainly don't want to ignore all icmp echo requests..

Cheers

Duncan

OK,
I read this from your post...

# Set default policies
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

So I see a default ACCEPT policy... coz this line is commented out...
#iptables -A FORWARD -j REJECT

That to me is an open FORWARD policy...

You haven't stated whether your brother is using your box or one in the LAN.
My guess it is in the LAN, but guesses can cause trouble... especially if you want to be restrictive...

''My brother has started 'boosting' and it is quite annoying.. opens a few hundred connections to yahoo servers, whilst creating yahoo IDs. I believe he is probably trying to sell them online, to make money.. He wont give me a reason why he is creating thousands of similarly named yahoo game IDs, with high grades.

I don't wish to be responsible for the consequences, so am going to block him from using the program. I have found out that he "booster" connects to yogXX.games.scd.yahoo.com''

So I'm going on what's posted, and you need to supply the rest...

Restricting in the OUTPUT chain if he is local, in the FORWARD chain & the nat table POSTROUTING chain if he is LAN based.
You will need to cover your bases and get a list of his traffic in order to make a sensible blocking rule set.
Use -j LOG rules for that... many of them...

The tutorial covers all the necessary settings and the reasons why.
It's long, but covers everything you are asking.
And it's much better you read this than we keep posting excerpts. The format is much better in the tutorial.
If there's something confusing in the tutorial, we're here to help with that...