[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [cobalt-security] ipchains adding to rc.local



Hi Robbert,

> They way I read the thing you are mentioning about the firewall script
> doesn't really differ from the thing Shimi mentioned earlier, I think.

Well, yes and no. What shimi proposed (IIRC) is that you could enter any
offender to a script with appropriate ipchains commands. This should work.

What I'm proposing is to first get a firewall that is tuned to your needs,
so that the chance of having to block offenders is minimal. My rule of thumb
is: deny everything, except... This approach has worked for me for quite
some time. <knock on wood>

With the manual adding of offenders to /etc/offenders (or whatever) you do
not specify a default rule. For instance, I have a default REJECT for input,
ALLOW for output and REJECT for forward (since this is a host with only one
ethernet interface). With unlimited access from localhost to localhost,
Active Monitor won't complain.

> However I think you are referring to an extra add-on or something ?? Or is
> the firewall script within Ipchains ?

I'm referring to a complete script that parses ipchains commands and thus
makes a complete ruleset.

> I searched over google for some information and found an pretty big HOWTO.
I
> know perhaps I should, not perhaps, I should!!.

Yes, you should. ;-)

Just in case, a couple of links. For LDP stuff, you might want to check
http://ldp.nllgg.nl, which should be a closer mirror for you.

http://www.linux.org/docs/ldp/howto/Firewall-HOWTO.html
http://www.linux.org/docs/ldp/howto/IPCHAINS-HOWTO.html
http://www.linux.org/docs/ldp/howto/Security-HOWTO.html
http://www.openna.com/products/books/securing-optimizing-linux/solrhe.htm

> Thanks ! I'm getting more and more interested with security and I'm up to
> installing snort, and more of that stuff, as soon as I have RTFM's.

That takes the most time of all, R'ing those FM's.

Get yourself acquainted with how ipchains works, first. How to call it,
which options it takes. If you know *what* you can specify, you can build a
script pretty quick just using your "boerenverstand" (excuse my French ;-P)
and as you learn more, you can easily do more neat stuff with ipchains.

For instance, I started out with a *very* simple script. It parses the
output of /sbin/ifconfig to determine all ip's on eth0:* and processes each
ip individually with generic rules. After that, I manually added specific
rules for specific interfaces/ip's (for instance eth0:1 which might have ip
192.168.1.2). If I add a new ip, I rerun the firewall script and off we go
again.

I am sort of lucky to have access to some more or less static ip's for my
Internet access. This makes tight rulemaking easier. For instance, I do not
allow any of my customers access to the GUI, I just give myself access to
it. Based on my access ip's, I can easily manage this.

> Last question for now. When a user is blocked through Ipchains, and tries
to
> visit again the server. What happens then ? Is there simply no response ?
Or
> is the user/visitor prompted with an access denied error ?? Just wondering
> about that.....

This depends on the service the user requests and the software he/she uses.
Windows is afwul with being denied access, since most processes will hang
almost infinitely. Ever tried Windows' telnet to connect to a host that
blocks port 23? Go get a cup of coffee then.

Furthermore, it depends on how you block access. If you tell ipchains to
DENY port 23, connections will stall. On the other hand, if you tell
ipchains to REJECT port 23, a decent telnet client will promptly tell you
you've been denied access. REJECT thereby gives more information on the
specific block to the process that requests access. I use REJECT almost
exclusively.

Good luck... Nico