I host a few sites for friends and family.

My WebHost has sent a notice that we should expect attacks from you know who.

They have made available PortSentry from Psionic.

My concern at this point is how to configure which IP's to allow.

They have it so that PortSentry runs from a telnet "menu". I took a quick look and enabled it at which point it said something about making sure I allowed my ISP's ip. I thinks thats what it said 'cause I disabled it and started a search on the Net for info on configuring it, That's how I found this Forum.

Well I went back in and the original menu no longer dispalys the "welcome" page and just allows options to restart add and block IP's etc.

So, I hoping by now you get my drift and can offer some help in my determining what IP's need to be enabled. I'm guessing that after I check whose been scanning my server, I should block those addresses.

But who, should I allow. Do I need to explicitly allow all ISP's that my clients dial in from? That doesn't sound right.

TIA - Lance

Its called *Port*sentry for a reason :-]
With Portsentry you can either (un)block ports, or (un)block ranges; you should add all DNSes, connecting mailservers etc to the ignore file anyway, and make sure which mode Portsentry runs to determine if you should add publicly accessable ports to the ignore section of the config or chalk up the ranges. Portsentry seems to accept netmasks, so IIRC, you could get away with specifying like 192.180.0.0/255.255.0.0 type ranges.

*IMO Portsentry should be replaced with Snort.
Snort isnt the same in that it doesnt have blocking capabilities, but is more advanced because it *scans* incoming packets (on all ports) for malicious contents. By comparing it with "signatures" it is able to detect abuse of services by exploits/dos/trojan/whatever else. It also comes with complementary apps that can do the blocking.

Also I would like to make a note on Single Points Of Failure. Any of these apps, including the firewall can be considered that way, because they don't check theirselves for having running state or validity of rules they put out, only if their own config is right at startup. In case of (inadverted|malicious) breakage this would leave the services on your box unprotected and open for public (mis)usage. Run services on separate boxen (eggs in one basket), don't run services(+versions) with known vulnerabilities, make sure your webapps are well-coded and maintained, chroot/jail if necessary.

HTH somehow