OK, now I have managed my rsyslogd to log the firewall into a separate file I would like to use a script which looks into this file for intruders which for example try to ping, telnet, ssh, rdp etc into my dsl connection.
And then use a kind of app or firewall on my ubuntu server to block them.
Yes my firewall logs them but does not block them if the policy is enabled, so they have access on through the firewall and the connect to my server but I only want some known IP addresses have access through it and this I cannot program in the firewall so I have to use some extras.

Or am I thinking way to far and is there a better solution with IPtables or app?

Is it possible to watch tcp connections between the firewall from outside IP addresses and the ubuntu server?

CSF (config-server firewall) is an excellent front-end for IPtables. You can configure it to block, say, anyone who has failed to log in via SSH 5 times within a short time span.

http://www.configserver.com/cp/csf.html

iptables has a limit test that will match so many packets per sec/min/hour/day that match the rule. I've also used this script in a cronjob that scans the syslog for ssh "Invalid user" or "not allowed" messages and drops the offending source IP address in hosts.deny:

Is it better to use UFW instead of IPtables in commandline mode ? And what happens with the IPtables rules if you use UFW rules too?

Not really; all of these tools under Linux (and I could probably find a dozen or two) are designed as easy ways to generate iptables rules. So, in theory, you could mix and match rules, but in practice, if one approach sets up a chain that the other tool doesn't know anything about, it is probably a recipe for problems. With something like UFW, they might have a little 'special sauce' (expert knowledge, rather than any proprietary technology) to make, eg, DoS attacks less likely to succeed. But, you can always inspect the rukleset a tool generates and see whther you understand all of it...

Logically, of course, a set of rules is a set of rules. So, if you write exactly the same set of rules by hand, or it comes out of a generator script, it is still the same set of rules and still does exactly the same thing. (something like UFW is likely to do stuff in addition to setting up firewall rules, though; but you could copy those things too.)

Again, there are probably about a dozen slightly different ways of skinning this particular cat, all slightly different, all doing vaguely the same sort of thing all having slightly different advantages and disadvantages.

From where you are (ie, with a log file containing a list of 'bad' ips), you could consider running a simple filter that strips those IPs out and uses that list as a blacklist. I'm not sure that I'd advise that for a couple of reasons

• unless you do something else, as well, that blacklist could grow very large and if you do a very latge number of compares, you could slow things
  down to an extent that makes a doS more likley to succeed (and I hate that idea)
• and there is miscellaneous scripting -re-inventing the wheel- that you could get wrong (and I hate that idea too)

look at denyhosts, blockhosts and fail2ban, and this for example

Another approach is here. (simply looking at open connections from standard linux commands and using that for the block list)

At this point, you could reasonably suggest that I have given you too many choices (and the one suggested by tsg is valid, too); If you can define exactly what you are defending against, you can quite simply get to a point at which you can tell whether any particular approach does the business; the problem is that if you define the problem incorrectly, you'll have to be lucky for the solution to work.

telnet??? telnet is insecure as a very insecure thing and you shouldn't be running it. ping is perhaps something that you might not desire in a security-paranoid kind of context, but shouldn't be too damaging; can't you just drop packets from the outside world on the appropriate port?

ssh can be potentially quite problematic, are you going to ssh in from the outside world? if not, just block ssh from the outside world. If you are to ssh in from the outside, read this. rdp? again can you block from the outside world?

...which points bring us to the fact the OP might be doing the right things the wrong way as he says in his OP:
so in essence he should 0) disable unnecessary (network-facing) services before doing anything else, 1) configure limits, password aging, force pubkey auth etc, etc on any user accounts that will log in from remote, restrict access to all other accounts and ensure proper auditing is in place, 2) configure and harden services that need to be available and only then 3) allow only those "known IP addresses" access to those services. In short: first harden the machine, then the network.

* tsg's iptables "-m limit" example is a good example of what Netfilter has to offer (it really has a lot more useful modules) and its fire-and-forget approach which contrasts with "deflate" which is a script (userland: slower), its dependencies (netstat, crond, mailx) and "seemingly notable features" like email (which users will either forget to read, forget to respond to or will simply ignore after 3000 emails anyway).


'watch -n 2 "iptables -n -t filter -L|grep ^[0-9].*tcp";', netstat, iftop, iptstate, ntop, you name it.

Thank you all for this wide bundel of information.
I have a hardware Watchguard Firebox III behind my dsl connection, so I already do a lot of blocking there. But some services I can't deny which go to my Ubuntu server but in the Firebox I cannot check on timeouts or wrong entered password for FTP for example so that's what I have to do in the server.
I will have to re-read your answers over and over to find out what is best for me.

And in the other way I don't like to use those webmin features because I'm very curious to learn and understand the commandline rules.

I think I will tryout the script from tsg and use it also for FTP connections, what would be a good value for the time it should run? every 10 minutes?

And do I have to change anything in rsyslog so the failures for FTP or SSH logins will be stored in the messages logfile?

I retract my previous statement about tsg's work as I mistook it for an iptables script: his is as unnecessary as "deflate": best use fail2ban as suggested by salasi because tcp wrappers do not block things at the network level, which you should prefer over service level blocking, see this.


If you're new to Linux then your definition of "best", with all due respect, may be based on what little you know. If my reply of "harden first..." doesn't sound like the single best approach then I strongly suggest you read up on system hardening or ask additional specific questions.