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
