Prev: FBSD 8.10 And VirtualBox 3.1
Next: Point-to-point link without PPP on freebsd? Is it possible?
From: John J. Rushford on 1 Jan 2010 13:33
Frank Merlott wrote:
> On Wed, 23 Dec 2009 02:28:42 +0100, Moe Trin
> <ibuprofin(a)painkiller.example.tld.invalid> wrote:
>
>> On Tue, 22 Dec 2009, in the Usenet newsgroup
>> comp.unix.bsd.freebsd.misc, in
>> article <hgpl6a$rp7$1(a)news.albasani.net>, bob prohaska's usenet
>> account wrote:
>>
>>> I've tried news.albasani.net and news.eternal-september.org, the
>>> former seems to work well. Didn't have much luck (nor try very hard)
>>> with the latter.
>>
>> A quick glance through my news spool suggests eternal-september.org
>> may be more popular, but popularity is a personal opinion only.
>>
>
> I am posting this through eternal-september and so far so good. I have been
> with them for a month, no downtime, great wide range of groups and great
> support
> at their own eternal-september.moderated group. SSL supported and
> posting IP is
> concealed.
>
>

Thanks for the suggestion, I am now using eternal-september.

John
From: John J. Rushford on 1 Jan 2010 14:07
Moe Trin wrote:
> On Mon, 21 Dec 2009, in the Usenet newsgroup comp.unix.bsd.freebsd.misc, in
> article <aaa47b0c-7ac7-4828-a906-598f3b9e3cfc(a)v30g2000yqm.googlegroups.com>,
> John Rushford wrote:
>
> NOTE: Posting from groups.google.com (or some web-forums) dramatically
> reduces the chance of your post being seen. Find a real news server.
>
>> Moe Trin) wrote:
>
>>> Why are you allowing everywhere else? World traveler who might be
>>> in Kazakhstan, Kenya, Kiribati, Korea, or Kuwait tomorrow?
>
>> I do travel, I spent 3 weeks in the Philippines the summer before
>> last building homes with a church group in one of the provinces.
>
> That was what - 15 months ago?
>
>> It was handy to ssh into my mail server when I could get an internet
>> connection. I had asterisk running on it back then and used it to
>> make phone calls to relatives in the states.
>
> "World travelers" are better suited using a crude port knocking
> technique. I'm _not_ referring to quickie connection attempts to 5
> to 10 different ports in a given sequence, and using that as the
> authentication _replacement_ scheme. Rather, make a single attempt
> to some _unused_ (meaning closed) port such as 70/tcp, 113/tcp or
> similar. The firewall notes the (failed) connection attempt, and opens
> the port where the SSH server lives for a one minute period for the
> address that tried to connect. The remote has a minute to connect
> and the "established" rule then holds the port open for that
> "conversation". You mention using a port blocker thingy that's a
> perl script - you can do the same thing by just causing the script
> to monitor the logs for connection attempts to your secret port and
> making the temporary firewall rule change. This isn't "security
> through obscurity" because when the port opens, you still have to
> supply the existing login and authentication tokens. All this is
> doing is dramatically reducing the number of people able to access
> the SSH server to run dictionary attacks by adding an additional hoop
> to jump through. The concept isn't new - I worked at a place that
> used this technique to protect their "telnet" server, which might
> give a clue that it was close to twenty years ago.
>
> The reason I do not recommend complicated port knocking sequences is
> that they are a pain to set up, and those secret ports that you may
> want to use may be blocked by the firewall at the site you are trying
> to connect from. An example is port 25/tcp - smart providers block
> users trying to connect to that port on systems OUTSIDE of their net
> in an attempt to prevent being abused by spammers and causing the ISP
> to wind up on one or more DNSbl. If you as a customer want to send
> mail, you forward it to the local ISPs mail or mail-submission server,
> and they do the forwarding to the eventual destination (sendmail calls
> it "smarthost"). Some providers block direct web access, preferring
> you to connect through their proxy (for any number of reasons) as
> another example of blocked ports.
>
> Words to live by: Don't overdo it - it's your foot you're shooting.
>
>> So what to allow and what to block.....
>
> The standard answer is to block address ranges that you don't have
> a reason to think you will need to use in the immediate future. 15
> months is not "immediate".
>
>> Currently, I have about 2300 blocked IP's in the table and have been
>> watching it for a performance problem. Have not seen any problems
>> thus far. I may fiddle with the script and keep track of when the
>> rule was added and then have another script remove them after they've
>> aged for say an hour.
>
> That would work if you want to roll your own. There are a number of
> these tools around - most are some form of script. I don't bother
> using them, because my server only accepts connections from a limited
> number of addresses (and I do use the above style of port-knocking
> when traveling and not knowing the suitable addresses at the remote
> site).
>
>> As far as using google groups is concerned, its all I can find that's
>> free.
>
> The 'NOTE:' is automatically added by my news tool when ever I am
> replying to a post originating at google. The rational is that there
> is enough spam/abuse from that source that people set their news tool
> to filter off such posts - and filtered means not seen or read.
>
> google is a search engine. So how about an article posted to the
> Usenet newsgroup "news.software.readers" on 3 Oct 2008 12:12:05 -0700
> with Message-ID <qdWdnUqP5sgc83vVnZ2dnUVZ_s_inZ2d(a)earthlink.com>
> which lists a few, or hit the newsgroups "alt.free.newsservers" or
> "alt.comp.freeware". Here's an example snippet from one post:
>

You got me to thinking more about this so, after upgrading my server
to FreeBSD 8. I investigated and am now using the OpenBSD packet
filter which seems to be much more feature rich that ipfilter.

With my new pf rules, I'm able to rate limit connections and drop the
IP's into a table and can expire the entry after 24 hours based on
connection statistics. Table searches are O (log n) and limited to
200,000 in FreeBSD 8.

Still learning about pf, but so far its working out quite nicely.

John
From: Moe Trin on 2 Jan 2010 17:41
On Fri, 01 Jan 2010, in the Usenet newsgroup comp.unix.bsd.freebsd.misc, in
article <hhlh5c$rlf$1(a)news.eternal-september.org>, John J. Rushford wrote:

>Moe Trin wrote:

>> John Rushford wrote:

>>> So what to allow and what to block.....

>> The standard answer is to block address ranges that you don't have
>> a reason to think you will need to use in the immediate future.

>>> Currently, I have about 2300 blocked IP's in the table and have been
>>> watching it for a performance problem. Have not seen any problems
>>> thus far. I may fiddle with the script and keep track of when the
>>> rule was added and then have another script remove them after they've
>>> aged for say an hour.

>> That would work if you want to roll your own. There are a number of
>> these tools around - most are some form of script.

>You got me to thinking more about this so, after upgrading my server
>to FreeBSD 8. I investigated and am now using the OpenBSD packet
>filter which seems to be much more feature rich that ipfilter.

We're talking about blocking IP addresses that failed SSH logins. As
noted, I prefer to limit access to address ranges and ports that I
know I'll be using. As a result, I don't see much in the way of brute
force attempts. They can't connect, and that means they can't attempt
the login. If I were concerned about the brute force attempts, I'd
_tend_ to go with a log reader application, and use that to install
temporary firewall rules, RATHER THAN blanket limiting connection
attempts. I feel that would give me finer control as I'm only going
to block failed attempts, rather than all attempts

>With my new pf rules, I'm able to rate limit connections and drop
>the IP's into a table and can expire the entry after 24 hours based
>on connection statistics. Table searches are O (log n) and limited
>to 200,000 in FreeBSD 8.

Blocking based on connection rates for 24 hours scares me - what
happens if those connections are legitimate and because of what I may
be using the connection for, may be frequent. I'm now blocked for 24
hours?

>Still learning about pf, but so far its working out quite nicely.

Glad to hear it! Try to keep the rules as simple yet broad as
practical.

Old guy
From: John J. Rushford on 3 Jan 2010 10:36
Moe Trin wrote:
> On Fri, 01 Jan 2010, in the Usenet newsgroup comp.unix.bsd.freebsd.misc, in
> article <hhlh5c$rlf$1(a)news.eternal-september.org>, John J. Rushford wrote:
>
>> Moe Trin wrote:
>
>>> John Rushford wrote:
>
>>>> So what to allow and what to block.....
>
>>> The standard answer is to block address ranges that you don't have
>>> a reason to think you will need to use in the immediate future.
>
>>>> Currently, I have about 2300 blocked IP's in the table and have been
>>>> watching it for a performance problem. Have not seen any problems
>>>> thus far. I may fiddle with the script and keep track of when the
>>>> rule was added and then have another script remove them after they've
>>>> aged for say an hour.
>
>>> That would work if you want to roll your own. There are a number of
>>> these tools around - most are some form of script.
>
>> You got me to thinking more about this so, after upgrading my server
>> to FreeBSD 8. I investigated and am now using the OpenBSD packet
>> filter which seems to be much more feature rich that ipfilter.
>
> We're talking about blocking IP addresses that failed SSH logins. As
> noted, I prefer to limit access to address ranges and ports that I
> know I'll be using. As a result, I don't see much in the way of brute
> force attempts. They can't connect, and that means they can't attempt
> the login. If I were concerned about the brute force attempts, I'd
> _tend_ to go with a log reader application, and use that to install
> temporary firewall rules, RATHER THAN blanket limiting connection
> attempts. I feel that would give me finer control as I'm only going
> to block failed attempts, rather than all attempts
>
>> With my new pf rules, I'm able to rate limit connections and drop
>> the IP's into a table and can expire the entry after 24 hours based
>> on connection statistics. Table searches are O (log n) and limited
>> to 200,000 in FreeBSD 8.
>
> Blocking based on connection rates for 24 hours scares me - what
> happens if those connections are legitimate and because of what I may
> be using the connection for, may be frequent. I'm now blocked for 24
> hours?
>

It's not a problem, the legitimate users know what the rules are.

John
First  |  Prev  | 
Pages: 1 2 3 4
Prev: FBSD 8.10 And VirtualBox 3.1
Next: Point-to-point link without PPP on freebsd? Is it possible?