Shields up - Whats up

Archived from groups: comp.security.firewalls (More info?)

If Shields-up is not worth using (for the reasons already given by some
here), are there any on line system testing tools that will give a more
worthwhile indication of vulnerability from incoming probing or information
gathering?

I'm not talking about scans for virus, trojan etc.

Thanks
19 answers Last reply
More about shields whats
  1. Archived from groups: comp.security.firewalls (More info?)

    "Alt Beer" <null@null.com> wrote in message
    news:AMjVe.7078$zw1.3603@newsfe2-gui.ntli.net...
    > If Shields-up is not worth using (for the reasons already given by some
    > here), are there any on line system testing tools that will give a more
    > worthwhile indication of vulnerability from incoming probing or
    information
    > gathering?
    >
    > I'm not talking about scans for virus, trojan etc.

    If you understand what shields up does, what its limitations are, what it
    can tell you, what it can't tell you, what is between you and shields up,
    etc, then it isn't necessarily worthless.
    I just ran it against my present location and failed miserably, but I know
    why so I don't care.

    There are many other similar online tools. Most of them will turn up here
    http://www.google.com/search?&q=security+scan
    But it's still necessary to know what their limitations are.

    Jason

    >
    > Thanks
    >
    >
    >
  2. Archived from groups: comp.security.firewalls (More info?)

    Alt Beer <null@null.com> wrote:
    > If Shields-up is not worth using (for the reasons already given by some
    > here), are there any on line system testing tools that will give a more
    > worthwhile indication of vulnerability from incoming probing or information
    > gathering?

    Such tools all suffer from the problem, that maybe on the route in between
    things are filtered, which are not from another route.

    So it's much better to scan your host locally. Just use a second host on
    the same network, and nmap -sS -P0

    Yours,
    VB.
    --
    "Es kann nicht sein, dass die Frustrierten in Rom bestimmen, was in
    deutschen Schlafzimmern passiert".
    Harald Schmidt zum "Weltjugendtag"
  3. Archived from groups: comp.security.firewalls (More info?)

    Jason Edwards <none1@invalid.invalid> wrote:
    > If you understand what shields up does, what its limitations are, what it
    > can tell you, what it can't tell you, what is between you and shields up,
    > etc, then it isn't necessarily worthless.

    Right. It's ridiculous, and makes life somewhat happier ;-)

    Yours,
    VB.
    --
    "Es kann nicht sein, dass die Frustrierten in Rom bestimmen, was in
    deutschen Schlafzimmern passiert".
    Harald Schmidt zum "Weltjugendtag"
  4. Archived from groups: comp.security.firewalls (More info?)

    Volker Birk wrote:
    > Alt Beer <null@null.com> wrote:
    > > If Shields-up is not worth using (for the reasons already given by some
    > > here), are there any on line system testing tools that will give a more
    > > worthwhile indication of vulnerability from incoming probing or information
    > > gathering?
    >
    > Such tools all suffer from the problem, that maybe on the route in between
    > things are filtered, which are not from another route.
    >
    > So it's much better to scan your host locally. Just use a second host on
    > the same network, and nmap -sS -P0
    >
    > Yours,
    > VB.
    > --

    but what if you want to test the router/firewall/nat device that the
    comps are connected to?
  5. Archived from groups: comp.security.firewalls (More info?)

    Jason Edwards wrote:
    > "Jim Scott" <mr.jimscott@Xvirgin.net> wrote in message
    > news:98xq7d8fwdd0.dlg@ID-104726.news.individual.net...
    > > On 13 Sep 2005 07:08:59 -0700, jameshanley39@yahoo.co.uk wrote:
    > >
    > > > Volker Birk wrote:
    > > >> Alt Beer <null@null.com> wrote:
    > > >>> If Shields-up is not worth using (for the reasons already given by
    > some
    > > >>> here), are there any on line system testing tools that will give a
    > more
    > > >>> worthwhile indication of vulnerability from incoming probing or
    > information
    > > >>> gathering?
    > > >>
    > > >> Such tools all suffer from the problem, that maybe on the route in
    > between
    > > >> things are filtered, which are not from another route.
    > > >>
    > > >> So it's much better to scan your host locally. Just use a second host
    > on
    > > >> the same network, and nmap -sS -P0
    > > >>
    > > >> Yours,
    > > >> VB.
    > > >> --
    > > >
    > > > but what if you want to test the router/firewall/nat device that the
    > > > comps are connected to?
    > >
    > > Or if it is a stand alone?
    >
    > Either scan yourself from another computer with another IP address (Such as
    > a friend or neighbor's computer) or use the online tools.
    >

    well. if a local scan really can't do it, then it's not an alternative
    to the web scan interfaces.

    so, i'm wondering 'what would VB do?'


    off topic slightly, Regarding alternatives - what i would do until I
    see a better idea

    and I can think of alternatives to a web interface too, without asking
    friends or neighbours!!!

    An alternative to online scan would be to have a comp outside the
    network. plug the comp into the phone socket and dial up to an ISP.
    So you have an IP outside that network sending packets to your network
    going throguh that router/firewall/NAT device. In the UK dial up isn't
    free though.
    And you need to have a comp to take off your network to do the test.
    You get a good test though, you can use nmap. But web scan wins hands
    down for convenience.

    I've only read book about real routers, but maybe if you have a proper
    router, then you can connect a 2 port switch to one port. Connect one
    port to the internet. On the other port put a computer. So now you can
    test your comp as if from the internet, using nmap. perhaps.

    It appears to me that there is no convenient way to avoid web
    interfaces. A local scan doesn't seem like an an alternative . I'm
    sure i'm wrong though. I'm hoping i'm wrong. i'm wondering 'what would
    VB do ;) ' since he seems by to think that online web scans are not
    necessary.

    Maybe some other comp somewhere on the internet, always on, that he can
    telnet to and run nmap from. But if it's accessible from anywhere,
    that's hard to secure. Academic institutions tend to offer this sort of
    thing and let any IP through.
  6. Archived from groups: comp.security.firewalls (More info?)

    On 13 Sep 2005 07:08:59 -0700, jameshanley39@yahoo.co.uk wrote:

    > Volker Birk wrote:
    >> Alt Beer <null@null.com> wrote:
    >>> If Shields-up is not worth using (for the reasons already given by some
    >>> here), are there any on line system testing tools that will give a more
    >>> worthwhile indication of vulnerability from incoming probing or information
    >>> gathering?
    >>
    >> Such tools all suffer from the problem, that maybe on the route in between
    >> things are filtered, which are not from another route.
    >>
    >> So it's much better to scan your host locally. Just use a second host on
    >> the same network, and nmap -sS -P0
    >>
    >> Yours,
    >> VB.
    >> --
    >
    > but what if you want to test the router/firewall/nat device that the
    > comps are connected to?

    Or if it is a stand alone?
    --
    Jim
    Tyneside UK
  7. Archived from groups: comp.security.firewalls (More info?)

    Volker Birk wrote:
    > jameshanley39@yahoo.co.uk wrote:
    > > > Such tools all suffer from the problem, that maybe on the route in between
    > > > things are filtered, which are not from another route.
    > > > So it's much better to scan your host locally. Just use a second host on
    > > > the same network, and nmap -sS -P0
    > > but what if you want to test the router/firewall/nat device that the
    > > comps are connected to?
    >
    > Then a test in the same network is useful also. Perhaps with a second
    > box at the same provider, if you want to test what's behind DSL, for
    > example.
    >
    > Yours,
    > VB.

    I don't know what you mean "second box at the same provider"

    second computer? second router? I don't understand either way.

    At the moment I have
    My Computers to my NAT device to the wall to my ISP's Router.

    There are no options for a second anything between the wall and my
    ISP's router. I can't even see behind there!! ;)

    Between my NAT device and the wall, there can only be a telephone
    cable.

    The only place on the NAT device where I can put anything other than
    the telephone cable is in the switch built into the NAT device. So I
    woudln't be testing my NAT device from the outside. Unless I used an
    online scanner. My NAT device has a built in firewall too, and of
    course port forwarding facility, so it's important to check it from the
    outside.

    So, when you say "second box at the same provider" I suppose you're
    assuming I have a better set up!!!

    I am thinking of a real router. Use 2 interfaces. Putt a switch on one
    interface, hooking that up to the itnernet and to a computerA. Then
    on the other interface I have the comps on my LAN. Then, compuoter A
    can access my LAN from the outside.


    I don't know what you mean by "second box at the same provider".
    What setup should I have?

    The idea is to port scan from the internet, or from outside my LAN,
    outside my router or nat device. I googled "second box at the same
    provider" but no luck!
  8. Archived from groups: comp.security.firewalls (More info?)

    "Jim Scott" <mr.jimscott@Xvirgin.net> wrote in message
    news:98xq7d8fwdd0.dlg@ID-104726.news.individual.net...
    > On 13 Sep 2005 07:08:59 -0700, jameshanley39@yahoo.co.uk wrote:
    >
    > > Volker Birk wrote:
    > >> Alt Beer <null@null.com> wrote:
    > >>> If Shields-up is not worth using (for the reasons already given by
    some
    > >>> here), are there any on line system testing tools that will give a
    more
    > >>> worthwhile indication of vulnerability from incoming probing or
    information
    > >>> gathering?
    > >>
    > >> Such tools all suffer from the problem, that maybe on the route in
    between
    > >> things are filtered, which are not from another route.
    > >>
    > >> So it's much better to scan your host locally. Just use a second host
    on
    > >> the same network, and nmap -sS -P0
    > >>
    > >> Yours,
    > >> VB.
    > >> --
    > >
    > > but what if you want to test the router/firewall/nat device that the
    > > comps are connected to?
    >
    > Or if it is a stand alone?

    Either scan yourself from another computer with another IP address (Such as
    a friend or neighbor's computer) or use the online tools.

    Jason

    > --
    > Jim
    > Tyneside UK
  9. Archived from groups: comp.security.firewalls (More info?)

    jameshanley39@yahoo.co.uk wrote:
    > > Such tools all suffer from the problem, that maybe on the route in between
    > > things are filtered, which are not from another route.
    > > So it's much better to scan your host locally. Just use a second host on
    > > the same network, and nmap -sS -P0
    > but what if you want to test the router/firewall/nat device that the
    > comps are connected to?

    Then a test in the same network is useful also. Perhaps with a second
    box at the same provider, if you want to test what's behind DSL, for
    example.

    Yours,
    VB.
    --
    "Es kann nicht sein, dass die Frustrierten in Rom bestimmen, was in
    deutschen Schlafzimmern passiert".
    Harald Schmidt zum "Weltjugendtag"
  10. Archived from groups: comp.security.firewalls (More info?)

    jameshanley39@yahoo.co.uk wrote:
    > so, i'm wondering 'what would VB do?'

    VB would do a netstat -ano or a lsof -i and check, what's offered.
    This is best anyway. ;-)

    Yours,
    VB.
    --
    "Es kann nicht sein, dass die Frustrierten in Rom bestimmen, was in
    deutschen Schlafzimmern passiert".
    Harald Schmidt zum "Weltjugendtag"
  11. Archived from groups: comp.security.firewalls (More info?)

    On 13 Sep 2005 19:26:58 +0200, Volker Birk wrote:

    > jameshanley39@yahoo.co.uk wrote:
    >> so, i'm wondering 'what would VB do?'
    >
    > VB would do a netstat -ano or a lsof -i and check, what's offered.
    > This is best anyway. ;-)
    >
    > Yours,
    > VB.

    What would he be looking out for?
    --
    Jim
    Tyneside UK
  12. Archived from groups: comp.security.firewalls (More info?)

    "Volker Birk" <bumens@dingens.org> wrote in message
    news:43270be2@news.uni-ulm.de...
    > jameshanley39@yahoo.co.uk wrote:
    > > so, i'm wondering 'what would VB do?'
    >
    > VB would do a netstat -ano or a lsof -i and check, what's offered.
    > This is best anyway. ;-)

    It is certainly best to know what is offered.
    In other words it is best to know what the results of a scan will be before
    you do it.
    I frequently use online tools to run scans, even shields up sometimes, but I
    nearly always get the result I knew I'd get and if I get an unexpected
    result then I'll compare it with the result from a different online tool or
    do other tests to find out why there's a discrepancy.
    Using shields up for a quick test doesn't mean I have to read or believe
    anything on the shields up site.

    Jason

    >
    > Yours,
    > VB.
    > --
    > "Es kann nicht sein, dass die Frustrierten in Rom bestimmen, was in
    > deutschen Schlafzimmern passiert".
    > Harald Schmidt zum "Weltjugendtag"
  13. Archived from groups: comp.security.firewalls (More info?)

    Jim Scott <mr.jimscott@xvirgin.net> wrote:
    > > jameshanley39@yahoo.co.uk wrote:
    > >> so, i'm wondering 'what would VB do?'
    > > VB would do a netstat -ano or a lsof -i and check, what's offered.
    > > This is best anyway. ;-)
    > What would he be looking out for?

    He'd looking out for processes listen()ing, and not listen()ing on
    localhost 127.0.0.1.

    Yours,
    VB.
    --
    "Es kann nicht sein, dass die Frustrierten in Rom bestimmen, was in
    deutschen Schlafzimmern passiert".
    Harald Schmidt zum "Weltjugendtag"
  14. Archived from groups: comp.security.firewalls (More info?)

    On 13 Sep 2005 22:34:59 +0200, Volker Birk wrote:

    > Jim Scott <mr.jimscott@xvirgin.net> wrote:
    >>> jameshanley39@yahoo.co.uk wrote:
    >>>> so, i'm wondering 'what would VB do?'
    >>> VB would do a netstat -ano or a lsof -i and check, what's offered.
    >>> This is best anyway. ;-)
    >> What would he be looking out for?
    >
    > He'd looking out for processes listen()ing, and not listen()ing on
    > localhost 127.0.0.1.
    >
    > Yours,
    > VB.

    And then?
    --
    Jim
    Tyneside UK
  15. Archived from groups: comp.security.firewalls (More info?)

    Jim Scott <mr.jimscott@xvirgin.net> wrote:
    > On 13 Sep 2005 22:34:59 +0200, Volker Birk wrote:
    > > Jim Scott <mr.jimscott@xvirgin.net> wrote:
    > >>> jameshanley39@yahoo.co.uk wrote:
    > >>>> so, i'm wondering 'what would VB do?'
    > >>> VB would do a netstat -ano or a lsof -i and check, what's offered.
    > >>> This is best anyway. ;-)
    > >> What would he be looking out for?
    > > He'd looking out for processes listen()ing, and not listen()ing on
    > > localhost 127.0.0.1.
    > And then?

    If there is noting which listen()s, then there is nothing I need to
    filter.

    And if a test from outside is showing something, then this is an error
    in this test.

    Yours,
    VB.
    --
    "Es kann nicht sein, dass die Frustrierten in Rom bestimmen, was in
    deutschen Schlafzimmern passiert".
    Harald Schmidt zum "Weltjugendtag"
  16. Archived from groups: comp.security.firewalls (More info?)

    jameshanley39@yahoo.co.uk wrote:
    > > > > Such tools all suffer from the problem, that maybe on the route in
    > > > > between
    > > > > things are filtered, which are not from another route.
    > > > > So it's much better to scan your host locally. Just use a second
    > > > > host on
    > > > > the same network, and nmap -sS -P0
    > > > but what if you want to test the router/firewall/nat device that the
    > > > comps are connected to?
    > > Then a test in the same network is useful also. Perhaps with a second
    > > box at the same provider, if you want to test what's behind DSL, for
    > > example.
    > I don't know what you mean "second box at the same provider"
    > second computer? second router? I don't understand either way.

    With a second computer, which uses the same infrastructure to connect,
    you'll have a very short route and usually nothing filtering in between.

    What I mean is, that with a second account at the same provider, a second
    connection is used.

    > At the moment I have
    > My Computers to my NAT device to the wall to my ISP's Router.
    > There are no options for a second anything between the wall and my
    > ISP's router. I can't even see behind there!! ;)
    > Between my NAT device and the wall, there can only be a telephone
    > cable.

    Just use a second "telephone cable" and a second connection. Perhaps
    you are having a friend, who uses the same connection type in your
    neighborhood?

    > The only place on the NAT device where I can put anything other than
    > the telephone cable is in the switch built into the NAT device. So I
    > woudln't be testing my NAT device from the outside. Unless I used an
    > online scanner. My NAT device has a built in firewall too, and of
    > course port forwarding facility, so it's important to check it from the
    > outside.

    In this case you're right. Aren't you able to have a second way to
    reach the Internet? Then a simple nmap -sS -P0 $actual_ip_address will do.

    > I don't know what you mean by "second box at the same provider".
    > What setup should I have?

    A friend with the same connection type, or just another computer with
    Internet connection, if that isn't possible.

    To make that clear: I have nothing against online scans, if they're not
    from Gibson or some other guys I don't trust at all. If you have a Webpage,
    who documents exactly _how_ the scan is done, and you trust in that, then
    you can use this way either, if no other way is suitable for you.

    Usually you're seeing immediately, if you cannot trust such a Webpage:
    if they're babbling about "stealth ports" ;-)

    This is important for security purposes anyway: think yourself. Don't
    believe too much. Test it yourself. Try it out, and try to understand.

    Yours,
    VB.
    --
    "Es kann nicht sein, dass die Frustrierten in Rom bestimmen, was in
    deutschen Schlafzimmern passiert".
    Harald Schmidt zum "Weltjugendtag"
  17. Archived from groups: comp.security.firewalls (More info?)

    On 13 Sep 2005 22:34:59 +0200, Volker Birk spoketh

    >Jim Scott <mr.jimscott@xvirgin.net> wrote:
    >> > jameshanley39@yahoo.co.uk wrote:
    >> >> so, i'm wondering 'what would VB do?'
    >> > VB would do a netstat -ano or a lsof -i and check, what's offered.
    >> > This is best anyway. ;-)
    >> What would he be looking out for?
    >
    >He'd looking out for processes listen()ing, and not listen()ing on
    >localhost 127.0.0.1.
    >
    >Yours,
    >VB.

    Actually, anything listening on 127.0.0.1 would be harmless anyways, as
    it would only accept local (host) connections.

    The things to look out for are anything listening on 0.0.0.0 or the
    actual IP address of the machine.

    Lars M. Hansen
    http://www.hansenonline.net
    (replace 'badnews' with 'news' in e-mail address)
  18. Archived from groups: comp.security.firewalls (More info?)

    On Sun, 18 Sep 2005 09:11:18 -0400, Lars M. Hansen
    <badnews@hansenonline.net> wrote:

    >On 13 Sep 2005 22:34:59 +0200, Volker Birk spoketh
    >
    >>Jim Scott <mr.jimscott@xvirgin.net> wrote:
    >>> > jameshanley39@yahoo.co.uk wrote:
    >>> >> so, i'm wondering 'what would VB do?'
    >>> > VB would do a netstat -ano or a lsof -i and check, what's offered.
    >>> > This is best anyway. ;-)
    >>> What would he be looking out for?
    >>
    >>He'd looking out for processes listen()ing, and not listen()ing on
    >>localhost 127.0.0.1.
    >>
    >>Yours,
    >>VB.
    >
    >Actually, anything listening on 127.0.0.1 would be harmless anyways, as
    >it would only accept local (host) connections.
    >
    >The things to look out for are anything listening on 0.0.0.0 or the
    >actual IP address of the machine.

    Netstat "listening" isn't always accurate. Below is a paste from a
    article by Marchand:
    http://www.hsc.fr./ressources/breves/min_srv_res_win.en.html

    *************************************
    C:\WINDOWS>netstat -anp tcp | find ":1367"
    TCP 0.0.0.0:1367 0.0.0.0:0 LISTENING
    TCP 192.70.106.142:1367 192.70.106.76:22 ESTABLISHED

    The second line shows the established connection, from local port 1367
    to remote
    port 22. However, the first line is incorrect because it reports local
    port 1367
    in the LISTENING state, whereas no TCP server is available on this
    port.

    Thus, for each outgoing TCP connection, an additional line will appear
    in
    netstat output, showing a TCP port in LISTENING state. It is important
    to make
    the difference between an opened TCP port and one incorrectly reported
    by netstat
    in the LISTENING state.

    Note: this bug has been fixed in Windows Server 2003.
    ***************************************
    I've seen misleading netstat -an reports myself on Win 2K Pro where it
    seems that some port numbered >1023 might be "open" but port scanning
    web sites report it as closed.

    Art

    http://home.epix.net/~artnpeg
  19. Archived from groups: comp.security.firewalls (More info?)

    Lars M. Hansen <badnews@hansenonline.net> wrote:
    > Actually, anything listening on 127.0.0.1 would be harmless anyways, as
    > it would only accept local (host) connections.

    Yes.

    > The things to look out for are anything listening on 0.0.0.0 or the
    > actual IP address of the machine.

    Yes. As I stated, _not_ listening on 127.0.0.1.

    Yours,
    VB.
    --
    "Es kann nicht sein, dass die Frustrierten in Rom bestimmen, was in
    deutschen Schlafzimmern passiert".
    Harald Schmidt zum "Weltjugendtag"
Ask a new question

Read More

Firewalls Security Networking