beemer_fan
Gebruiker
- Lid geworden
- 10 mrt 2003
- Berichten
- 245
Dit is toch wel vrij belangrijk voor iedereen die een exchange server heeft draaien.
Er is een nieuwe soort attack waarmee de hackers bezig zijn, geen wormen of virussen, maar spam attacks.
Het komt erop neer dat de hacker zijn probeert te authenticeren op je exchange en van daar uit miljoenen spam e-mails begint te versturen. Dit brengt niet alleen teweeg dat je server natuurlijk veel minder performant wordt, maar je zult kwade e-mails terug krijgen, je exchange komt op een zwarte lijst te staan en als je al helemaal pech hebt, je volledig IP-adres.
Als je gehackt bent, is het niet echt duidelijk te zien, enkel als je auditing voor account-access hebt opgezet.
Beveiligen is gelukkig wel vrij simpel, er staan in het artikel dat ik bijgevoegd heb, 4 beveiligingsmethoden.
Bron:
A worrisome new kind of attack is making the rounds on the
Internet. This new threat isn't a worm like SoBig or Slammer, and it
isn't a virus like Swen--it's an insidious spam attack that victimizes
innocent Exchange Server systems. And this attack is succeeding far
more often than it should.
Spammers are scanning the Internet looking for SMTP servers. These
spammers use retrieved banner information to identify Exchange
servers, then use the SMTP service to mount brute-force
password-guessing attacks against well-known accounts on those
servers. That's right: Instead of attacking the increasingly
well-defended Windows remote procedure call (RPC) services that most
organizations use for logon authentication, this attack sends a
barrage of SMTP AUTH LOGON commands until one succeeds.
"But wait a minute," you say. "Exchange Server 2003 and Exchange
2000 Server have relaying turned off by default!" Yes, they do--for
unauthenticated users. But if a spammer manages to snag an
authenticated user's credentials, the spammer can authenticate to your
server and use it to blast out millions of spam messages. As a
consequence, your server (and possibly your entire IP block) will
likely end up on a variety of blacklists--and you'll probably receive
a flood of angry messages from irate spam recipients. To make matters
worse, all this activity probably will fill your queues and
transaction logs, slowing your server's performance.
This attack's dastardly nature is worsened by the fact that the
attack is mostly invisible unless you've turned on auditing for
account-access events. The SMTP log that the Microsoft IIS SMTP
component maintains doesn't record the use of SMTP AUTH, so you can't
look for a sudden spike in the number of AUTH requests to indicate
that you're under attack. Your first warning sign might be that your
server starts getting waves of spam-generated nondelivery reports
(NDRs). Fortunately, protecting your servers against this attack is a
simple process.
First, make sure that your administrator accounts have strong,
complex passwords with more than 15 characters that are a mix of
letters, numbers, and symbols. (When a password has 16 or more
characters, Windows can't locally store the password's easily-cracked
LM hash.) Other user accounts also should have complex passwords, but
protecting your privileged accounts against brute-force password
guessing is especially important.
Second, if you don't allow relaying, consider turning it off
completely on all external-facing servers. If you do allow relaying, I
suggest you reconsider your decision. For example, if you allow
relaying to support external POP users, consider whether you could
accomplish this task another way (e.g., by using the users' ISPs).
Third, consider disabling both basic and Windows integrated
authentication on any SMTP virtual server that faces the Internet.
Doing so prevents password-guessing attacks, but it also prevents
users from authenticating before sending email. If you must leave this
feature enabled, make sure that you also enable account-object
auditing and regularly monitor the Windows event logs for long series
of event ID 528, which failed logon attempts generate.
Fourth, if you use an Intrusion Detection System (IDS), configure
it to watch for failed SMTP authentication requests (i.e., tell it to
look for the text "535 5.7.3 Authentication unsuccessful" at offset 54
in packets on TCP port 25). This warning will alert you to an
attempted attack.
Microsoft knows about this type of attack and will probably take
measures to protect against it at some point. Until then, keep a
careful eye on your servers to make sure they aren't being attacked.
(And thanks to Andy Webb, who first brought this subject to my
attention.)
Er is een nieuwe soort attack waarmee de hackers bezig zijn, geen wormen of virussen, maar spam attacks.
Het komt erop neer dat de hacker zijn probeert te authenticeren op je exchange en van daar uit miljoenen spam e-mails begint te versturen. Dit brengt niet alleen teweeg dat je server natuurlijk veel minder performant wordt, maar je zult kwade e-mails terug krijgen, je exchange komt op een zwarte lijst te staan en als je al helemaal pech hebt, je volledig IP-adres.
Als je gehackt bent, is het niet echt duidelijk te zien, enkel als je auditing voor account-access hebt opgezet.
Beveiligen is gelukkig wel vrij simpel, er staan in het artikel dat ik bijgevoegd heb, 4 beveiligingsmethoden.
Bron:
A worrisome new kind of attack is making the rounds on the
Internet. This new threat isn't a worm like SoBig or Slammer, and it
isn't a virus like Swen--it's an insidious spam attack that victimizes
innocent Exchange Server systems. And this attack is succeeding far
more often than it should.
Spammers are scanning the Internet looking for SMTP servers. These
spammers use retrieved banner information to identify Exchange
servers, then use the SMTP service to mount brute-force
password-guessing attacks against well-known accounts on those
servers. That's right: Instead of attacking the increasingly
well-defended Windows remote procedure call (RPC) services that most
organizations use for logon authentication, this attack sends a
barrage of SMTP AUTH LOGON commands until one succeeds.
"But wait a minute," you say. "Exchange Server 2003 and Exchange
2000 Server have relaying turned off by default!" Yes, they do--for
unauthenticated users. But if a spammer manages to snag an
authenticated user's credentials, the spammer can authenticate to your
server and use it to blast out millions of spam messages. As a
consequence, your server (and possibly your entire IP block) will
likely end up on a variety of blacklists--and you'll probably receive
a flood of angry messages from irate spam recipients. To make matters
worse, all this activity probably will fill your queues and
transaction logs, slowing your server's performance.
This attack's dastardly nature is worsened by the fact that the
attack is mostly invisible unless you've turned on auditing for
account-access events. The SMTP log that the Microsoft IIS SMTP
component maintains doesn't record the use of SMTP AUTH, so you can't
look for a sudden spike in the number of AUTH requests to indicate
that you're under attack. Your first warning sign might be that your
server starts getting waves of spam-generated nondelivery reports
(NDRs). Fortunately, protecting your servers against this attack is a
simple process.
First, make sure that your administrator accounts have strong,
complex passwords with more than 15 characters that are a mix of
letters, numbers, and symbols. (When a password has 16 or more
characters, Windows can't locally store the password's easily-cracked
LM hash.) Other user accounts also should have complex passwords, but
protecting your privileged accounts against brute-force password
guessing is especially important.
Second, if you don't allow relaying, consider turning it off
completely on all external-facing servers. If you do allow relaying, I
suggest you reconsider your decision. For example, if you allow
relaying to support external POP users, consider whether you could
accomplish this task another way (e.g., by using the users' ISPs).
Third, consider disabling both basic and Windows integrated
authentication on any SMTP virtual server that faces the Internet.
Doing so prevents password-guessing attacks, but it also prevents
users from authenticating before sending email. If you must leave this
feature enabled, make sure that you also enable account-object
auditing and regularly monitor the Windows event logs for long series
of event ID 528, which failed logon attempts generate.
Fourth, if you use an Intrusion Detection System (IDS), configure
it to watch for failed SMTP authentication requests (i.e., tell it to
look for the text "535 5.7.3 Authentication unsuccessful" at offset 54
in packets on TCP port 25). This warning will alert you to an
attempted attack.
Microsoft knows about this type of attack and will probably take
measures to protect against it at some point. Until then, keep a
careful eye on your servers to make sure they aren't being attacked.
(And thanks to Andy Webb, who first brought this subject to my
attention.)
