SRP is designed to resist both active and passive attacks, how does SRP prevent man-in-middle and packet modification attacks?
SRP is a Password-Authenticated Key Exchange algorithm. One flawed but simple way to see it is that client and server share a secret, on which the algorithm expands; an attacker trying a man-in-the-middle attack does not know the secret, and cannot successfully impersonate either the client or the server (or both, in a true MitM).
What I describe above is "just" using the password as a (pre-shared) key. PAKE algorithms go a bit further, with a lot of mathematics, to be able to tolerate a shared secret of low entropy (namely, the password): an attacker observing the exchange, or even trying to impersonate the client or the server, does not learn anything which would allow him to "try passwords at home" (i.e. he does not get out of the algorithm a hash of the password), something called an offline dictionary attack. This is done with a subtle dance with a classical key exchange and a commitment.
Simplest to understand is Encrypted Key Exchange in which the exchange is a normal Diffie-Hellman, but client and server both "encrypt" what they send with the password. The "encryption" algorithm must be such that decrypting with the wrong password still yields something which looks like a normal DH message (another element of the group). An attacker who wants to run an offline dictionary attack will want to "retarget" a given exchange, by doing something which amounts to "let's imagine that for this past exchange, I had used password P". With EKE, any "retarget" with another password than the one he indeed used leaves the attacker outside of the DH key exchange, preventing him from obtaining the DH session key and testing his password hypothesis.
(I said "simplest to understand", not "simple". It takes some time to cryptographers to wrap their mind around what really happens in PAKE algorithms, which a friend of mine had once described as "a small miracle".)
Anyway, a PAKE algorithm is a key exchange and results in a shared key K. It is still up to client and server to use K to encrypt and protect subsequent data packets, using the usual paraphernalia of symmetric encryption and MAC. This is why SRP is best used as part of SSL/TLS, the latter providing the mechanisms for tunneling long streams of data.