Re: failed shields up test

On Sat, 22 Dec 2007, in the Usenet newsgroup alt.os.linux.suse, in article
<fkhqmu$k8n$1@xxxxxxxxxxxxxxxxx>, Paul J Gans wrote:

My belief is that thousands of guys trying to break into machines
do not waste their time on machines that are powered down. They
are *VERY* hard to break into.

Do you have two systems you can use that are located on the same LAN?
Try to ping one - you'll probably get a response, but when you've
tried, look at the output of the command '/sbin/arp -a' See the
data for that system? Now wait about a minute for the ARP data
to expire, and while waiting, go to that system and dick with it's
firewall or what-ever, and disable the ping response. With a Linux
box, this can be done by 'echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all'

Now, repeat the test, and notice that the ping command reports no
reply, but you'll also see that '/sbin/arp -a' is showing the MAC data
of the remote. Where do you suppose that comes from? (HINT: Try using
a packet sniffer). And for the final test, reach over and unplug
the network cable from the remote box - again waiting for the data
to expire off the ARP cache, then ping the host. My, my, my, look at
the different indications - ping says "unreachable", and the ARP cache
shows a question mark for the MAC address.

Now, plug the cable back in, and fire up that packet sniffer on "this"
box, and try to telnet to (I dunno - try) port 70 (Gopher) on the
remote. Notice no matter what you try, the system responds with a
RST packet "go away - there is no one home". Do tell everyone how
someone is going to break in past that.

So, my theory is, don't let them know you are there.

As others have pointed out - if there isn't a response with an ICMP
error or TCP 'RST' packet, the box IS THERE. In your copious free
time, read the man page for 'nmap'. Recall that TCP is but one of many
protocols that can be found in an IP packet (see figure 3.1 in RFC0791
and note that the 'Protocol' field is eight bits allowing for 256
different values - http://www.iana.org/assignments/protocol-numbers
lists 141 of them). Tools like nmap (and there really are a few others)
can investigate a lot more than just TCP/UDP/ICMP. Where "experts"
like Gibson screw up is failing to look at the big picture - testing
all protocols, and for those protocols that have them, all ports, and
see that there is no response (which assumes the lack of an adaptive
firewall and/or network stack - but thats a whole 'nother ball of tar).

Old guy
.

Relevant Pages

  • Re: failed shields up test
    ... Try to ping one - you'll probably get a response, ... Now, plug the cable back in, and fire up that packet sniffer on "this" ... protocols that can be found in an IP packet (see figure 3.1 in RFC0791 ...
    (alt.os.linux.suse)
  • Re: [SLE] SuSE/Linux Ping vs DOS Ping
    ... string for a ping packet is 56 bits, add that to the 8 bit header and you get a 64 bit packet of data. ... I believe that Windows sends out a data string 24 bits in length, add the 8 bit header and you get a 32 bit packet. ... even changing the ping byte size didn't work. ... And SuSE's response: ...
    (SuSE)
  • Re: weird ping behavior
    ... > So sometimes I can ping normally. ... > under the impression that ping tries to send out a packet a second. ... the response line could be much longer than the response time. ... to eliminate the DNS time. ...
    (comp.os.linux.misc)
  • [NEWS] Downgrading the Oracle Native Authentication
    ... Get your security news from a reliable source. ... Oracle native authentication protocols are typical challenge-response ... After some negotiation the client sends the username. ... calls it packet version ...
    (Securiteam)
  • Re: Ping & Physics
    ... As I'm sure you know ping retuns the time taken for the packet ... be determined from ping latency values, ... considering only the bit rate is 1.5 ms for a round trip. ...
    (comp.unix.questions)