[nSLUG] Security on dialup
George N. White III
gnwiii at gmail.com
Thu Feb 27 08:43:54 AST 2014
On Thu, Feb 27, 2014 at 2:01 AM, Mike Spencer <mspencer at tallships.ca> wrote:
> On 02/26/2014 02:56 AM, Mike Spencer wrote:
> > If I had an always-on high speed internet connection, there are
> > several things I'd have to change, I guess. As it is, one box is
> > episodically on the net by dial-up.
> To which Ben replied:
> ben> It's a game of percentages, isn't it? Always-on high speed
> ben> internet means more time for the attacker to attack you, but how
> ben> long, exactly, do you think it takes for an attack to succeed?
> Well, roughly, at least 100 times longer for me than for you. :-)
> The few attacks I've read about in detail involve a small piece of
> compromising code that then fetches a much larger chunk of code. With
> blinkenlights on my desk and 38K bps, "much larger" is (would be)
> at least potentially noticeable.
You mainly read about crude attacks that are easily detected. Someone
wanting to compromise lots of systems will use the smallest possible
payload to compromise a system, and stealthy measures to do the nasty
business (twiddle a few bytes in RAM for a TLS library so all https
are accepted, then sit back and collect passwords, logins, and acct nos.
a compromised router).
I do run iptables(8) on my dial-up box. For high-speed, always-on, I
> probably should do a more sophisticated job of configuring it. In the
> last hour, I've seen SYN probes from China on ports 25, 22, 23, 80 and
> 8088 and one on port 22 from India that were successfully
> ignored. ("Seen" because I often leave tcpdump running in a window
> that peeks out from behind other windows, where unexpected scrolling
> of data gets my attention better than the modem lights.)
> I also run a script in the background that checks several critical
> system files every few minutes and plays a loud audible alarm if one
> of them changes. It goes off every afternoon when cron does log rotate.
There are lots of critical files, so this may not be effective use of
> Although fans of fancy interactive sites would see it as a sort of
> sacrifice, I rarely do anything that involves js or Java and don't
> auto-run any code. Attachments in email are manually unpacked.
> ben> I think an admin on a system connected via dialup should be every
> ben> bit as careful about security as one on high speed Internet.
> Yes, of course. I think the threat is lower. I'm probably more
> concerned about mass surveillance than intrusion. (Email packets to my
> wife, who is physically in the next room, go through the US and are
> subject to collection & scrutiny as "foreign" communication.)
The threat is not much different. A few attackers may ignore dialup,
but the real difference is that you will find it hard to miss a low-rent
script kiddy attack that does use large payloads. You are more
vulnerable to denial of service attacks using amplification if you
happen to piss off the wrong people (and members of certain groups/
organizations have been targeted en mass by baddies who disliked
Don't assume it is just the US where IP data are being snooped. US
origin data can be snooped by a "partner" country and information
shared with partners. The bad guys don't care where you live, and it is
safe to assume they have much the same data gathering capabilities
as NSA etc -- just more targeted at specific groups.
And, back to the original critique, I don't see how telnet between
> local boxen through a router that is not itself on the net is a
> potential risk. Perhaps I should.
In large organizations, people say "telnet is fine on the internal
network, then, out of habit, use telnet to connect to an external
site (or one called
The only system that is not at risk is the one that is never turned
on. If you make a habit of using less insecure tools you will
know how to configure and use them, be better able to
recognize anomalies, etc.
George N. White III <aa056 at chebucto.ns.ca>
Head of St. Margarets Bay, Nova Scotia
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the nSLUG