Blocking whole class B net not working

ITMannen · #1 (**permalink**) 06-06-2008, 11:48 AM

Hi all.

Astaro version 7.1 (last version before 7.2, we have not updated yet).

We have problems with a bot net that is originating at a high number on machines on a service in Holland.

I want to block the whole net 85.17.0.0, so i have made a network group called "blocklist" and put 85.17.0.0/255.255.0.0 as a member in the group.

The first line in my packet filter is to block "blocklist" - any - any, which according to my logic would effeciently block that whole subnet.

However traffic to that net is not blocked at all.

So i changed the "automatic packet filter configuration" for my DNAT to manual, and put the accept rule after the block rule.

Same result.

I alsy tried to block individual adresses with the same result.

What may be a clue is that the website i want to keep "clean" is on an additional ethernet adress on the primary internet interface.

So to keep the question short: Why the h*ll cant i block traffic to an web side on the inside of the firewall that has a external adress that is not the primary adress on the interface.

My astaro reseller was as baffled as me, however we have national day in sweden today, so the reseller is having the weekend off.

Anyone stumbled upon this before?

BarryG · #2 (**permalink**) 06-06-2008, 07:46 PM

Sounds like the rule should have the DESTINATION set, not the source.
Or, 2 rules, one for source, one for dest.

Barry

ITMannen · #3 (**permalink**) 06-06-2008, 10:33 PM

Quote:

Originally Posted by BarryG

Sounds like the rule should have the DESTINATION set, not the source.
Or, 2 rules, one for source, one for dest.

Hello Barry.

I dont really understand why the destination should be set.
If i have as my first filter rule any IP packet with the source from the block list should be dropped, it would not let that packet continue in to my webserver.

I will try to set a filter for the destination as well, just for good measure.

It just sounds a bit fishy to me, i never had problems with that type of filter before, however i never tried this on an additional adress on the external interface before.

Keith_M · #4 (**permalink**) 06-07-2008, 01:30 PM

If Source any any drop
Put this as rule #1 (or close to the top)

This should block those IP's. Turn on logging and watch the live packet filter log to verify. Trun the log off afterwards if you want.

If it still does not work turn logging on a bunch of rules and filter for that IP so see if it blocking. Be sure to turn off the automatic packet filter rule. I am not a big fan of those

BarryG · #5 (**permalink**) 06-08-2008, 07:06 AM

Quote:

Originally Posted by ITMannen

I dont really understand why the destination should be set.

I was assuming the traffic is coming from infected machines in your network, going to the the other network.

If not, then it's not necessary, but wouldn't hurt to also have this outgoing rule.

Are you under a DOS attack?
ICMP?

Generally, the PF rules for 'ALL' services don't affect ICMP.

Have you looked at the anti-flood/anti-DOS settings, and the ICMP settings?

Barry

ITMannen · #6 (**permalink**) 06-13-2008, 06:21 PM

No, the attack is from outside to a webserver on the inside.
And it is not a DOS attack, they use a certain script to "reserve" all my merchandise so that it will be put "out of stock" for my proper customer.

I assume it is a business competitor trying to block our business, paying some hacker to do so.

Anyway, i will investigate it further, but it seems that when using additional adresses the rules dont apply. The same block on the main address works fine.

BarryG · #7 (**permalink**) 06-14-2008, 01:44 AM

Did you put the block PF rule above any ALLOW rules?

I have lots of networks, including ClassA and B's blocked in the PF, and it works fine.

Barry