Re: failed shields up test
- From: Malcolm <malcolm_nospamlewis@xxxxxxxxxxxxx>
- Date: Sat, 22 Dec 2007 14:17:27 -0600
On Sat, 22 Dec 2007 13:27:09 -0600
ibuprofin@xxxxxxxxxxxxxxxxxxxxxx (Moe Trin) wrote:
On Sat, 22 Dec 2007, in the Usenet newsgroup alt.os.linux.suse, inHi
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
You could also use an external shell account to do your testing
from.
--
Cheers Malcolm °¿° (Linux Counter #276890)
SLED 10.0 SP1 x86_64 Kernel 2.6.16.54-0.2.3-smp
up 16 days 18:00, 1 user, load average: 0.02, 0.03, 0.00
.
- Follow-Ups:
- Re: failed shields up test
- From: Moe Trin
- Re: failed shields up test
- References:
- failed shields up test
- From: Derk
- Re: failed shields up test
- From: Nikos Chantziaras
- Re: failed shields up test
- From: Paul J Gans
- Re: failed shields up test
- From: Moe Trin
- failed shields up test
- Prev by Date: Re: dependency hell
- Next by Date: Re: dependency hell
- Previous by thread: Re: failed shields up test
- Next by thread: Re: failed shields up test
- Index(es):
Relevant Pages
|
