Did I obfuscate my usenet newsreader & who I am in this posting?

Ernie,

Just haven't posted it, and wont. ;_)

Allan

Good. I haven't bothered to look it up. ;-)

If it is told to reject pings, a router or firewall is doing a it's 'job' when it rejects a ping. If it isn't told to do that then they are not doing a good job. No one says you can't accept pings. Are you afraid of getting pinged? Are you afraid you might get hacked by a ping?

Why would I care to do that? I don't give a shit if you accept pings or not.

You told the OP that, if they accepted pings, they didn't use a router or a firewall. Completely incorrect statement. Just because everyone may not set up their stuff to your standard doesn't make it wrong.

I know that.

Ernie said:

I was merely saying that Ernie's claim was wrong or, at least, not completely correct.

Isn't that essentially what I said?

Nope to both. I prefer to be invisible to the Internet though.

For educational purposes?

Okay, a router may default to accept pings and such. Mine does, I changed the setting during setup. I believe that most firewalls default to blocking pings. Ergo, Tamara probably isn't using a router or firewall.

There's no "right" or "wrong" to it. I prefer a fairly "tight" Internet connection, other people may not.

Not really. You said if they didn't block pings, that was wrong.

You think blocking pings does that?

I already know what it looks like when pings are blocked ;-)

An assumption. I have a router and I allow it to accept pings. Mind you, one has to take some other steps if you do that.

Point taken. I didn't mean to sound harsh.

See below about "right" and "wrong".

It helps.

Based on what Sam Spade tells me.

Yep, steps that I prefer not to mess with.

No problem.

Ernie B. hath wroth:

It's not working today for some reason. It's certainly doing a port scan on my router as indicated by my monitoring software. However, the final report is essentially blank, as you discovered. My router has so many open ports that it should have found at least one.

Here's some recommended and not so recommended security checkers:

I still prefer NMAP.

RDNS shows she's in San Jose CA and connected to PBI/SBC/at&t DSL via the SBC router in Pleasanton.

Good site. Bookmarked for further study, thanks.

She's hopefully reading this thread and learning things. I know I've added to my knowledge.

Surely that's down to local policy (and the consequent implementation)? I prefer my firewall to respond to ping, so it does.

Chris

My router (and I hadn't noticed until someone else posted the problem here) misunderstands the setting for anti-smurf and blocks hosts with addresses ending in .0. I think it was a yahoo or hotmail site that was the example given, but I found a few. At the time, I thought SMURF attacks were either considered ineffective, or just not used any more.

I allow ping responses. I have one server on my network returning the ping instead of the router, because returning ping from the router confuses some people when that server is down, since "it" appears to be responding to ping.

I see that Jeff goes out of his way to obfuscate his identity ;-)

Hard to say. Who are you? If you are not Tamara, don't have a hotmail address, and don't live in San Jose, CA, then you might have done a pretty good job.

snipped-for-privacy@63.usenet.us.com hath wroth:

I guess SMURF is still being used for DoS (denial of service) attacks. However, most new routers default to not allowing redirected ICMP packets, so it's probably ineffective.

I've had far too many arguements on whether IP's ending in .0 are valid. Methinks they're NOT valid. For example, Windoze instantly returns: C:\\>ping 192.168.1.0 Pinging 192.168.1.0 with 32 bytes of data: Destination specified is invalid. Destination specified is invalid. Destination specified is invalid. Destination specified is invalid.

My Unix box returns pings and dupes from most every device it sees in the ARP table. => ping 192.168.111.0 PING 192.168.111.0 (192.168.111.0): 56 data bytes 64 bytes from comix (192.168.111.1): icmp_seq=0 ttl=255 time=10 ms 64 bytes from router (192.168.111.33): icmp_seq=0 ttl=64 time=120 ms (DUP!)

Such weird results would imply that ending in .0 is NOT a valid IP address. That doesn't seem to stop some systems from using it. I've notice that I can never really ping such server directly. It usually shows up in a traceroute list, where I think it was intended to screw up any attempts to probe the inside LAN or routeing. Dunno.

Good idea. I usually just care if the router is accessible.

It's called hiding in plain sight.

• Isn't Smurf a Directed Broadcast attack? I remember living through them at an ISP and watching large ethernet switches with their lights litterally throbbing. I think the setting for that is "no ip directed broadcast". There are other recommended anti-DOS settings. Search for no ip directed broadcast and smurf and some pop up on google.com.

• Windows does that because you are on a /24 in 192.168.1.0, however if you were on a /23 on 192.168.0.0 that ping would work just fine. In fact so would file sharing and everything else. I just labbed this in Vmware Workstation with 2 XP pro ... works like a charm. XP #1 is 192.168.0.10 /23 and XP #2 is 192.168.1.0. I put them on a seperate Virtual Network to test that because I didn't want to screw my actual network.

• If you had a /20 or such larger sized network you could very easily have subnets bigger than the /24 "Class C" that most users think of. The only reason not to use a .0 or a .255 these days is if it IS *THE* network or subnet address TO YOU or TO YOUR ISP. If it doesn't need to be used as either one of those, then it is FAIR GAME. This all depends on how your network was assigned from your network provider, and how you have subnetted it within your location. I worked for a cable ISP for a time and managed such IP Space. I managed the equipment networks and the DHCP Servers for 2 cities. If my memory serves me right we assigned the whole space, for example, in /21's, /22's, and /23's ... depending on how we arranged them. Variable Length Subnet Mask and all that. I think end customers got .0 addresses assigned. Which was fine because to us it was not the network address for a range, and the whole thing was ours from whoever we got it from be it AT&T or ARIN. (I have read of some web sites not liking .0 addresses... I don't know how common or rare that is?)

• Unix does this because you are on that /24. You are pinging the whole network. Not all hosts will recognize that, but some will.

Here's an example on 192.168.0.0/24:

# ping 192.168.0.0 Do you want to ping broadcast? Then -b

• Nope... Just not valid on a /24.

"Alan Spicer" hath wroth:

Sorta. The source IP is forged so that the ICMP ping return goes to the forged IP address instead of the originator.

The Cisco IOS fixes for Smurf attacks are: no ip directed-broadcast no ip redirects no ip unreachables no ip proxy-arp (not sure about this one) Actually, only the "no ip directed-broadcast" has any effect on Smurf attacks, but the other prevent attacks using similar redirection mechanisms (e.g. fraggle).

Hmmm... I've never tried .0 on a /23 network, but will do so at next opportunity. I don't see how a /23 network makes any difference. The active part of the address is all zero's in both /23 and /24.

Interesting. I didn't know that.

I know of 4 local ISP's that don't use .0 IP's as this is the network IP address. .255 is the broadcast IP address. Locally, Comcast/at&t uses /23 networks. I've never seen a .0 address on their networks, but I wasn't looking for it. I'll check on what they're doing later.

No -b option on vintage SCO Unix 3.2v4.2 or under Cygwin. It's there under Linux.

Well, the majority of the cheap home routers preferred by alt.internet.wireless users are limited to /24 networks mostly thanks to limited ARP table memory space. The routers just can't handle larger networks. I think it fair to say that .0 is not a valid IP for such small routers. (Yeah, I know that assumptions are the mother of all screwups).

• I think you're right. And by being directed broadcast I think it gets to ping your inside network broadcast addresses so that every host so configured to respond would respond... and that flood is sent back to an attack victim which is not the sender. Many of these are done together to really DoS the victim. I believe that most Internet routers block this at the ISP/backbone level before it even gets to you. I wouldn't think that a small home router would need to block that.

• Exactly... Nice info.!

• It makes a difference because, for example, 192.168.0.0 /23 is the following subnet:

Subnet Mask Subnet Size Host Range Broadcast

192.168.0.0 255.255.254.0 510 192.168.0.1 to 192.168.1.254 192.168.1.255

The all zeroes or network is on 192.168.0.0, the all ones or broadcast is on

192.168.1.255

Inbetween lies 192.168.1.0, which in this context (a /23) isn't being looked at like a network address for the old class C (or now /24), but as a single IP Address. And it's quite valid to do this with even an RFC 1918 chunk... on someones "private" network. Although I doubt, as you do, that most on here or anywhere would do that. It's fun though ;-)

(This address is probably not "all ones" because actually you are using 9 bits for Host portion instead of just 8. The "1." or "1.0" has a 1 in it.

192 11000000

168

10101000

1

00000001

0

00000000

11000000.10101000.00000001.00000000 N---------------------------->H---------->)

• That probably doesn't line up correctly in here. But subnet calculator with CIDR will show that.

• Probably don't have that in SunOS/Solaris either. I'll have to fire up my Solaris 9 Intel lab and try it.

• Yep... but you might be right about the memory issue. And you're definately right about most home router users... And you definately know you're RF stuff, which I've been enjoying on here by the way.

"Alan Spicer" hath wroth:

I'm always right. Well... maybe usually right.

Looks like Smurf is alive and well:

Old exploits never die and just fade away.

Try the Smurf test probe. My DD-WRT SP3 v3 6/20/2007 box yielded: Your probe of 63.249.85.127/24 yielded the following results: Network: 63.249.85.0, Netmask: 255.255.255.0, Broadcast:

63.249.85.255, Responded: Yes (broadcast=1, network=1), Duplicates: 0 CONCLUSION: The network responded, but returned no dups. OK network.

It could flood the LAN if the ACL (access control list) did not block RFC1918 non-routeable IP's. If the packets source IP were to appear to be coming from the inside LAN, it would create a very effective DoS attack but for only trashing the inside LAN. There would be no return IP pointing to any outside IP's. Something like this, where the router bocks inbound traffic on IP's known to be on the inside LAN and are therefore subject to source IP spoofing: # access-list 101 deny ip host 0.0.0.0 any log # access-list 101 deny ip 10.0.0.0 0.255.255.255 any log # access-list 101 deny ip 172.16.0.0 0.15.255.255 any log # access-list 101 deny ip 192.168.0.0 0.0.255.255 any log # access-list 101 deny ip 127.0.0.0 0.255.255.255 any log # access-list 101 deny ip host 255.255.255.255 any log # access-list 101 deny ip 169.254.0.0 0.0.255.255 any log # access-list 101 deny ip 0.0.0.0 0.255.255.255 any log followed by a list of allows. I lifted this from the Cisco router FAQ on DSLReports.

Agreed. However, I'm not a router expert and am not sure it works this way. Incidentally, PC Flank router exploits test:

I can hang a few routers and firmware versions with some of these tests. Sorry, but no Smurf test:

Incidentally, a router that responds to broadcast address from outside ICMP redirects is called a "smurf amplifier". One packet in can yields 255 packets out per broadcast address.

OK, so far so good.

Looked at by what like a network address? When I apply a bit wise netmask to a address, everything that's a 1 in 255.255.254.0 gets converted to zeros. In this case, I have 23 binary zeros, followed by

9 valid bits. In the more common case of 255.255.255.0, I get 24 binary zeros, followed by 8 valid bits. However, in BOTH cases, all the bits are zero so there's no way for the PAD (packet assembler/dissembler) to distinguish between these two cases. I'm lost, but suspect I'm missing something obvious (or dumb) as I know that some systems are using .0 as a valid IP. I'll do some reading and playing with a netmask calculator, later.

Also -b is not available in FreeBSD.

I usually use fping for MSDOS in order to get better timing resolution.

It uses -b for: -b : beep on every successful reply (- to beep on timeout) No options for broadcasts. Oh well.

At least it doesn't screw up like Windoze ping and Unix: C:\\>fping 192.168.111.0 Fast pinger version 2.16 (c) Wouter Dhondt

Pinging 192.168.111.0 with 32 bytes of data every 1000 ms: 192.168.111.0: request timed out 192.168.111.0: request timed out (etc...)

More than you ever needed (or wanted) to know about ping:

Many cheap wireless routers don't even have enough table space and scratch RAM to handle a minimal number of connections. For example, note the rather limited number of connections allowed by some bottom of the chart routers:

I confirmed some of the numbers with a home made simulator that will rapidly rotate through a list of MAC addresses, thus simulating multiple simultaneous connections.

Also, your answers to wireless questions are also quite good. I've been waiting for you to make a mistake, so I can pounce, but haven't found any yet.

"Alan Spicer" hath wroth:

No. I forgot to include the /32 and the tester defaulted to /24. With the proper /32 mask, I get: Your probe of 63.249.85.127/32 yielded the following results: Network: 63.249.85.127, Netmask: 255.255.255.255, Broadcast: 63.249.85.127, Responded: Yes (broadcast=1, network=1), Duplicates: 0 CONCLUSION: The network responded, but returned no dups. OK network. Sorry for the muddle.

Port scans and NMAP probes are so common these daze that unless it's being done continuously, nobody notices. I think I see about 3 of these per week, some lasting for hours.

It's as easy as learning to count binary on one finger.

I cross over all 4 pairs so that my crossover cable works with Gigabit ethernet. The only reason to leave two pairs straight through is if you're sharing the CAT5 with POTS lines. See 2nd chart at:

Free IP and netmask calculator.

I'm still lost|confused|bugged as to why .0 doesn't work with /24 but allegedly does with /23. If you remove the decimal points, and treat the IP address as a single 32 bit binary number, there's no obvious difference between /24 and /23 networks. /23 is just using more bits than /24. Otherwise, they're identical in form and function. The address is still ending in all zeros in both cases, just different lengths. I'm probably missing something basic or obvious here and need to hit the books and do some testing. Give me a few days.