Roundtable

roundtable@muug.ca

2555 discussions

Shaw packet loss
by John Lange 19 Oct '10

19 Oct '10

Just wondering if anyone else has noticed that Shaw seems to be having systemic problems with their network? I've run tests from several different locations and all of them seem to show significant intermittent packet loss to the first hop (gateway). It comes and goes and some days are worse than others but it is persistent. -- John Lange www.johnlange.ca

5 16

MUUG board election results
by Gilbert E. Detillieux 13 Oct '10

13 Oct '10

The ballots were collected and the votes counted at last night's MUUG general meeting, and here (for the sake of those who couldn't be there in person) are the results. Your board for the 2010-2011 year will be... Sean Cody Trevor Cordes Gilbert Detillieux Michael Doob Robert Keizer Katherine Scrupa Doug Shewfelt Adam Thompson A big "thank you" to all the nominees who let their names stand for election, and an even bigger thanks to Kevin McGregor and Montana Quiring, who resigned from the board this year after many years of valuable service to the group. -- Gilbert E. Detillieux E-mail: <gedetil(a)muug.mb.ca> Manitoba UNIX User Group Web: http://www.muug.mb.ca/ PO Box 130 St-Boniface Phone: (204)474-8161 Winnipeg MB CANADA R2H 3B4 Fax: (204)474-7609

1 0

MUUG Meeting, Oct 12, 7:30pm -- The Wireless Neighbourhood
by gedetil＠cs.umanitoba.ca 05 Oct '10

05 Oct '10

The Manitoba UNIX User Group (MUUG) will be holding its next monthly meeting on Tuesday, October 12. The meeting topic for this month is as follows: The Wireless Neighbourhood Over three years ago, neighbours and MUUG members Kevin McGregor and Kelly Leveille thought they had some cool ideas for data sharing that would work well via a direct link between their homes. They had briefly experimented with using their broadband Internet connection, but they were disappointed by the asymmetric connection speeds. This month, Kelly and Kevin will discuss the hardware, firmware, topology, trials and tribulations, configuration and eventual successful implementation of their private, wireless-connected network. With pictures, and demo-free! Plus, this month's meeting is the MUUG annual general meeting, which will include the election of the MUUG board of directors for the 2010-2011 year. You must be a MUUG member in good standing, and be present at the meeting, in order to vote. The group holds its general meetings at 7:30pm on the second Tuesday of every month from September to June. (There are no meetings in July and August.) Meetings are open to the general public; you don't have to be a MUUG member to attend. ********************************************************************** Please note our meeting location: The IBM offices, at 400 Ellice Ave. (between Edmonton and Kennedy). When you arrive, you will have to sign in at the reception desk, and then wait for someone to take you (in groups) to the meeting room. Please try to arrive by about 7:15pm, so the meeting can start promptly at 7:30pm. Don't be late, or you may not get in. (But don't come too early either, since security may not be there to let you in before 7:15 or so.) Non-members may be required to show photo ID at the security desk. Limited parking is available for free on the street, either on Ellice Ave. or on some of the intersecting streets. Indoor parking is also available nearby, at Portage Place, for $5.00 for the evening. Bicycle parking is available in a bike rack under video surveillance located behind the building on Webb Place. ********************************************************************** For more information about MUUG, and its monthly meetings, check out their Web server: http://www.muug.mb.ca/ Help us promote this month's meeting, by putting this poster up on your workplace bulletin board or other suitable public message board: http://www.muug.mb.ca/meetings/MUUGmeeting.pdf -- Gilbert E. Detillieux E-mail: <gedetil(a)muug.mb.ca> Manitoba UNIX User Group Web: http://www.muug.mb.ca/ PO Box 130 St-Boniface Phone: (204)474-8161 Winnipeg MB CANADA R2H 3B4 Fax: (204)474-7609

1 0

Re: [RndTbl] ssh host checking
by Trevor Cordes 01 Oct '10

01 Oct '10

On 2010-09-10 Sean Walberg wrote: > Hey Trevor, > > If you're connecting with a password to a compromised box or > otherwise being hit with an MITM attack, you'll give up your > password. If you're connecting to the same server with a key, you > won't compromise your key because the private key isn't sent over the > channel. It's only used to decrypt a challenge encrypted by the > public key. Thanks for the response, sorry for my delay I haven't had time to deal with this again until now. I'm using rsa & dsa keys to login. No passwords. > In both cases, the data channel will also be visible to the attacker. Oops, that would be bad. > The .ssh/known hosts file will work on hostnames, so I'm not sure why > a change in IP is flagging the host key checks because the key > shouldn't change. Hmm, my known hosts file is almost all IP's (no hostnames) even though I'm pretty sure I'm connecting with hostnames. The DNS is all dynamic DNS so the hostname->IP mapping changes a lot (for DSL anyhow). Maybe I'll look into getting ssh to use hostnames, not IPs, in knownhosts. Unless, perhaps it is using IPs when it is finding duplicate hostname/IP tuples. Your thought about the key was my thought exactly. I'm not sure why it even needs the tuple at all. Why not just store the key and say "this key is good no matter the IP/hostname". > One alternative that might be a good middle ground would be to run > with both parameters set to "yes". If an event happens, the ssh will > fail. You could then run some checks to make sure things are OK Not good for my automated script. It's mission-critical and I would be bugged several times a day probably (I hate MTS DSL...) with failures. I really need to FaF. > ($old_ip != $new_ip) and then do a token "ssh $hostname -o > StrictHostKeyChecking=no -o CheckHostIP=no /bin/false " which would > be enough to save the key on your management station. Re-try the ssh > with full security. Log the event somewhere. Hmm, perhaps using expect or something to automatically interface with ssh and check the fingerprint when things fail might be a solution. You've given me some good ideas. > I did something similar in the EC2 environment, but I could guarantee > the IP address was new so there might be some tweaking needed if you > stomp on a previously known IP. Perhaps I could make a script to associate dates with IPs and delete any old ones, or any where it can determine the IP was the last one used by a certain host. > There also might be options outside of SSH but that would depend on > what you're trying to do. Sounds like the only options will be outside of ssh :-( Not ideal, but certainly doable. > On Fri, Sep 10, 2010 at 3:09 AM, Trevor Cordes <trevor(a)tecnopolis.ca> > wrote: > > > What security will I lose by using ssh with: > > -o StrictHostKeyChecking=no -o CheckHostIP=no > > ? > > > > I have a script that connects automatically to dozens of linux > > boxen (that I control) on the internet using dsa/rsa keys. Many of > > these are on MTS DSL and so change their IP's frequently (often > > many times a week). They all have dynamic dns setup so I can > > always access them via a DNS domain name (rather than IP). > > > > If I use the ssh defaults of StrictHostKeyChecking=ask and > > CheckHostIP=yes, it mostly works as expected, but sometimes my > > script will hang with ssh waiting for tty input with the usual: > > > > The authenticity of host 'foo.com (141.162.215.81)' can't be > > established. Are you sure you want to continue connecting (yes/no)? > > > > I don't mind this for new boxes where I haven't confirmed the > > fingerprint yet, but for existing boxes where the IP has changed, > > it sometimes gives me grief. I can't recall all the particular > > instances, but the one that just hit me was one of my MTS boxes > > cycled onto an IP that was previously used by a different box! > > Seems rather unlikely, but with DSL hanging up all the time, it's > > bound to happen. I see no way around this occurrence except to use > > the above -o options to disable all checks. > > > > So what attacks am I really opening myseful up to with those > > settings? Is the worst case that a MitM captures my commands? Or > > is the worst case that they gain my password/key and access to the > > remote system? > > > > What else? > > > > It sure would be nice if I could, on my local box, install a key or > > something from each of the remote boxen and say that I never care > > about what IP it has at the moment, just check the key and be happy > > & secure. > > > > For all scenarios assume local + remote boxes have not been > > compromised.

1 0

SIP for business
by Montana Quiring 01 Oct '10

01 Oct '10

Hello, Any suggestions for a decent SIP provider in Canada. I want a Winnipeg phone number to use for business calls, but I want it to be VOIP with a soft phone client option. I want people to be able to call this phone number from their land line/mobile phone. I would like the softphone client to be non proprietary (multi-platform). I don't want to run an Asterisk server in my basement (at this point). ;) I want it to be reliable. -Montana Blog and Aggregation Site: http://montanaquiring.info iPhone/Touch Apps I have bought: http://appshopper.com/feed/user/antikx/myapps

4 5

RTFM brainstorm.
by Sean Cody 28 Sep '10

28 Sep '10

We are quickly powering through our current RTFM pool. Since the point of the exercise is to educate the group it seems only reasonable to find out what commands/systems the group would like to hear about? That being said, is there any command/system you were always curious about but haven't found time to investigate? What about a command you are using but you are unsure if you are getting the full potential out of it? Any particular command you enjoy using that you think other people could benefit from? Let us know and we'll add it to the pool. -- Sean P.S. While we would really like members to present RTFM, just giving us an idea of the things you want to learn about will help a lot.

8 13

Re: [RndTbl] RTFM brainstorm.
by Adam Thompson 28 Sep '10

28 Sep '10

Ooh, I'd love to get *any* insight into what autotools does. OTOH, that could easily fly right over everyone's heads at the meeting (including mine)... Thoughts on that, anyone? I certainly would second doing an RTFM bit on fink(1) (or is it (8)?). Any serious MacOS user (IMHO) eventually winds up needing one of those projects for *something* or other. And another hat to throw into the ring: make(1). -Adam ------Original Message------ From: O'Gorman, Peter Sender: roundtable-bounces(a)muug.mb.ca To: Roundtable, MUUG Cc: Pfaiffer, Mike ReplyTo: Roundtable, MUUG Subject: Re: [RndTbl] RTFM brainstorm. Sent: Sep 27, 2010 21:17 On 09/27/2010 07:26 PM, Mike Pfaiffer wrote: > > Speaking of Mac stuff (this ought to interest you and Lindsay)... Since > it came up in an earlier conversation, it might be useful to have a > presentation on MacPorts, Fink, etc.. I've used it a couple of times > successfully and once unsuccessfully. No doubt there are some > features/tweaks we don't know about. ;-) I could do something on this (I was one of the project leads for the Fink project for a few years and have a fair knowledge of MacPorts). Alternatively, I could do something quick on the autotools (also known as autocrap), if there is interest in that. Peter _______________________________________________ Roundtable mailing list Roundtable(a)muug.mb.ca http://www.muug.mb.ca/mailman/listinfo/roundtable

3 2

Last day for nominations!
by Adam Thompson 28 Sep '10

28 Sep '10

Reminder - today is the last day for nominations to the Board! If you don't have your nominations papers in by midnight, you cannot stand for election at the AGM next month. (N.B. Historically, the Elections Committee has accepted electronic notices of nomination, provided the signed paper copy is forwarded to us promptly. So if you'd like to stand for election, get ONE OTHER CURRENT MEMBER to nominate you ASAP!) -Adam Thompson athompso(a)muug.mb.ca athompso(a)athompso.net (204) 291-7950 [if you have any last-minute questions before midnight, I suppose]

1 0

Re: [RndTbl] Roundtable Digest, Vol 69, Issue 11
by Brock Wolfe 21 Sep '10

21 Sep '10

I prefer the DROP packet by IP ADDRESS solution. Simple and to the point. Worked really well for me on abusive crawlers from china and russia. 8-) Brock On 9/18/2010 12:00 PM, roundtable-request(a)muug.mb.ca wrote: > Send Roundtable mailing list submissions to > roundtable(a)muug.mb.ca > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.muug.mb.ca/mailman/listinfo/roundtable > or, via email, send a message with subject or body 'help' to > roundtable-request(a)muug.mb.ca > > You can reach the person managing the list at > roundtable-owner(a)muug.mb.ca > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Roundtable digest..." > > > Today's Topics: > > 1. slowing httpd access to cgi-bin scripts (Gilles Detillieux) > 2. Re: slowing httpd access to cgi-bin scripts > (Helgi Hrafn Gunnarsson) > 3. Re: slowing httpd access to cgi-bin scripts (Sean Walberg) > 4. Re: slowing httpd access to cgi-bin scripts (Tim Lavoie) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 17 Sep 2010 16:08:00 -0500 > From: Gilles Detillieux<grdetil(a)scrc.umanitoba.ca> > Subject: [RndTbl] slowing httpd access to cgi-bin scripts > To: MUUG Roundtable<roundtable(a)muug.mb.ca> > Message-ID:<4C93D8B0.2010708(a)scrc.umanitoba.ca> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Every once in a while, some doofus points a web crawler at our web site > and, ignoring the disallowed areas in our robots.txt file, starts > crawling through some of our cgi-bin scripts at a rate of 4 to 8 hits a > second. This is particularly annoying with some of the more processor > and disk intensive CGI programs, such as man2html, which also happens to > generate lots of links back to itself. > > Is there anything I can set up in Apache to throttle back and slow down > remote hosts when they start hitting hard on cgi-bin? I don't want to > do anything that would adversely affect legitimate users, nor make > important things like the manual pages hard to find by removing any > public links to them. But when a client starts making 10 or more GET > requests on /cgi-bin in a 5 second period, it would be nice if I could > get the server to progressively add longer and longer delays before > servicing these requests, to keep the load down and prevent the server > from thrashing. > > I'd appreciate any tips. > > Thanks, > Gilles >

3 2

slowing httpd access to cgi-bin scripts
by Gilles Detillieux 21 Sep '10

21 Sep '10

Every once in a while, some doofus points a web crawler at our web site and, ignoring the disallowed areas in our robots.txt file, starts crawling through some of our cgi-bin scripts at a rate of 4 to 8 hits a second. This is particularly annoying with some of the more processor and disk intensive CGI programs, such as man2html, which also happens to generate lots of links back to itself. Is there anything I can set up in Apache to throttle back and slow down remote hosts when they start hitting hard on cgi-bin? I don't want to do anything that would adversely affect legitimate users, nor make important things like the manual pages hard to find by removing any public links to them. But when a client starts making 10 or more GET requests on /cgi-bin in a 5 second period, it would be nice if I could get the server to progressively add longer and longer delays before servicing these requests, to keep the load down and prevent the server from thrashing. I'd appreciate any tips. Thanks, Gilles -- Gilles R. Detillieux E-mail: <grdetil(a)scrc.umanitoba.ca> Spinal Cord Research Centre WWW: http://www.scrc.umanitoba.ca/ Dept. Physiology, U. of Manitoba Winnipeg, MB R3E 0J9 (Canada)

4 4

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

Roundtable