Hack attempt by Bandview.net??[2nd update] False alarm

Assimilator1

Elite Member
Nov 4, 1999
24,165
524
126
I dialled up to the net ,had Zone Alarm running & immediatly I get a popup alert blocking access to 64.119.200.215 ,then another & another!.....,in the meantime I decide to do a tracert to get some idea of who it is ,this is what I got (doh dunno how to scroll up in a DOS box!:eek:)

12 252 ms 257 ms 262 ms so-0-0-0.mpr4.sjc2.us.mfnx.net [64.125.30.2]
13 288 ms 256 ms 258 ms pos8-0.mpr1.sjc2.us.mfnx.net [208.184.102.201]
14 269 ms 268 ms 256 ms pos0-0.mpr2.lax2.us.mfnx.net [208.185.156.126]
15 256 ms 253 ms 261 ms pos2-0.cr2.lax3.us.mfnx.net [208.184.233.22]
16 273 ms 258 ms 257 ms pos1-0.pr1.lax3.us.mfnx.net [208.184.233.58]
17 254 ms 258 ms 263 ms 204.255.169.53
18 329 ms 253 ms 277 ms 0.so-0-3-0.XL2.LAX9.ALTER.NET [152.63.115.6]
19 280 ms 251 ms 262 ms 0.so-3-0-0.XR2.LAX9.ALTER.NET [152.63.115.165]
20 273 ms 271 ms 262 ms 190.at-0-0-0.CL2.SDG2.ALTER.NET [152.63.112.33]
21 273 ms 252 ms 262 ms 194.ATM6-0.GW2.SDG1.ALTER.NET [146.188.249.85]
22 277 ms 273 ms 279 ms internap2-sdg.customer.alter.net [157.130.233.14]
23 269 ms 278 ms 279 ms border2.fe2-0-bbnet2.sdg.pnap.net [63.251.127.6]
24 332 ms 258 ms 263 ms iway-2.border2.sdg.pnap.net [63.251.125.122]
25 291 ms 268 ms 279 ms bbr1.sdg-lax.atm4.iwaynetworks.com [64.119.206.49]
26 332 ms 279 ms 277 ms bbr1.lax-sdg.atm4.iwaynetworks.com [64.119.206.54]
27 282 ms 272 ms 278 ms bandview.net [64.119.200.215]

Trace complete.

I go to www.bandview.net & sure enough its a website about domain name registration.
If you go their be careful because it tries to reset your homepage,install programs & you get several pop up windows!.

Btw after this I ended up with 57 popup alerts! :|,it only stopped when I disconnected & re-dialled

Anything I can do about them?



 

MainFramed

Diamond Member
May 29, 2002
5,981
1
0
try downloading a pop up stopper from the web, i have been looking for one when i find one that works i will let you know;) i hate the pop-ups as well:|
 

RaySun2Be

Lifer
Oct 10, 1999
16,565
6
71
here4amission,
I think the Pop Up Alerts Assimilator1 is talking about are ZoneAlarm alerts that it blocked access to his PC from an outside source.

However, since you are looking for a popup stopper, try Pop-Up Stopper at PanicWare

I use it and it does a great job of blocking popup ads. And you can still get to things you want. I've had no problems with it at all. :)


Assimilator1,
As far as the intrusion, do you have logging turned on? What ports were they trying to come through on? You might do a WHOIS lookup on that domain to see who it is registered too, as well as post a formal complaint to their ISP provider, as well as send the information to the authorities.


A WHOIS on bandview.net returned the following info:
Registrant:
Bandview
332524 Rosecrans Pl
Manhattan Beach, CA 90266
US

Domain Name: BANDVIEW.NET

Administrative Contact:
Shorts, Nick abuse@bandview.net
332524 Rosecrans Pl
Manhattan Beach, CA 90266
US
3102052430

Technical Contact:
Shorts, Nick abuse@bandview.net
332524 Rosecrans Pl
Manhattan Beach, CA 90266
US
3102052430



Registration Service Provider:
Low Cost Domains, support@lowcostdomains.com
http://www.lowcostdomains.com


Registrar of Record: TUCOWS, INC.
Record last updated on 23-Apr-2002.
Record expires on 22-Apr-2003.
Record Created on 22-Apr-2002.

Domain servers in listed order:
NS.LOWCOSTDOMAINS.COM 216.226.138.100
NS2.LOWCOSTDOMAINS.COM 216.226.138.101
 

Spacehead

Lifer
Jun 2, 2002
13,067
9,858
136
I always wondered if anything could be done about ZA alerts also. The last few months, port 1214 has been getting hammered, big time! I think one night there were over 100 alerts in less than an hour & a half!

Thanks for the 'whois' link there RaySon. That may come in handy.

I'm sure glad i have ZA!
 

n0cmonkey

Elite Member
Jun 10, 2001
42,936
1
0
Assimilator1, without more information there is nothing we can do for you. Give us some of the logs these guys created. We would need atleast some port numbers. Its probably a false positive though. :)

I got no popups or anything when trying to view their page. Yet another reason Mozilla rocks ;)
 

n0cmonkey

Elite Member
Jun 10, 2001
42,936
1
0
Originally posted by: Spacehead
I always wondered if anything could be done about ZA alerts also. The last few months, port 1214 has been getting hammered, big time! I think one night there were over 100 alerts in less than an hour & a half!

Thanks for the 'whois' link there RaySon. That may come in handy.

I'm sure glad i have ZA!

Thats Kazaa's port.
 

Assimilator1

Elite Member
Nov 4, 1999
24,165
524
126
I forgot to mention those 57 alerts came in a space of about 5mins!

here4amission
I was referring to the block alerts by Zone alarm ,;) I already have a pop up stopper.

n0cmonkey & Ray
Here's the section of the log dealing with Bandview.net

FWIN,2002/06/21,16:59:52 +1:00 GMT, 64.119.200.215:53985, 62.252.188.58:1080,TCP (flags:S)
FWIN,2002/06/21,16:59:53 +1:00 GMT, 64.119.200.215:53885, 62.252.188.58:1080,TCP (flags:S)
FWIN,2002/06/21,16:59:54 +1:00 GMT,64.119.200.215:54085,62.252.188.58:1080,TCP (flags:S)
FWIN,2002/06/21,16:59:59 +1:00 GMT,64.119.200.215:54185,62.252.188.58:1080,TCP (flags:S)
FWIN,2002/06/21,17:00:04 +1:00 GMT,64.119.200.215:54285,62.252.188.58:1080,TCP (flags:S)
FWIN,2002/06/21,17:00:09 +1:00 GMT,64.119.200.215:54385,62.252.188.58:1080,TCP (flags:S)
FWIN,2002/06/21,17:00:14 +1:00 GMT,64.119.200.215:54485,62.252.188.58:1080,TCP (flags:S)
FWIN,2002/06/21,17:00:19 +1:00 GMT,64.119.200.215:54585,62.252.188.58:1080,TCP (flags:S)
FWIN,2002/06/21,17:00:24 +1:00 GMT,64.119.200.215:54685,62.252.188.58:1080,TCP (flags:S)
FWIN,2002/06/21,17:00:29 +1:00 GMT,64.119.200.215:54785,62.252.188.58:1080,TCP (flags:S)
FWIN,2002/06/21,17:00:35 +1:00 GMT,64.119.200.215:54885,62.252.188.58:1080,TCP (flags:S)
FWIN,2002/06/21,17:00:40 +1:00 GMT,64.119.200.215:55004,62.252.188.58:1080,TCP (flags:S)
FWIN,2002/06/21,17:00:45 +1:00 GMT,64.119.200.215:55104,62.252.188.58:1080,TCP (flags:S)
FWIN,2002/06/21,17:00:51 +1:00 GMT,64.119.200.215:55204,62.252.188.58:1080,TCP (flags:S)
FWIN,2002/06/21,17:00:56 +1:00 GMT,64.119.200.215:55304,62.252.188.58:1080,TCP (flags:S)
FWIN,2002/06/21,17:01:01 +1:00 GMT,64.119.200.215:55404,62.252.188.58:1080,TCP (flags:S)
FWIN,2002/06/21,17:01:06 +1:00 GMT,64.119.200.215:55504,62.252.188.58:1080,TCP (flags:S)
FWIN,2002/06/21,17:01:11 +1:00 GMT,64.119.200.215:55604,62.252.188.58:1080,TCP (flags:S)
FWIN,2002/06/21,17:01:17 +1:00 GMT,64.119.200.215:55704,62.252.188.58:1080,TCP (flags:S)
FWIN,2002/06/21,17:01:22 +1:00 GMT,64.119.200.215:55804,62.252.188.58:1080,TCP (flags:S)
FWIN,2002/06/21,17:01:27 +1:00 GMT,64.119.200.215:55904,62.252.188.58:1080,TCP (flags:S)
FWIN,2002/06/21,17:01:32 +1:00 GMT,64.119.200.215:56004,62.252.188.58:1080,TCP (flags:S)
FWIN,2002/06/21,17:01:37 +1:00 GMT,64.119.200.215:56104,62.252.188.58:1080,TCP (flags:S)
FWIN,2002/06/21,17:01:41 +1:00 GMT,64.119.200.215:56200,62.252.188.58:1080,TCP (flags:S)
FWIN,2002/06/21,17:01:46 +1:00 GMT,64.119.200.215:56300,62.252.188.58:1080,TCP (flags:S)
FWIN,2002/06/21,17:01:52 +1:00 GMT,64.119.200.215:56400,62.252.188.58:1080,TCP (flags:S)
FWIN,2002/06/21,17:01:57 +1:00 GMT,64.119.200.215:56500,62.252.188.58:1080,TCP (flags:S)
FWIN,2002/06/21,17:02:02 +1:00 GMT,64.119.200.215:56600,62.252.188.58:1080,TCP (flags:S)
FWIN,2002/06/21,17:02:07 +1:00 GMT,64.119.200.215:56700,62.252.188.58:1080,TCP (flags:S)
FWIN,2002/06/21,17:02:12 +1:00 GMT,64.119.200.215:56800,62.252.188.58:1080,TCP (flags:S)
FWIN,2002/06/21,17:02:17 +1:00 GMT,64.119.200.215:56900,62.252.188.58:1080,TCP (flags:S)
FWIN,2002/06/21,17:02:21 +1:00 GMT,64.119.200.215:57000,62.252.188.58:1080,TCP (flags:S)
FWIN,2002/06/21,17:02:27 +1:00 GMT,64.119.200.215:57100,62.252.188.58:1080,TCP (flags:S)
FWIN,2002/06/21,17:02:32 +1:00 GMT,64.119.200.215:57200,62.252.188.58:1080,TCP (flags:S)
FWIN,2002/06/21,17:02:37 +1:00 GMT,64.119.200.215:57300,62.252.188.58:1080,TCP (flags:S)
FWIN,2002/06/21,17:02:44 +1:00 GMT,64.119.200.215:57406,62.252.188.58:1080,TCP (flags:S)
FWIN,2002/06/21,17:02:48 +1:00 GMT,64.119.200.215:57506,62.252.188.58:1080,TCP (flags:S)
FWIN,2002/06/21,17:02:54 +1:00 GMT,64.119.200.215:57606,62.252.188.58:1080,TCP (flags:S)
FWIN,2002/06/21,17:02:59 +1:00 GMT,64.119.200.215:57706,62.252.188.58:1080,TCP (flags:S)
FWIN,2002/06/21,17:03:04 +1:00 GMT,64.119.200.215:57806,62.252.188.58:1080,TCP (flags:S)
FWIN,2002/06/21,17:03:08 +1:00 GMT,64.119.200.215:57906,62.252.188.58:1080,TCP (flags:S)
FWIN,2002/06/21,17:03:13 +1:00 GMT,64.119.200.215:58006,62.252.188.58:1080,TCP (flags:S)
FWIN,2002/06/21,17:03:18 +1:00 GMT,64.119.200.215:58106,62.252.188.58:1080,TCP (flags:S)
FWIN,2002/06/21,17:03:23 +1:00 GMT,64.119.200.215:58206,62.252.188.58:1080,TCP (flags:S)
FWIN,2002/06/21,17:03:28 +1:00 GMT,64.119.200.215:58306,62.252.188.58:1080,TCP (flags:S)
FWIN,2002/06/21,17:03:33 +1:00 GMT,64.119.200.215:58406,62.252.188.58:1080,TCP (flags:S)
FWIN,2002/06/21,17:03:38 +1:00 GMT,64.119.200.215:58506,62.252.188.58:1080,TCP (flags:S)
FWIN,2002/06/21,17:03:44 +1:00 GMT,64.119.200.215:58615,62.252.188.58:1080,TCP (flags:S)
FWIN,2002/06/21,17:03:49 +1:00 GMT,64.119.200.215:58715,62.252.188.58:1080,TCP (flags:S)
FWIN,2002/06/21,17:03:54 +1:00 GMT,64.119.200.215:58815,62.252.188.58:1080,TCP (flags:S)
FWIN,2002/06/21,17:03:59 +1:00 GMT,64.119.200.215:58915,62.252.188.58:1080,TCP (flags:S)
FWIN,2002/06/21,17:04:04 +1:00 GMT,64.119.200.215:59015,62.252.188.58:1080,TCP (flags:S)
FWIN,2002/06/21,17:04:08 +1:00 GMT,64.119.200.215:59115,62.252.188.58:1080,TCP (flags:S)
FWIN,2002/06/21,17:04:13 +1:00 GMT,64.119.200.215:59215,62.252.188.58:1080,TCP (flags:S)
FWIN,2002/06/21,17:04:19 +1:00 GMT,64.119.200.215:59315,62.252.188.58:1080,TCP (flags:S)
FWIN,2002/06/21,17:04:24 +1:00 GMT,64.119.200.215:59415,62.252.188.58:1080,TCP (flags:S)
FWIN,2002/06/21,17:04:28 +1:00 GMT,64.119.200.215:59515,62.252.188.58:1080,TCP (flags:S)


See how many ports they tried?!:Q

Spacehead
Glad I have ZA too :) ,btw my 57 alerts came in just 5mins!:Q
 

n0cmonkey

Elite Member
Jun 10, 2001
42,936
1
0
Assimilator1 Im guessing your ip address is 62.252.188.58? They only checked 1 port, 1080. It looks like someone was looking for a proxy server on your ip, maybe a wingate. Wingates are useful for hiding your ip when you are doing something you shouldnt be... Anyhow, email abuse@bandview.net (hopefully that works since they didnt seem to list it on their site) and block the ip. I wouldnt worry about it too much. BTW, send them the logs you showed and mention that you are GMT (or whatever timezone you happen to be in).

cc abuse@iway.com on that email. The whois on that ip address turned up iway.com too. They seem to be some kind of cyber cafe.
 

Assimilator1

Elite Member
Nov 4, 1999
24,165
524
126
62.252.188.58 is the IP I was on that day (I'm on dialup),I've never heard of Wingate before & I don't run it ,so why would they be looking for it on my PC?:confused:
Why were they going out on a different port each time?

The whois on that ip address turned up iway.com too. They seem to be some kind of cyber cafe

Are you saying there are websites that are using the same IP?:confused: ,I don't get it ,when I did a tracert it showed bandview.net
I looked for an email on their site to complain to but couldn't find any:| ,I'll try abuse@bandview.net

Thanks for the help so far btw:)
 

Staver

Senior member
Oct 10, 1999
909
0
76
Here is a nice Zone Alarm add-on Log Viewer. It's free and helps maker better sense of what is going on in ZA. It also adds backtrace which ZA lacks. Another program is MyNetWatchMan. It will auto submit reports to ISPs for you as will the Log Viewer.
 

Barnaby W. Füi

Elite Member
Aug 14, 2001
12,343
0
0
Originally posted by: Assimilator1

See how many ports they tried?!:Q
nah the different port numbers are on their end, they were only trying 1080 on you. personally i dont even care who's trying to do what to me (ok thats an exaggeration but just follow me here ;)). i filter out anyone who's annoying (hello nimda) and just drop the packets. it'd take forever to try to contact all the internet llamas and their ISP's, and even then i doubt much would happen. the internet is like the wild west! (yeeehaw!)
 

Descartes

Lifer
Oct 10, 1999
13,968
2
0
You were caused no harm. Look at the log entry...

FWIN,2002/06/21,16:59:52 +1:00 GMT, 64.119.200.215:53985, 62.252.188.58:1080,TCP (flags:S)

See the "flags:S" in parenthesis? In TCP vernacular, an S flag is a SYN flag. A SYN flag is just a bit turned on in the TCP header itself to indicate that an attempt to connect was made. Since you have no service actually listening on port 1080, your TCP stack returned a packet with the R flag (RST, or reset).
A few things are easily discernable with this log...

This is neither a manual attempt to attack, nor an automated one. If this were a manual attack, a port scan would be the first thing you saw, and they wouldn't attempt to connect to a service that didn't exist that many times. If the attacker were running software that automated the attack it would have ceased operation upon receiving the first RST packet. It wouldn't just keep drilling your machine with a SYN packet attempting to establish a connection with a service that doesn't exist. The only reason you would see that many SYN packets sent to a given port is when you have a legitimate service running is when the attacker was attempting to "fill in" your connection backlog, canonically referred to as a SYN flood. This isn't the case. You'll also note that each attempt to connect used a different port. These ports are dynamically allocated by the implementing TCP/IP stack (known as ephemeral ports). This indicates that the client did indeed receive an RST packet from your stack and abandoned the connection attempt. With all this in mind, the most logical explanation is that someone was running some legitimate client software that utilized a service that resides on port 1080 (you can't tell what service they were looking for unless you logged the packets) and they mistyped the ip address/hostname.

 

MainFramed

Diamond Member
May 29, 2002
5,981
1
0
Originally posted by: RaySun2Be
here4amission,
I think the Pop Up Alerts Assimilator1 is talking about are ZoneAlarm alerts that it blocked access to his PC from an outside source.

However, since you are looking for a popup stopper, try Pop-Up Stopper at PanicWare

I use it and it does a great job of blocking popup ads. And you can still get to things you want. I've had no problems with it at all.


i have tried to use this pop up stopper on my computer ( Xp Pro) and it doesnt work @ all. i have it enabled but it dont work.


Assimilator1,
i thought you had millions of pop up adds coming...sorry bout that:eek:
 

Batti

Golden Member
Feb 2, 2000
1,608
0
0
Excellent synopsis, Descartes!!! Nice job of demonstrating what you can discern from a log.

 

n0cmonkey

Elite Member
Jun 10, 2001
42,936
1
0
Originally posted by: Assimilator1
62.252.188.58 is the IP I was on that day (I'm on dialup),I've never heard of Wingate before & I don't run it ,so why would they be looking for it on my PC?:confused:
Why were they going out on a different port each time?

The whois on that ip address turned up iway.com too. They seem to be some kind of cyber cafe

Are you saying there are websites that are using the same IP?:confused: ,I don't get it ,when I did a tracert it showed bandview.net
I looked for an email on their site to complain to but couldn't find any:| ,I'll try abuse@bandview.net

Thanks for the help so far btw:)

Descartes pretty much covered it (although Im not in 100% agreement with everything he said, but I definitely agree it looks like a misconfiguration). And yes, different sites can use the same ip address, look at virtual sites (?) in apache.
 

Assimilator1

Elite Member
Nov 4, 1999
24,165
524
126
Descartes
Thanks for the info :) ,though I didn't undertsand some of it! :eek: ,I guess I can relax knowing it wasn't a hack attempt :)

The only reason you would see that many SYN packets sent to a given port is when you have a legitimate service running is when the attacker was attempting to "fill in" your connection backlog, canonically referred to as a SYN flood

That's the bit that lost me!;)
 

n0cmonkey

Elite Member
Jun 10, 2001
42,936
1
0
Originally posted by: Assimilator1
Descartes
Thanks for the info :) ,though I didn't undertsand some of it! :eek: ,I guess I can relax knowing it wasn't a hack attempt :)

The only reason you would see that many SYN packets sent to a given port is when you have a legitimate service running is when the attacker was attempting to "fill in" your connection backlog, canonically referred to as a SYN flood

That's the bit that lost me!;)

You have 3 machines. Each one can handle 1 seti wu at a time. For some reason, someone from another team sends you 6 fake seti wus to work on. Your machines are too busy with those wus to work on real ones. A syn flood ties up your machine from doing what it should be doing, much like these fictional fake seti wus would do. Make a little more sense?
 

Descartes

Lifer
Oct 10, 1999
13,968
2
0
The only reason you would see that many SYN packets sent to a given port is when you have a legitimate service running is when the attacker was attempting to "fill in" your connection backlog, canonically referred to as a SYN flood

That's the bit that lost me!

I'll expound...

First some foundational information. In the TCP world you have what's called the three-way handshake. I'm probably patronizing you with this information, but I'll repeat it just in case. The three-way handshake consists of the transfer of three packets between the server and client. When a client does an active open (we won't get into active vs. passive opens), it sends a packet with the SYN bit on in the TCP header to the server. The SYN bit simply tells the server to synchronize the sequence numbers with the client. The server will then, if it can/wants to establish a connection, send a SYN-ACK. That just acknowledges the previous SYN. The client will then send a final ACK, acknowledging the previously received SYN-ACK. At this point the connection is established until the first FIN packet is sent by either endpoint.

Each implementing TCP/IP stack has a queue for incoming connections, sometimes called the backlog which I referred to earlier. When a server's TCP/IP stack receives a SYN packet (connection request), it will execute a simple algorithm to determine whether or not the connection can be fulfilled. On BSD-derived implementations, the backlog is usually around 5 or so, but that's changed over time. If the server can fulfill the request (queued connections < maximum), it will send the SYN-ACK to the client. At this point, the server waits patiently for the final ACK from the client. This is where the potential for a SYN flood comes in. If a given client were to send enough SYN packets to the server to max out it's backlog *without* ACKing any of the SYN-ACKs, you have effectively encumbered the service from fulfilling connections with legitimate clients. Even worse, most TCP/IP implementations will not send anything to the client when this connection backlog is full, it simply doesn't respond. This is why you see clients that resend SYN packets over and over in an attempt to establish a connection.

That's actually simple to perform, but one normally doesn't stop there. Obviously you wouldn't want to leave your IP address in the IP header when you send these SYN packets to the server, so you spoof it. There are different types of spoofing, but in this case it's extremely simple. If you modified the source IP in the IP header of the packet you send to the server, it has no way to know where the connection requests originated. There's a problem here, however. The server will send a SYN-ACK to the source IP you spoofed in the IP header. Why is this bad? When the host you spoofed receives the SYN-ACK from the server which received your spoofed SYN packet, it will respond with a RST packet indicating it has no idea where this packet came from. When that happens, the server will effectively "throw out" the connection from the queue. One would need to spoof the IP address of a host that is down.

In summary, if you send enough SYN packets to a given server with a spoofed source IP address referencing a host that is not be able to respond with a RST packet to exceed the total queueable connections (backlog) you will have succeeded in SYN flooding the server.

Also note that different TCP/IP implementations have different algorithms to determine the total number of queueable connections, and some even respond differently when their backlog is full. These implementation nuances are how OS fingerprinting tools work; they encapsulate the known nuances of disparate TCP/IP implementations to discern the target OS. Windows systems are the most notably deviant in their implementations, so you can usually discern whether or not your target is a Windows box by sending a simple FIN packet, for example.

Sorry for the long post, I get carried away at times. Hope that made sense...
 

Assimilator1

Elite Member
Nov 4, 1999
24,165
524
126
n0cmonkey
Now your talking my language;) ,I think I've got it on a basic level:)

Descartes
You're not patronising me ,so don't worry:) ,this all new to me ,I'll read it all when I have time ,dinner is soon;)