[sf-lug] Cool little security check

maestro maestro415 at gmail.com
Mon Sep 3 23:27:05 PDT 2018


Thank you Michael P. ...


message ends.
__________________




On Mon, Sep 3, 2018 at 8:53 PM Michael Paoli <Michael.Paoli at cal.berkeley.edu>
wrote:

> > From: aaronco36 <aaronco36 at SDF.ORG>
> > Subject: [sf-lug] Cool little security check
> > Date: Sun, 2 Sep 2018 15:17:33 +0000 (UTC)
>
> > maestro <maestro415 at gmail.com> wrote at [01]:
> >
> >> Next, go to www.grc.com and click on ShieldsUp, next screen scroll
> >> down to Hot Spots, and click on ShieldsUp again, next screen click on
> >> Proceed, next screen click on All Service Ports and let it check the
> >> ports, gives an ok result, the ports are neon green,
> >
> > The ShieldsUp Wikipedia writeup of [02] describes it as such:
> > ~~~~~~~~~~ quoting ~~~~~~~~~~~~~~
> > ShieldsUp is an online port scanning service created by Steve Gibson
> > of Gibson Research Corporation and hosted at grc.com. The purpose of
> > this utility is to alert the users of any ports that have been
> > opened through their firewalls or through their NAT routers. The
> > utility can scan the most common file sharing ports, as well as all
> > service ports (1-1056), and user defined ports, in sets of 64.
> > It is often recommended for checking port vulnerabilities.
> >
> > The scanning servers have the static IP addresses of 4.79.142.192 to
> > 4.79.142.207.
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >
> > Instead of using this ShieldsUp security check on one's own machine,
> > IMHO, you might also want to seriously consider getting more
> > up-to-speed with the Nmap Network exploration tool and security /
> > port scanner. One of its online manpages is here [03], although if
> > you've already installed Nmap, you can read its manpage directly from
>
> Heck, if you've got regular login access on the host, why bother to go
> so far as to scan with nmap?  One could use something like:
> $ ss -nlf inet -f inet6
> Or if you've got superuser ("root") access, add the -p option too
> to also get the responsible process information at the same time:
> # ss -nlpf inet -f inet6
>
> See: ss(8)
> For older installations/distributions, see also: netstat(8)
> Use of ss is also typically much more efficient in any common usage
> scenarios ... e.g. just want to know if TCP ports 25 and/or 587 are
> being listened to and if so on what IP(s):
> $ ss -nlt '( sport = :25 or sport = :587 )'
> State      Recv-Q Send-Q Local Address:Port               Peer Address:Port
> LISTEN     0      10     127.0.0.1:25                       *:*
> LISTEN     0      10     127.0.0.1:587                      *:*
> LISTEN     0      10         ::1:25                      :::*
> $
> And on another host, for comparison:
> $ ss -nlt '( sport = :25 or sport = :587 )'
> State      Recv-Q Send-Q Local Address:Port               Peer Address:Port
> LISTEN     0      20           *:25                       *:*
> LISTEN     0      20          :::25                      :::*
> $
> Using ss(8) in such a scenario is also much more efficient, as that
> filtering is done in-kernel ... as opposed to trying to post-filter
> the output of netstat and trying to be sure to not also include any
> false positives.
>
>
> _______________________________________________
> sf-lug mailing list
> sf-lug at linuxmafia.com
> http://linuxmafia.com/mailman/listinfo/sf-lug
> Information about SF-LUG is at http://www.sf-lug.org/<br>
> Related Information <br>
> http://www.shallowsky.com/blog/<br>
> http://explainshell.com/ <br>
>


-- 

*~the quieter you become, the more you are able to hear...*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linuxmafia.com/pipermail/sf-lug/attachments/20180903/1138e680/attachment.html>


More information about the sf-lug mailing list