I am using Debian loaded from DVDs so the following is not some Windows
update phenomenon.

Since I left college this summer, I no longer have access to the campus
Hi-speed Internet. So for now I am stuck on a rural dial up line that
somehow the phone company has limited to about 26k throughput. I am
trying to find out from the telco what is going on and why not 56k, but
for now I am watching the lights on an external modem and they are
revealing some stuff that I don't like.

I am not much of a telecommunications guru (read: not at all) but it would
appear that most of the traffic on my link is not mine. I realize that
there is a certain amount of handshaking on initial connect, and some may
be Firefox looking for updates (although I have turned off all of that I
can find). But there is a lot left over that I can't explain.

As an example... I was adding a couple of DVDs to my Netflix queue. It
seemed very slow, taking almost a minute between screens even with the
pictures turned off. Then I noticed the lights on the modem which
indicated a continual receive with an occasional send even after the page
was loaded and Firefox indicated "Done". It would continue for two
minutes or so. I went to google and the same thing happened.

Then I went through Firefox and turned off every update, feed and
automatic check I could find. Made no difference. So I loaded Konqueror
and surfed with that and got the same results - an unasked for receipt of
something that is minutes long and that happens at random intervals of
about 2 to 5 minutes.

Next I logged off and dialed back in with no browser at all. I should
have just talked to the ISP hardware and then dropped into a passive mode
with an occasional keep alive blip. But sure enough, in about 20 seconds
in comes a 3 minute continuous receive.

The above post indicates two problems. Something is stealing a bunch of
what little bandwidth I have, and (I think) somebody is talking to me
unasked. This would never be noticed on a broadband link unless someone
was running some kind of trace.

What is the easist way to determine what is incoming on an Internet
connection? I know that I could learn Snort or such like, but I am just
starting my first career and there isn't a whole lot of time left for
playing. A Linux utility of some kind, maybe?

Thanx any
Tom

Am Wed, 16 Jul 2008 21:46:16 -0500 schrieb Tom Wyley:

> Next I logged off and dialed back in with no browser at all. I should
> have just talked to the ISP hardware and then dropped into a passive mode
> with an occasional keep alive blip. But sure enough, in about 20 seconds
> in comes a 3 minute continuous receive.

keepalive? (your isp drops the connection after a while)

> The above post indicates two problems. Something is stealing a bunch of
> what little bandwidth I have, and (I think) somebody is talking to me
> unasked. This would never be noticed on a broadband link unless someone
> was running some kind of trace.

Usually you'll have a p2p connection, so you don't get other packets
except the packet ist for you.

> What is the easist way to determine what is incoming on an Internet
> connection? I know that I could learn Snort or such like, but I am just
> starting my first career and there isn't a whole lot of time left for
> playing. A Linux utility of some kind, maybe?
>
> Thanx any
> Tom


Snort is an ids an sniffer like tcpdump, wireshark etc. is what you are
looking for.

cheers

Tom Wyley <twxxxxxx@hooya.com> wrote:
> I am using Debian loaded from DVDs so the following is not some Windows
> update phenomenon.

> Since I left college this summer, I no longer have access to the campus
> Hi-speed Internet. So for now I am stuck on a rural dial up line that
> somehow the phone company has limited to about 26k throughput. I am
> trying to find out from the telco what is going on and why not 56k, but

You may have to accept 26k in a rural area since modems negotiate speed
and long phone lines to the ISP will limit what speed can be negotiated.
But the particular modem or modem configuration can also limit speed.
So it's a good idea to learn all you can about the modem to make sure
the configuration is the best it can be.

You won't get 56k in the U.S., all I've ever gotten is 50667 bps and
that's a rare exception, most of the time it's 48000 or 49999 bps.
And there's a FCC limit of 53kbps, if I remember correctly.

> for now I am watching the lights on an external modem and they are
> revealing some stuff that I don't like.

....

> Next I logged off and dialed back in with no browser at all. I should
> have just talked to the ISP hardware and then dropped into a passive mode
> with an occasional keep alive blip. But sure enough, in about 20 seconds
> in comes a 3 minute continuous receive.

> The above post indicates two problems. Something is stealing a bunch of
> what little bandwidth I have, and (I think) somebody is talking to me
> unasked. This would never be noticed on a broadband link unless someone
> was running some kind of trace.

If there is an Internet connection there will be kiddies trying to break
into it and cause trouble. Even on a PPP connection a firewall is a good
idea.

> What is the easist way to determine what is incoming on an Internet
> connection? I know that I could learn Snort or such like, but I am just
> starting my first career and there isn't a whole lot of time left for
> playing. A Linux utility of some kind, maybe?

This dumps traffic on ppp0 to standard output:
tcpdump -v -i ppp0

This dumps traffic without DNS lookup for the IP addresses:
tcpdump -vn -i ppp0

There will be a lot of output over 3 minutes in either case, most
of which won't be of much more value than what you see in 3 seconds.
There will be a learning curve. I don't know what, if any, GUI traffic
sniffing tools are available.

> Thanx any
> Tom

--
Clifford Kite
/* Speak softly and carry a +6 two-handed sword. */

On Wed, 16 Jul 2008, in the Usenet newsgroup comp.os.linux.networking, in
article <KY2dnepobYPlL-PVnZ2dnUVZ_gednZ2d@oco.net>, Tom Wyley wrote:

>So for now I am stuck on a rural dial up line that somehow the phone
>company has limited to about 26k throughput. I am trying to find out
>from the telco what is going on and why not 56k, but for now I am
>watching the lights on an external modem and they are revealing some
>stuff that I don't like.

1. Are you using the "correct" init-string according to the manufacturer
of your un-named modem?
2. "rural dial up" suggests you are some distance from town - how noisy
is the phone line? 56K (and indeed anything over about 26K tends to
want to see a "clean" phone line - 26-33.6K is almost harder than 37-56K
on a noisier line.
3. Looking at modem lights isn't as informative as looking at the actual
data transfers.

>I am not much of a telecommunications guru (read: not at all) but it
>would appear that most of the traffic on my link is not mine.

You're possibly seeing windoze "messenger spam" (UDP to ports 1025-1035)
but that should be relatively light. OTHER THAN THAT, your connection
is a point-to-point link, and the only traffic on that link is to/from
your computer.

>I realize that there is a certain amount of handshaking on initial
>connect, and some may be Firefox looking for updates (although I have
>turned off all of that I can find). But there is a lot left over that
>I can't explain.

Let's start by not using a browser. Most browsers are happy to try to
load every piece of eye-candy and other crap. What traffic do you see
when the browser isn't running?

>Next I logged off and dialed back in with no browser at all. I should
>have just talked to the ISP hardware and then dropped into a passive mode
>with an occasional keep alive blip. But sure enough, in about 20 seconds
>in comes a 3 minute continuous receive.

Figure out where the command line is, and run 'netstat -anptu' and see
what is talking to what. See the man page for netstat so you understand
what it's telling you.

>The above post indicates two problems. Something is stealing a bunch of
>what little bandwidth I have, and (I think) somebody is talking to me
>unasked. This would never be noticed on a broadband link unless someone
>was running some kind of trace.

Depending on what all you installed, there shouldn't be that much open
for "others" to connect to you. Nearly all of that traffic is _probably_
due to client things you are running - but you won't know that until
you find out what the traffic is. Most people install all kinds of
extra trash that they think might be interesting, and don't know what
it's actually doing.

>What is the easist way to determine what is incoming on an Internet
>connection?

[compton ~]$ netstat -anptu
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 8972/sshd
[compton ~]$

Doesn't really tell you, but the firewall is only accepting connections
from two ranges totalling 1500 addresses (a /22 and two /24s).

>I know that I could learn Snort or such like, but I am just starting my
>first career and there isn't a whole lot of time left for playing.

-rw-rw-r-- 1 gferg ldp 155096 Jan 23 2004 Security-HOWTO
-rw-rw-r-- 1 gferg ldp 278012 Jul 23 2002 Security-Quickstart-HOWTO

Should be on your system in /usr/share/HOWTO (or use your favorite search
engine) - and there are a number of other good ones.

Old guy

O
> You may have to accept 26k in a rural area since modems negotiate speed
> and long phone lines to the ISP will limit what speed can be negotiated.
> But the particular modem or modem configuration can also limit speed.
> So it's a good idea to learn all you can about the modem to make sure
> the configuration is the best it can be.
>
>

As it turns out, the Telco has put "combiners" on the lines to get two
customers on one piece of copper. So I will never get over 26k from here.

Tome

>
> 1. Are you using the "correct" init-string according to the manufacturer
> of your un-named modem?
> 2. "rural dial up" suggests you are some distance from town - how noisy
> is the phone line? 56K (and indeed anything over about 26K tends to
> want to see a "clean" phone line - 26-33.6K is almost harder than 37-56K
> on a noisier line.

I found today that the phone company has put combiners on the lines around
here so as to get two customers on one piece of copper. The bandwidth is
only 30k on each side.

> Let's start by not using a browser. Most browsers are happy to try to
> load every piece of eye-candy and other crap. What traffic do you see
> when the browser isn't running?
>
> Figure out where the command line is, and run 'netstat -anptu' and see
> what is talking to what. See the man page for netstat so you understand
> what it's telling you.
>
I can handle the command line ok but netstat is a big little program so I
am RTFMing to figure it out. Looks to be about a zillion combinations of
options.

> Depending on what all you installed, there shouldn't be that much open
> for "others" to connect to you. Nearly all of that traffic is _probably_
> due to client things you are running - but you won't know that until you
> find out what the traffic is. Most people install all kinds of extra
> trash that they think might be interesting, and don't know what it's
> actually doing.

This is just a basic Debian install with stuff for a programmer (C, Perl,
Tk, Mysql, and so forth). Not much else. I have a Smoothwall box
between me and the modem with all ports except 80 and 441 closed. I can
see all the Windows trojan junk hitting me but nothing in the firewall
shows anything that I can corrilate to a 2 and 3 minute unrequested receive
package.

Like I said, what is happening probably also happens on broadband lines
also - it is just the speed of my line that makes it obvious.

Will check out netstat.

Thanks
Tom

On Thu, 17 Jul 2008, in the Usenet newsgroup comp.os.linux.networking, in
article <5IudndO9Xp7Nf-LVnZ2dnUVZ_iydnZ2d@oco.net>, Tom Wyley wrote:

>I found today that the phone company has put combiners on the lines
>around here so as to get two customers on one piece of copper. The
>bandwidth is only 30k on each side.

Phone companies are only required to provide a "voice grade" type of
connection, which can be pretty horrible. Modems use a modulation
scheme called trellis modulation using fixed frequencies - the
information being carried as a combination of amplitude and carrier
phase changes. This is what allows a "56k" connection to go over a
wire that only carries 300 to 3000 Hertz voice.

>I can handle the command line ok but netstat is a big little program
>so I am RTFMing to figure it out. Looks to be about a zillion
>combinations of options.

The one you are interested in is 'netstat -anptu' which shows
all connections (-a), using numbers (-n) rather than hostnames,
displays the process name/ID that "owns" the connection on "this" end
(-p) and shows TCP (-t) and UDP (-u) connections. This will tell you
what process/program is using the connection. You can then isolate
that process/program to see what started it by using the 'ps'
command - specifically 'ps afuwx' and looking for the problem ID
and/or program name. Note that both commands are a 'snapshot' of
what is happening when you press the Enter key - neither knows about
what recently happened, or what may happen later. They only know about
"right now".

>This is just a basic Debian install with stuff for a programmer (C,
>Perl, Tk, Mysql, and so forth). Not much else. I have a Smoothwall
>box between me and the modem with all ports except 80 and 441 closed.
>I can see all the Windows trojan junk hitting me but nothing in the
>firewall shows anything that I can corrilate to a 2 and 3 minute
>unrequested receive package.

441 is a bit unusual - are you sure you don't mean 443? Assuming
those are closed to _inbound_ packets (or are you running a web server
that everyone is trying to access), it's most likely some traffic in
response to that which you are generating. If all you are running is
client software (no servers), then you need not open/forward any
server ports. Your client uses a _random_ port number between 1025
and ~65000 on your end, and talks to remote servers on well known ports
like '80' for web-crap, '443' for secure web-crap, or 119 for Usenet.
The remote server talks back to you _from_ it's well known port _to_
that high random port number. If you aren't running a server, ports 0
to 1024 on your side should not be in use.

You'll probably find that you have some "helper" programs running to get
automatic updates, check the mail, news, and who knows what else. If
you are not running a server, then any attempt by a remote system to
connect to you will be ended with one packet:

Remote_system:port_$NUMBER -> Your_system:port_$FOO "Hello"
Your_system:port_$FOO -> Remote_system:port_$NUMBER "No one here"

That's it - maybe 40-70 bytes in each direction, and the connection is
ended. If there is no server, then the only traffic will be in response
to something your system initiated.

Your_system:port_$NUMBER -> Remote_system:port_$BAR "Hello"
Remote_system:port_$BAR -> Your_system:port_$NUMBER "Hi - what?"
Your_system:port_$NUMBER -> Remote_system:port_$BAR "Good to see you"
Your_system:port_$NUMBER -> Remote_system:port_$BAR "Send me $CRAP"
Remote_system:port_$BAR -> Your_system:port_$NUMBER "Here it comes!!!"
and away we go, with three tons of what-ever it was that you asked
them for. (Yes, this is a bit simplified, but the concept is accurate.)

Bottom line - no servers on your end means only a tiny blip of traffic
as your computer tells the remote "I'm sorry, but the number you dialed
is not in service - CLICK!". If there _is_ a server, you have to figure
out what ('netstat' will tell you that) and why ('ps' will help there).
If there is traffic, but you aren't running any servers (netstat shows
no port "LISTENING"), then it's something you asked for, and the
'netstat' and 'ps' commands should be able to help you find it.

>Like I said, what is happening probably also happens on broadband lines
>also - it is just the speed of my line that makes it obvious.

That's where those HOWTOs come in handy.

Old guy

On 2008-07-18, Moe Trin <ibuprofin@painkiller.example.tld> wrote:
> On Thu, 17 Jul 2008, in the Usenet newsgroup comp.os.linux.networking, in
> article <5IudndO9Xp7Nf-LVnZ2dnUVZ_iydnZ2d@oco.net>, Tom Wyley wrote:
>
> ...
>
> That's it - maybe 40-70 bytes in each direction, and the connection is
> ended. If there is no server, then the only traffic will be in response
> to something your system initiated.
>
> Your_system:port_$NUMBER -> Remote_system:port_$BAR "Hello"
> Remote_system:port_$BAR -> Your_system:port_$NUMBER "Hi - what?"
> Your_system:port_$NUMBER -> Remote_system:port_$BAR "Good to see you"
> Your_system:port_$NUMBER -> Remote_system:port_$BAR "Send me $CRAP"
> Remote_system:port_$BAR -> Your_system:port_$NUMBER "Here it comes!!!"
> and away we go, with three tons of what-ever it was that you asked
> them for. (Yes, this is a bit simplified, but the concept is accurate.)
>
> Bottom line - no servers on your end means only a tiny blip of traffic
> as your computer tells the remote "I'm sorry, but the number you dialed
> is not in service - CLICK!". If there _is_ a server, you have to figure

Cannot a firewall be configured to simply ignore any incoming requests,
so that there would be no response at all, instead of saying the
equivalent of "not in service"?


--

On Sat, 19 Jul 2008, in the Usenet newsgroup comp.os.linux.networking, in
article <slrng828c1.ajo.allergic-to-spam@no-spam-allowed.invalid>,
Jim Cochrane wrote:

>Moe Trin <ibuprofin@painkiller.example.tld> wrote:

>> Bottom line - no servers on your end means only a tiny blip of traffic
>> as your computer tells the remote "I'm sorry, but the number you dialed
>> is not in service - CLICK!".

>Cannot a firewall be configured to simply ignore any incoming requests,
>so that there would be no response at all, instead of saying the
>equivalent of "not in service"?

In addition to the regular HOWTOs from then LDP, see

http://www.netfilter.org/documentation/HOWTO/

That's the "default" result when using 'iptables' "DROP" rule. To have
the firewall reject with an ICMP Type 3 Code 3 (Port Unreachable) or
similar, you have to provide an extra rule of "REJECT with". In most
cases, you provide a "default" rule which would be a DROP, but you can
also forward it to an unused port, and have that port provide the
"normal" RST flagged TCP packet.

There is a huge debate of whether it's better to provide no response
verses the RST or ICMP 3,3. Some feel this makes their computer
invisible, neglecting to note that were their computer non-existent,
the upstream router would normally provide an ICMP Type 3 Code 1 (Host
Unreachable). I've actually seen idiots who configured their firewall
to mimic the 'Host Unreachable' response - I say 'idiots' because the
resulting ICMP error comes from the IP address that is supposedly
unreachable. The lack of response causes the remote computer to make
additional tries - so you aren't saving any bandwidth by silently
discarding unwanted packets. As far as the bad guys are concerned, the
lack of response confirms that the computer does exist, is reachable,
and is using some form of firewall. This _MAY_ attract more attention
compared to the effect of a more normal RST or ICMP 3,3. Your choice.

Others think that by not responding to unwanted packets, they can hide
information about their computer, such as operating system type and
version. See the documentation that comes with the popular 'nmap' tool

[compton ~]$ whatis nmap
nmap (1) - Network exploration tool and security scanner
[compton ~]$

for considerably more details on this technique, and some simple means
of defeating such probes.

There is one situation when it _IS_ desirable to ignore unwanted
packets. This is the case for UDP. Messenger spam (usually messages
that appear to be windoze warning messages, directed to UDP ports 1025
to 1030 or so) are often using spoofed source addresses. Looking at the
IP headers of such packets, there are usually some glaringly obvious
indications that the source is spoofed (such as using IP addresses that
haven't been released by IANA - see that one fairly often). This means
that there is no reason to send a FOAD packet to a non-existent or
innocent host that had nothing to do with the UDP spam.

Finally, there is a case where dropping packets causes you problems.
The most common problem is 'identd' or 'auth' on tcp/113. You connect
to a remote system, and it sends a query to this port - basically
asking "who is your user who is connecting to my port <mumble>?". It
waits until it gets an answer - either a response from the identd that
is running on your system, or a port rejection from the network stack
because you aren't running identd. If you DROP these packets, rather
than rejecting or answering them, you have to wait ten to thirty
seconds for the remote client to time out before your desired
connection goes through. I see this on a number of servers I connect
to on a regular basis. My solution is to have a special rule for
these known servers to this specific port.

The gotcha if you are silently discarding unwanted packets is that you
have to do so for all 65536 ports and all 256 possible protocols (there
is more to the world of IP than TCP, UDP, and ICMP). See the 'nmap'
documentation for a lot more details and concepts.

Old guy

> Phone companies are only required to provide a "voice grade" type of
> connection, which can be pretty horrible. Modems use a modulation

Yep. Well so much for that. I don't have the time, money or political
connections to make the Telco change anything. Fortunately my use of
dialup is only for the summer. However, the inquiry led me to a many
years old local newspaper investigation (way back when most people were on
dialup) about a sudden drop in everyone's connection speed. Apparently the
Telco was massively installing these combiner things all over the area.
The reporter was told that nobody at the phone company was authorized
to give any info or comment on the matter.

>
> The one you are interested in is 'netstat -anptu' which shows all
> connections (-a), using numbers (-n) rather than hostnames, displays the
> process name/ID that "owns" the connection on "this" end (-p) and shows

Netstat gives a ton of info. So far I am still just playing with it and
not trying to trap anything real, but I did see one 2 minute session to
data.coremetrics.com after my dialup connect and before I did anything.
Still googling for who or what they are.

>
> 441 is a bit unusual - are you sure you don't mean 443? Assuming those

Yep. It is 441. It was the default port that Smoothwall gave for
connection so I had no reason to change it. No server on this end -
well, actually there are 3 local servers, but none that ever see the
Internet.
>
You'll probably find that you have some "helper" programs running to get
> automatic updates, check the mail, news, and who knows what else. If you
> are not running a server, then any attempt by a remote system to connect
> to you will be ended with one packet:
>

I don't think so. When I install Debian, I do it from scratch, apt by apt
rather than use a canned version. Just the kernel and enough stuff to be
able to access the machine and then just the packag(es) I need. I make
sure that nothing like exim or rsync has been installed without my knowing
it. This isn't to say that there absolutely isn't some rogue package
connecting with somebody, but I see no evidence of it, yet.

Thanks for all the info.

Tom