Slashdot Mirror

And for that whirlwind tour of what's good in that system, take a peek at my OpenBSD and you slides.

To me this sounds like the main problem is the "security" device that's generating a lot of noise.

My solution would be to put something (very low power gear will do) running a recent OpenBSD and a PF ruleset with overflow rules modeled on the ones outlined here in front of that whiny device. The ruleset would need to be modified to fit the observed traffic, of course. Then anyone who fits the profile of unwanted traffic simply auto-LART themselves into the table of blocked addresses.

With a properly placed adaptive firewall like that, the noisemaker would likely not see enough of the traffic to trigger any of the useless warnings.

Re-using the existing connection is of course useful to fend off the traditional killing techniques for rapid-fire password guessers (such as http://home.nuug.no/~peter/pf/... and similar), but you still have to come up with the set of bytes that will let you authenticate. Which leads to the other thing --

The clowns I have been writing about ("The Hail Mary Cloud" -- http://bsdly.blogspot.ca/2013/... and links therein) used a totally different approach, but the general advice re passwords and other issues given in the conclusions apply here too.

Peter N. M. Hansteen's PF tutorial and books are recommended reads, Peter remains involved with the developers and the information stays relevant and useful. He also ensures that readers using other BSD systems, especially with older versions of pf, can learn just as much from it.

* The Book of PF, 3rd Edition, 2014 - ISBN: 978-1593275891
* http://home.nuug.no/~peter/pf/

Michael W Lucas is another author that writes books for both the BSD and sysadmin communities, similarly, he works closely with developers and users to release these short, yet all-encompassing tomes of information, covering a wide variety of topics.

https://www.michaelwlucas.com/...
* Absolute OpenBSD, 2nd Edition, 2013 - ISBN: 978-1593274764
* SSH Mastery, 2012 - ISBN: 978-1470069711
* Sudo Master, 2013 - ISBN: 978-1493626205

And of course, official documentation is great. The effort of many people working to improve, Jason McIntyre improving readability and overall quality, Ingo Schwarze's amazing work on mandoc(1) tools. OpenBSD's FAQ, which is usually the first step people take to learn more about the system, is maintained by Nick Holland.

http://www.openbsd.org/faq/
http://www.openbsd.org/cgi-bin...

Has our AC determined whether Kerberos is in OpenBSD ports? I am reading "Kerberos has been removed from the base system. Kerberos support will be available via a package."

My money is on OpenBSD for projects like this. You get very compact base system that still has all the stuff you need in there for a project like this. And even my old PF tutorial has enough info to get you up and running.

But with the man pages and the OpenBSD FAQ you really have all the information you need at your fingertips.

Over in OpenBSD land, PF has supported tables of IP addresses that can be manipulated on the fly for years (see eg these table samples. One common use is (courtesy of another useful adaptive feature called state tracking options) to detect and block bruteforcers (see eg this set of tutorial examples). In addition, the OpenBSD versions of dhcpd and bgpd as well as other applications are routinely set up to interact with your filtering config via tables.

Another adaptive or dynamic feature is anchors, named sub-rulesets where applications such as a proxy (ftp-proxy for example) or relayd (the load balancer) can insert and delete rules as needed. You can manipulate rules inside anchors from the command line too, of course.

My BSDCan slides has more material, as of course does The Book of PF, and never forget The PF docs as the authoritative source.

Over in OpenBSD land, PF has supported tables of IP addresses that can be manipulated on the fly for years (see eg these table samples. One common use is (courtesy of another useful adaptive feature called state tracking options) to detect and block bruteforcers (see eg this set of tutorial examples). In addition, the OpenBSD versions of dhcpd and bgpd as well as other applications are routinely set up to interact with your filtering config via tables.

Another adaptive or dynamic feature is anchors, named sub-rulesets where applications such as a proxy (ftp-proxy for example) or relayd (the load balancer) can insert and delete rules as needed. You can manipulate rules inside anchors from the command line too, of course.

My BSDCan slides has more material, as of course does The Book of PF, and never forget The PF docs as the authoritative source.

Over in OpenBSD land, PF has supported tables of IP addresses that can be manipulated on the fly for years (see eg these table samples. One common use is (courtesy of another useful adaptive feature called state tracking options) to detect and block bruteforcers (see eg this set of tutorial examples). In addition, the OpenBSD versions of dhcpd and bgpd as well as other applications are routinely set up to interact with your filtering config via tables.

Another adaptive or dynamic feature is anchors, named sub-rulesets where applications such as a proxy (ftp-proxy for example) or relayd (the load balancer) can insert and delete rules as needed. You can manipulate rules inside anchors from the command line too, of course.

My BSDCan slides has more material, as of course does The Book of PF, and never forget The PF docs as the authoritative source.

They've also added a nice feature called expiretables that keeps the "bruteforce" table small & efficient by expiring entries that haven't seen any hits after a definable period of time.

FWIW, there's also an entry in the official PF FAQ on this...

Thanks for mentioning the tuturial, but actually expiretable is no longer necessary. On anything with PF equal to OpenBSD 4.1 or newer a simple

pfctl -t bruteforce -T expire 86400

will expire table entries that have not had their statistics updated for the last 24 hours (86400 seconds)

I really should reverse the sequence at that page. expiretable likely still works, but it is no longer necessary to install a separate package to get table expiry.

The tutorial that explains what all this does is here. They've also added a nice feature called expiretables that keeps the "bruteforce" table small & efficient by expiring entries that haven't seen any hits after a definable period of time.

FWIW, there's also an entry in the official PF FAQ on this...

The tutorial that explains what all this does is here. They've also added a nice feature called expiretables that keeps the "bruteforce" table small & efficient by expiring entries that haven't seen any hits after a definable period of time.

FWIW, there's also an entry in the official PF FAQ on this...

For those already familiar with Peter Hansteen's website, I'll offer a Thumbs Up recommendation for his Book of PF.

There's already been several stories on Slashdot either submitted by or about him, and I don't recall any mention of his book. I'd say his efforts if not his humility deserve some kind of reward, and the reduced sale price of $19.77 is a bargain.

I generally do not get a lot of spam, but one episode recently made me collect some samples and blog about them (/.ed as Giving Your Greytrapping a Helping Hand).

That page also contains references such as the complete listing of subject lines from spammers caught in our blacklists over a few years' time.

Enjoy!

OpenBSD doesn't use ipchains -- it uses pf, which many people -- myself included -- like a lot. OpenBSD is secure and easy to get routing.

The end result is the same, but pf can be easily adapted to many tricks like this, automatically blocking SSH bruteforcing.

I'd give the beginners using Ubuntu a break. They're overwhelming sometimes, but the community growing is a good thing. I'm sure someone I've introduced to Linux has needed online help (badly!), but another friend I introduced to Linux really dug in and we're now both better developers because of it. You just don't know.

Subject says it all, really. The best approach is to set up an OpenBSD machine as your gateway, filter traffic using PF to any degree you desire, and please set up spamd in greylisting mode (the default).

That will take care of most of your spam right there, and you could usefully have something like a spamasassin and clamav combo running in the delivery phase on your real mail server.

Useful references: Firewalling with OpenBSD's PF (tutorial)
The Book of PF
and Effective spam and malware countermeasures: Network noise reduction using free tools

And yes, I've blogged a bit about this too, over at my blog

Subject says it all, really. The best approach is to set up an OpenBSD machine as your gateway, filter traffic using PF to any degree you desire, and please set up spamd in greylisting mode (the default).

That will take care of most of your spam right there, and you could usefully have something like a spamasassin and clamav combo running in the delivery phase on your real mail server.

Useful references: Firewalling with OpenBSD's PF (tutorial)
The Book of PF
and Effective spam and malware countermeasures: Network noise reduction using free tools

And yes, I've blogged a bit about this too, over at my blog

If you're already dealing with XML files, I would suggest that the main barrier to using a toolset such as DocBook (SGML or XML variants) should be gone already.

DocBook is excellent at enforcing proper structure and contains all the elements you need (really!) to write tech documentation.

Several high profile projects such as FreeBSD, KDE, GNOME and others use DocBook as their main doc format, as do I believe more tech companies than actually want to admit it. I maintain the PF tutorial at http://home.nuug.no/~peter/pf/ as DocBook SGML myself.

The tools most people use for DocBook are free (most likely just a few mouse clicks or commands away through your package system), but some proprietary/commercial tools are available too. The main reference is at docbook.org, it certainly would not hurt to check it out.

There is not now and will never be such a thing as 'guaranteed email delivery'. SMTP is a collaborative, best effort thing. Read the fine RFCs.

In practice, with the myriad spam fighting methods out there, and the fact that some of the companies which pay up for the service will at some time or other have some of their systems take over by spam sending robots, there *will* be legitimate reasons to not accept (and optionally tarpit) attempts at mail delivery from hosts or networks whose owners have paid up for the 'guaranteed delivery' scheme.

This is some of the stuff I was on about in my BSDCan paper (now accessible at http://home.nuug.no/~peter/malware-talk/silent-net work.pdf).

Now, of course it is legitimate to dream about a mail delivery system without SMTP's warts and wrinkles, but this is not it, and it is not going to help solve any real-world problem.

Intelectual Property SUX, say NO to IP!

Nice book on the subject:
http://levine.sscnet.ucla.edu/general/intellectual /against.htm

Nice speech (in english, despite how the page looks):
http://www.nuug.no/aktiviteter/20051117-p2p/

Missing on that list is "Snøfrix" (just in Norwegian), a Live-CD to introduce Linux to Norwegian school kids.

Snøfrix has gained quite some popularity recently, as quite a few libraries are now distributing Snøfrix, in addition to it being mentioned in the largest Norwegian TV channel (NRK), on a program dedicated to protecting consumers right -- this time comparing Linux to Windows.

The name is a mix of "Knoppix" upon which is it based, and "Snøfrix", the name of the 11 (or so) year old daughter of its creator, deciding what should be on the CD.

It recently won NUUG's (Norwegian Unix User Group) price for promotion of free software (only in Norwegian too :( ) as well.