Steve Dispensa wrote: > > A couple of amplifications: And a few more comments. See below.
> > On Sun, 2003-03-16 at 20:51, Priscilla Oppenheimer wrote: > > Alan Stone wrote: > > > > > > Hi.. Group > > > > > > I always heard of those hacker spoof a IP and hack other > people > > > system. Does spoof IP mean they are changing their source > IP > > > so that they pass thru firewall? If yes, may I know what > tool > > > can they use in order to change their source IP > ... > > To change your address, use the TCP/IP Control Panel or > equivalent in the > > operating system that you are using. > > More commonly (in my experience) people (skr1pt k1dd3z) use > some stupid > program on a UNIX computer that writes to the network on a raw > socket. > This way the administrator of the system doesn't have to know > (as long > as the user has root - required for raw sockets). Good point. And I like your spelling for the "scribble brats." :-) > > > You probably won't get through any firewalls, though. > Firewalls make sure an > > outsider isn't using an inside address. Routers ensure this > too. It can be > > easily accomplished with a simple access list. > > Those ACLs are far less common in enterprises than one would > hope. > Routers should do ingress filtering, but if the attacker > chooses just a > random address, it won't be in the filter list. What you're talking about certainly happens. But the term "IP spoofing" generally means that the attacker's address isn't random. At least that was its original meaning. The attacker's address is an address from your assigned range. You just have to do a deny on any packets coming in with a source address that matches your inside (real) address, unless my brain is fried from too much green beer. Also, all of us, as good network citizens, should be denying any packets going out that don't have a source address that matches our real inside address. That won't protect us, but it will protect others from one of our inside users being a jerk. > Most of the > packet > floods I've been on the business end of have been completely > random > addresses. In fact, some of them pick a random address per > packet. On > networks that do ingress filtering, the user may only have to > pick an > address in the network's range, which will often still disguise > his true > identity. > > > Even before firewalls and routers watched for this, IP > spoofing didn't mean > > you could hack much unless you had additional hacking > abilities. You had to > > spoof the IP address of a trusted host and you had to be > running software > > that didn't care that you didn't see any replies. The replies > go to the > > legitimate holder of the IP address. > > Another scenario is the above-mentioned packet flood attack, > which still > happens every day to somebody. Outside of SYN floods, this is > usually > done with non-TCP datagrams, and the sender never reallly cares > about > responses. Yes, SYN floods are definitely a problem and they can't be stopped just by avoiding IP spoofing. But other measures can be used, of course. > > A special case of this is the smurf attack - the attacker > writes the > address of the victim host into the source address field and > sends a big > directed-broadcast ping to a big network. Each host on the > network > sends a big response to the victim, chewing up most/all of its > bandwidth. We got hit by something like this a few years ago. Let's see if I remember how it went. The first clue was that our T1, which had never even approached saturation, was starting to approach saturation. We discovered that our hosts were receiving gazillions of ping replies, despite never having sent a ping. Someone was spoofing our addresses and making it look like we were sending pings. A filter solved the problem. Plus a co-worker somehow managed to track down the attacker's ISP and get him in trouble. I don't remember how he did that. He's a genius type. > > As Priscilla pointed out, hijacking attacks are pretty > difficult these > days, given the ISN randomization and ingress filtering that > many I love to talk about the initial sequence number (ISN) randomization. The reason I like to talk about it is because most of the books that describe it mess it up so badly that a casual reader couldn't possibly understand it! :-) For one thing, they make it sound like every TCP sequence number is randomized. Well, that would completely break TCP. The goal is to make sure a hacker can't guess TCP sequence numbers. If you can suceed with that goal, that's a good thing. The downside is that "randomizing" TCP sequence numbers is expensive in its use of resources (processing and memory mainly). Cisco PIX firewall documentation says not to enable the TCP sequence number randomization if something else is already doing it. The documentation doesn't explain this strange warning and then goes on to say, we strongly advise not disabling the TCP sequence number randomization. Well, I advise disabling it if there are any performance or interoperability concerns for two reasons: 1) It's likely something else IS randomizing the sequence number. Every modern operating system does, so the end hosts are probably already doing it. However, this is somewhat new. If your hosts are using older operating sytems, there's a problem. If you allow TCP connections to a router, (for Telnet, for example), even IOS had some problems with guessable TCP sequence numbers until rather recently. Check Google for lots of info on vulnerabilities related to the TCP initial sequence number on various operating systems. But if you are using modern operating systems, why ask a firewall to randomize TCP sequence numbers again, especially considering the performance hit? 2) If traffic doesn't come back in the same way that it went out, TCP will be broken. The firewall that "randomizes" sequence numbers has to change the ACKs that come back too. Once a firewall randomizes the initial sequence number, it has to track and change TCP sequence numbers and ACKs for the entire session. This is expensive and open to problems if traffic doesn't come back through that firewall. Example hostA ------Firewall/Router--------host B Host A sends SYN, sequence number = 100 Firewall changes sequence number to 2189 Host B receives 2189, sends ACK 2190 Firewall receives ACK, changes it to 101 Firewall forwards ACK to Host A Host A sends 100 bytes of data, seq = 101 Firewall changes seq number to 2190 Host B receives 2190, sends ACK 2290 (it received 100 bytes) Firewall receives ACK, changes it to 201 Firewall forwards ACK to Host B And on and on until the FINs. Do you see how much work that firewall is doing? It has to understand TCP! What if it's a 286 runing IP Chains? ;-) OK, that's all for now. Priscilla > firewalls and routers tend to do. It's usually easier to just > exploit a > security hole directly. > > -sd > > Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=65594&t=65559 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
