Topic: Can't block *anything*

[Steven Bayrak]

I am having problems blocking certain ips so that people on my network cannot access them.  I saw a previous post from Nathan showing examples but they do not work. Im using an E-Smith v4.1.1. Im tring to block out napster [www.napster.com->(64.124.41.39)]. No matter what I do I can still ping it.

Author: Nathan Fowler (evilghost_AT_stickit.nu)
Date:   05-24-01 09:56

Deny the bastard access using ipchains. Deny his entire Class C subnet.

Deny everything to that Class C
/sbin/ipchains -N in
/sbin/ipchains -A in --source 64.124.41.0/24 -j DENY
or
/sbin/ipchains -A in --source 64.124.41.39/32 -j DENY

Hope this helped

The above example does *not* work. Can anyone post examples that DO work? E-Smith's ipchain rules are setup all weird.

[Peter Hollandare]

Try this :

/sbin/ipchains -I input -s 64.124.41.0/24 -j DENY -l

This will deny their entire mask from 0 to 255

Note! e-smith's daily event removes it, but theres a simple workarround for this, rather than copy new templates (which i find annoying), just follow these simple steps under.

1. make a file called fire.rc in /etc/cron.daily (pico fire.rc).
2. paste sample i gave. (/sbin/ipchains -I input -s 64.124.41.0/24 -j DENY -l).
3. chmod 777 fire.rc

Done.

Since all files in here only run 1time per day, its simple to activate the it right away. Just enter ./fire.rc and its activated instantly.

[Kirrily Robert]

Peter Hollandare wrote:

> Note! e-smith's daily event removes it, but theres a simple
> workarround for this, rather than copy new templates (which i
> find annoying), just follow these simple steps under.
>
> 1. make a file called fire.rc in /etc/cron.daily (pico
> fire.rc).
> 2. paste sample i gave. (/sbin/ipchains -I input -s
> 64.124.41.0/24 -j DENY -l).
> 3. chmod 777 fire.rc
>
> Done.
>
> Since all files in here only run 1time per day, its simple to
> activate the it right away. Just enter ./fire.rc and
> its activated instantly.

Peter, I really have to take issue with you on this one.  As I've already said once this morning, chmod'ing things to 777 is a HUGE SECURITY RISK.  I would not advise anyone to do this.

Furthermore, putting things into /etc/e-smith/templates-custom, despite being a little different to some other distros, is a very useful thing to do.  It will ensure that your customisations are backed up along with your other configuration and user data, and keep it in one clear place to make it easier for you to figure out what you've changed.

Finally, your recommendation may not even work.  What's to say that your script will run straight after the e-smith daily update of /etc ?  Perhaps it will run just before, in which case you won't see your modifications at all.  Or perhaps there will be a pause of some minutes between them while other tasks run, which would give a brief failure each day.

K.

[Scott Smith]

Kirrily Robert wrote:
>
> Peter, I really have to take issue with you on this one.  As
> I've already said once this morning, chmod'ing things to 777
> is a HUGE SECURITY RISK.  I would not advise anyone to do this.

Especially if files are owned by and/or will be executed as root.

> Furthermore, putting things into
> /etc/e-smith/templates-custom, despite being a little
> different to some other distros, is a very useful thing to
> do.  It will ensure that your customisations are backed up
> along with your other configuration and user data, and keep
> it in one clear place to make it easier for you to figure out
> what you've changed.

One other item you've not mentioned, and one that I feel is more critical than the issues you did point out, is that making customizations to files/areas that e-smith manages via templates may (probably will) result in those customizations being lost the next time the e-smith templates are expanded. Using the template system ensures customizations are maintained and not overwritten.

Scott