Re: [PLUG] Reality check

[David]

On 11/20/2017 07:58 PM, Mke C> wrote:



On 11/20/2017 05:54 PM, plug-requ...@pdxlinux.org wrote:


-clip -


When the firewall receives an ICMP packet, ping and traceroute both will
show failure and/or lack of "up: state. If the attacker knows the 
device is

there by DNS resolution or IP address, they have a known target, and the
dropping of packets (IMO) is just obscuring things a little bit.


This is more of an ol' skool mentality that reflects a serious lack of a 
deeper understanding of networking and of being a good & useful netizen. 
In reality, we should actually see less and less of this over time as 
the ICMP protocol suite is very useful and blocking it doesn't amount to 
very much that's good and/or useful.


Coming from an admin background, you are correct that I don't have a 
deep understanding of networking. I am continually trying to learn from 
my mistakes, the input of others, and from readings that I can pick up.


I agree that ICMP is a useful too, and I am frustrated by the security 
group at $WORK that has disabled the return of these packets.



Other tools that you can try are telnet to the port for the service in
question, nmap to check for all open ports (potential for looking like an
attacker), and netcat (nc) to test for specific, or scan for all open,
ports.

A deeper way to search if things are connecting at all is the use of
netstat, Wireshark, or tcpdump in some cases.


I've been a network engineer for over a decade and I've learned to use 
the simplest tool possible for a task. In this case tcping is a very 
good simple and easy to use tool for anyone who's just wanting to test 
connectivity to network host. Most implementations allow for a port 
number to  be specified. If you're unsure of the port number from the 
Linux cli you can cat the /etc/services file to get a listing of udp & 
tcp ports w. description that's updated by IANA.


e.g.
~$ cat /etc/services
# Network services, Internet style
#
# Note that it is presently the policy of IANA to assign a single 
well-known port number for both TCP and UDP; hence, officially ports 
have two entries

# even if the protocol doesn't support UDP operations.
#
# Updated from http://www.iana.org/assignments/port-numbers and other 
sources like http://www.freebsd.org/cgi/cvsweb.cgi/src/etc/services .
# New ports will be added on request if they have been officially 
assigned by IANA and used in the real-world or are needed by a debian 
package.

# If you need a huge list of used numbers please install the nmap package.

tcpmux        1/tcp                # TCP port service multiplexer
echo        7/tcp
echo        7/udp
discard        9/tcp        sink null
discard        9/udp        sink null
systat        11/tcp        users

This particular implementation, 
https://www.elifulkerson.com/projects/tcping.php , provides a lot of 
HTTP mode options as well setting wait interval for a response, 
calculating jitter (variance in delay) and prefer ipv4 or ipv6.


Cool, a new tool to check out. Thank you for this information.

Network connectivity is going to likely become more problematic, and 
our means of testing things will likely become more restricted as time 
passes.

Just my guess, but it's a trend I have been noticing.


I don't follow nor subscribe to this logic at all. I expect network 
connectivity and ways to test to it to only get better as everyone and 
their grandparents demand well performing, highly reliable internet 
connectivity from all of their devices, everywhere. 5 years ago while 
working at an ISP in downtown Portland I had to work on networking 
problems from end-users of our ISP business partners who where 
complaining about high ping times in their favorite online game. And I'm 
talking about sub 150 ms round-trip ping times which is used as the 
measuring stick for toll quality VoIP.


My pessimism revolves around the increasing number of attacks by black 
hats (thinking of Mirai), human errors that impact large networks 
(recent Level 3 / Comcast routing issues), and the potential of the 
federal government trying to take away a level playing field.


It is my hope that the tools will get better and with it the willingness 
on the part of the major ISP players to provide more transparency and 
information real time as problems happen in the future.


> Also, consider that IPv6 provides improved QOS functionality, better
> security and faster routing on an end to end connection basis. As
> infrastructure gets re-designed and changed  out I only expect network
> connectivity to get less problematic with greater visibility into
> problems provided by better tools and information.

All good things for me to learn from and consider. IPv6 is not something 
that I have deep understanding of, and maybe now is the time to start 
looking at, and learning, it again.


dafr
___
PLUG mailing list
PLUG@pdxlinux.org
http://lists.pdxlinux.org/mailman/listinfo/plug

Re: [PLUG] Reality check

[Tomas Kuchta]

Not the original poster - BUT, thank you very much for such positive post
Mike.

... more or these please ... and Knipex tools too!

On Nov 20, 2017 7:58 PM, "Mke C"  wrote:



On 11/20/2017 05:54 PM, plug-requ...@pdxlinux.org wrote:

> With the mail/phone issues I've had recently I want to check that I'm
>> doing things correctly. Two instances of not reaching web pages.
>>
>> I can load (and ping)www.opendkim.org, but cannot load (or ping)
>>
>> lists.opendkim.org. This means their mail list page is off-line. Yes?
>>
>> No, not necessarily.
>
> Yesterday and today I try to accesswww.verizonwireless.com  but the
>
> page
>> won't load. Neither can I ping that server. This means that their web site
>> is down. Yes?
>>
>> Again, not necessarily.
>
> More and more IT / Security groups are going to dropping the ICMP (ping)
> packets for "security" reasons, and this affects several tools that have
> long been used by the layperson and professional alike.
>
> When the firewall receives an ICMP packet, ping and traceroute both will
> show failure and/or lack of "up: state. If the attacker knows the device is
> there by DNS resolution or IP address, they have a known target, and the
> dropping of packets (IMO) is just obscuring things a little bit.
>
This is more of an ol' skool mentality that reflects a serious lack of a
deeper understanding of networking and of being a good & useful netizen. In
reality, we should actually see less and less of this over time as the ICMP
protocol suite is very useful and blocking it doesn't amount to very much
that's good and/or useful.

Other tools that you can try are telnet to the port for the service in
> question, nmap to check for all open ports (potential for looking like an
> attacker), and netcat (nc) to test for specific, or scan for all open,
> ports.
>
> A deeper way to search if things are connecting at all is the use of
> netstat, Wireshark, or tcpdump in some cases.
>
I've been a network engineer for over a decade and I've learned to use the
simplest tool possible for a task. In this case tcping is a very good
simple and easy to use tool for anyone who's just wanting to test
connectivity to network host. Most implementations allow for a port number
to  be specified. If you're unsure of the port number from the Linux cli
you can cat the /etc/services file to get a listing of udp & tcp ports w.
description that's updated by IANA.

e.g.
~$ cat /etc/services
# Network services, Internet style
#
# Note that it is presently the policy of IANA to assign a single
well-known port number for both TCP and UDP; hence, officially ports have
two entries
# even if the protocol doesn't support UDP operations.
#
# Updated from http://www.iana.org/assignments/port-numbers and other
sources like http://www.freebsd.org/cgi/cvsweb.cgi/src/etc/services .
# New ports will be added on request if they have been officially assigned
by IANA and used in the real-world or are needed by a debian package.
# If you need a huge list of used numbers please install the nmap package.

tcpmux1/tcp# TCP port service multiplexer
echo7/tcp
echo7/udp
discard9/tcpsink null
discard9/udpsink null
systat11/tcpusers

This particular implementation, https://www.elifulkerson.com/p
rojects/tcping.php , provides a lot of HTTP mode options as well setting
wait interval for a response, calculating jitter (variance in delay) and
prefer ipv4 or ipv6.

Network connectivity is going to likely become more problematic, and our
> means of testing things will likely become more restricted as time passes.
> Just my guess, but it's a trend I have been noticing.
>
I don't follow nor subscribe to this logic at all. I expect network
connectivity and ways to test to it to only get better as everyone and
their grandparents demand well performing, highly reliable internet
connectivity from all of their devices, everywhere. 5 years ago while
working at an ISP in downtown Portland I had to work on networking problems
from end-users of our ISP business partners who where complaining about
high ping times in their favorite online game. And I'm talking about sub
150 ms round-trip ping times which is used as the measuring stick for toll
quality VoIP.

Also, consider that IPv6 provides improved QOS functionality, better
security and faster routing on an end to end connection basis. As
infrastructure gets re-designed and changed  out I only expect network
connectivity to get less problematic with greater visibility into problems
provided by better tools and information.

___
PLUG mailing list
PLUG@pdxlinux.org
http://lists.pdxlinux.org/mailman/listinfo/plug
___
PLUG mailing list
PLUG@pdxlinux.org
http://lists.pdxlinux.org/mailman/listinfo/plug

Re: [PLUG] Reality check

[Mke C>]

On 11/20/2017 05:54 PM, plug-requ...@pdxlinux.org wrote:

With the mail/phone issues I've had recently I want to check that I'm
doing things correctly. Two instances of not reaching web pages.

I can load (and ping)www.opendkim.org, but cannot load (or ping)
lists.opendkim.org. This means their mail list page is off-line. Yes?


No, not necessarily.

Yesterday and today I try to accesswww.verizonwireless.com  but the

page
won't load. Neither can I ping that server. This means that their web site
is down. Yes?


Again, not necessarily.

More and more IT / Security groups are going to dropping the ICMP (ping)
packets for "security" reasons, and this affects several tools that have
long been used by the layperson and professional alike.

When the firewall receives an ICMP packet, ping and traceroute both will
show failure and/or lack of "up: state. If the attacker knows the device is
there by DNS resolution or IP address, they have a known target, and the
dropping of packets (IMO) is just obscuring things a little bit.
This is more of an ol' skool mentality that reflects a serious lack of a 
deeper understanding of networking and of being a good & useful netizen. 
In reality, we should actually see less and less of this over time as 
the ICMP protocol suite is very useful and blocking it doesn't amount to 
very much that's good and/or useful.

Other tools that you can try are telnet to the port for the service in
question, nmap to check for all open ports (potential for looking like an
attacker), and netcat (nc) to test for specific, or scan for all open,
ports.

A deeper way to search if things are connecting at all is the use of
netstat, Wireshark, or tcpdump in some cases.
I've been a network engineer for over a decade and I've learned to use 
the simplest tool possible for a task. In this case tcping is a very 
good simple and easy to use tool for anyone who's just wanting to test 
connectivity to network host. Most implementations allow for a port 
number to  be specified. If you're unsure of the port number from the 
Linux cli you can cat the /etc/services file to get a listing of udp & 
tcp ports w. description that's updated by IANA.


e.g.
~$ cat /etc/services
# Network services, Internet style
#
# Note that it is presently the policy of IANA to assign a single 
well-known port number for both TCP and UDP; hence, officially ports 
have two entries

# even if the protocol doesn't support UDP operations.
#
# Updated from http://www.iana.org/assignments/port-numbers and other 
sources like http://www.freebsd.org/cgi/cvsweb.cgi/src/etc/services .
# New ports will be added on request if they have been officially 
assigned by IANA and used in the real-world or are needed by a debian 
package.

# If you need a huge list of used numbers please install the nmap package.

tcpmux        1/tcp                # TCP port service multiplexer
echo        7/tcp
echo        7/udp
discard        9/tcp        sink null
discard        9/udp        sink null
systat        11/tcp        users

This particular implementation, 
https://www.elifulkerson.com/projects/tcping.php , provides a lot of 
HTTP mode options as well setting wait interval for a response, 
calculating jitter (variance in delay) and prefer ipv4 or ipv6.

Network connectivity is going to likely become more problematic, and our means 
of testing things will likely become more restricted as time passes.
Just my guess, but it's a trend I have been noticing.
I don't follow nor subscribe to this logic at all. I expect network 
connectivity and ways to test to it to only get better as everyone and 
their grandparents demand well performing, highly reliable internet 
connectivity from all of their devices, everywhere. 5 years ago while 
working at an ISP in downtown Portland I had to work on networking 
problems from end-users of our ISP business partners who where 
complaining about high ping times in their favorite online game. And I'm 
talking about sub 150 ms round-trip ping times which is used as the 
measuring stick for toll quality VoIP.


Also, consider that IPv6 provides improved QOS functionality, better 
security and faster routing on an end to end connection basis. As 
infrastructure gets re-designed and changed  out I only expect network 
connectivity to get less problematic with greater visibility into 
problems provided by better tools and information.

___
PLUG mailing list
PLUG@pdxlinux.org
http://lists.pdxlinux.org/mailman/listinfo/plug

Re: [PLUG] Reality check

[david]

On 11/18/2017 03:47 PM, Rich Shepard wrote:

   With the mail/phone issues I've had recently I want to check that I'm
doing things correctly. Two instances of not reaching web pages.

   I can load (and ping) www.opendkim.org, but cannot load (or ping)
lists.opendkim.org. This means their mail list page is off-line. Yes?


No, not necessarily.


   Yesterday and today I try to access www.verizonwireless.com but the page
won't load. Neither can I ping that server. This means that their web site
is down. Yes?


Again, not necessarily.

More and more IT / Security groups are going to dropping the ICMP (ping) 
packets for "security" reasons, and this affects several tools that have 
long been used by the layperson and professional alike.


When the firewall receives an ICMP packet, ping and traceroute both will 
show failure and/or lack of "up: state. If the attacker knows the device 
is there by DNS resolution or IP address, they have a known target, and 
the dropping of packets (IMO) is just obscuring things a little bit.


Other tools that you can try are telnet to the port for the service in 
question, nmap to check for all open ports (potential for looking like 
an attacker), and netcat (nc) to test for specific, or scan for all 
open, ports.


A deeper way to search if things are connecting at all is the use of 
netstat, Wireshark, or tcpdump in some cases.


Network connectivity is going to likely become more problematic, and our 
means of testing things will likely become more restricted as time 
passes. Just my guess, but it's a trend I have been noticing.


dafr
___
PLUG mailing list
PLUG@pdxlinux.org
http://lists.pdxlinux.org/mailman/listinfo/plug

Re: [PLUG] Reality check

[Tom]

I can reach both web sites, not sure about the list.

It is not unusual that computers do not respond to ping these days.

Perhaps you can try: traceroute lists.opendkim.org
Traceroute does not guarantee anything either, but at least show if
there is some sort of network route to IP.

ping www.opendkim.org
PING medusa.blackops.org (208.69.40.157) 56(84) bytes of data.
64 bytes from medusa.blackops.org (208.69.40.157): icmp_seq=1 ttl=54
time=22.1 ms
www.verizonwireless.com does not respond to ping but loads in browser.
lists.opendkim.org does not respond to ping or traceroute.

traceroute to lists.opendkim.org (208.69.177.116), 30 hops max, 60 byte
packets
 1  usg1 (192.168.1.1)  0.412 ms  0.576 ms  0.389 ms
 2  ptld-dsl-gw49.ptld.qwest.net (207.225.84.49)  3.347 ms  3.507
ms  3.776 ms
 3  ptld-agw1.inet.qwest.net (207.225.86.129)  3.594 ms  3.708
ms  3.808 ms
 4  sea-brdr-02.inet.qwest.net (67.14.41.190)  7.126 ms  7.223
ms  7.519 ms
 5  be209.ccr21.sea02.atlas.cogentco.com (154.54.11.1)  23.969
ms  23.855 ms  25.295 ms
 6  be2084.ccr22.sea01.atlas.cogentco.com (154.54.0.253)  24.450 ms
be2083.ccr21.sea01.atlas.cogentco.com (154.54.0.249)  21.590 ms
be2084.ccr22.sea01.atlas.cogentco.com (154.54.0.253)  22.125 ms
 7  be2075.ccr21.sfo01.atlas.cogentco.com (154.54.0.233)  24.792
ms  24.723 ms  24.601 ms
 8  be3178.ccr21.sjc01.atlas.cogentco.com (154.54.43.70)  24.814 ms
be3179.ccr22.sjc01.atlas.cogentco.com (154.54.43.150)  22.224
ms  22.089 ms
 9  be2063.rcr21.b001848-1.sjc01.atlas.cogentco.com
(154.54.1.162)  22.693 ms be2095.rcr21.b001848-
1.sjc01.atlas.cogentco.com (154.54.3.138)  23.589 ms  23.997 ms
10  * * *
11  * * *


Check if DNS works by asking dig or nslookup

For basic sanity checks, I found www.google.com to respond reliably to
ping. Additionally it is good for checking DNS as it should change IP
with most requests.

Tomas

On Sat, 2017-11-18 at 15:47 -0800, Rich Shepard wrote:
>    With the mail/phone issues I've had recently I want to check that
> I'm
> doing things correctly. Two instances of not reaching
> web pages.
> 
>    I can load (and ping) www.opendkim.org, but cannot load (or ping)
> lists.opendkim.org. This means their mail list page is off-line. Yes?
> 
>    Yesterday and today I try to access www.verizonwireless.com but
> the page
> won't load. Neither can I ping that server. This means that their web
> site
> is down. Yes?
> 
>    Perhaps it's the fault of climate change, but the mail server for
> the LyX
> mail list has been down for 8 days now "we have some hardware issues
> that
> should be resolved soon." Definition of 'soon' is left to the reader.
> 
> Rich
> ___
> PLUG mailing list
> PLUG@pdxlinux.org
> http://lists.pdxlinux.org/mailman/listinfo/plug
___
PLUG mailing list
PLUG@pdxlinux.org
http://lists.pdxlinux.org/mailman/listinfo/plug

Re: [PLUG] Reality check

[Russell Johnson]

> On Nov 18, 2017, at 15:47, Rich Shepard  wrote:
> 
>  With the mail/phone issues I've had recently I want to check that I'm
> doing things correctly. Two instances of not reaching web pages.
> 
>  I can load (and ping) www.opendkim.org, but cannot load (or ping)
> lists.opendkim.org. This means their mail list page is off-line. Yes?
> 
>  Yesterday and today I try to access www.verizonwireless.com but the page
> won't load. Neither can I ping that server. This means that their web site
> is down. Yes?

Hey Rich,

When I find myself in this position, I like to use 
http://downforeveryoneorjustme.com/ . They 
can tell you if it’s down, or just you. 

FWIW, Verizon’s site appears to be up for me. 

—

Russell Johnson
r...@dimstar.net




___
PLUG mailing list
PLUG@pdxlinux.org
http://lists.pdxlinux.org/mailman/listinfo/plug

[PLUG] Reality check

[Rich Shepard]

  With the mail/phone issues I've had recently I want to check that I'm
doing things correctly. Two instances of not reaching web pages.

  I can load (and ping) www.opendkim.org, but cannot load (or ping)
lists.opendkim.org. This means their mail list page is off-line. Yes?

  Yesterday and today I try to access www.verizonwireless.com but the page
won't load. Neither can I ping that server. This means that their web site
is down. Yes?

  Perhaps it's the fault of climate change, but the mail server for the LyX
mail list has been down for 8 days now "we have some hardware issues that
should be resolved soon." Definition of 'soon' is left to the reader.

Rich
___
PLUG mailing list
PLUG@pdxlinux.org
http://lists.pdxlinux.org/mailman/listinfo/plug