Jump to content

GraemeL

Membera
  • Content Count

    173
  • Joined

  • Last visited

Everything posted by GraemeL

  1. GraemeL

    exchange 2003 sp2 server dnsbl problem

    OK, I see your problem now. This is going to be pretty technical, but it should make sense to your IT staff. The replies are correct given the queries that your server is sending, but the queries are meaningless. When querying a blocklist, the quads are reversed. If I want to test the IP address 127.0.0.2, the query actually gets sent as 2.0.0.127.sbl-xbl.spamhaus.org. So the IP address you are querying isn't 15.103.16.10 (which does belong to HP) but 10.16.103.15 which is in IANA reserved space. This would seem to indicate that the mail server that you're attempting to do the lookups from doesn't receive mail directly from the internet, but instead gets it from another server which is connected to the internet and then relays it over your internal network. Since the sort of lookups that you're attempting only ever check the address of the machine that is involved in the current SMTP transaction, all your lookups will be for 10.16.103.15. One solution would be to do the RBL checks on the external gateway. I'm assuming that your setup looks something like this: Internal server <---> External gateway <---> Internet So all checks on the internal server will always check the address of the external gateway. If you can do the tests at the external gateway, you will be testing the address of the machine on the internet that is trying to send you mail.
  2. GraemeL

    exchange 2003 sp2 server dnsbl problem

    Here are responses to an unlisted and a listed address formatted by dig. You can see how the formatted data relates to what you're seeing in your packet captures. Unlisted dig 1.0.0.127.zen.spamhaus.org ; &lt;&lt;&gt;&gt; DiG 9.3.1 &lt;&lt;&gt;&gt; 1.0.0.127.zen.spamhaus.org ;; global options: printcmd ;; Got answer: ;; -&gt;&gt;HEADER&lt;&lt;- opcode: QUERY, status: NXDOMAIN, id: 63664 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;1.0.0.127.zen.spamhaus.org. IN A ;; AUTHORITY SECTION: zen.spamhaus.org. 900 IN SOA need.to.know.only. hostmaster.spamhaus.org. 2007120407 3600 600 432000 900 ;; Query time: 193 msec ;; SERVER: 195.7.224.57#53(195.7.224.57) ;; WHEN: Tue Dec 4 02:00:09 2007 ;; MSG SIZE rcvd: 108 Listed dig 2.0.0.127.zen.spamhaus.org ; &lt;&lt;&gt;&gt; DiG 9.3.1 &lt;&lt;&gt;&gt; 2.0.0.127.zen.spamhaus.org ;; global options: printcmd ;; Got answer: ;; -&gt;&gt;HEADER&lt;&lt;- opcode: QUERY, status: NOERROR, id: 35876 ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 23, ADDITIONAL: 3 ;; QUESTION SECTION: ;2.0.0.127.zen.spamhaus.org. IN A ;; ANSWER SECTION: 2.0.0.127.zen.spamhaus.org. 1357 IN A 127.0.0.10 2.0.0.127.zen.spamhaus.org. 1357 IN A 127.0.0.2 2.0.0.127.zen.spamhaus.org. 1357 IN A 127.0.0.4 ;; AUTHORITY SECTION: zen.spamhaus.org. 46681 IN NS c.ns.spamhaus.org. zen.spamhaus.org. 46681 IN NS d.ns.spamhaus.org. zen.spamhaus.org. 46681 IN NS f.ns.spamhaus.org. zen.spamhaus.org. 46681 IN NS g.ns.spamhaus.org. zen.spamhaus.org. 46681 IN NS h.ns.spamhaus.org. zen.spamhaus.org. 46681 IN NS i.ns.spamhaus.org. zen.spamhaus.org. 46681 IN NS k.ns.spamhaus.org. zen.spamhaus.org. 46681 IN NS l.ns.spamhaus.org. zen.spamhaus.org. 46681 IN NS m.ns.spamhaus.org. zen.spamhaus.org. 46681 IN NS n.ns.spamhaus.org. zen.spamhaus.org. 46681 IN NS o.ns.spamhaus.org. zen.spamhaus.org. 46681 IN NS q.ns.spamhaus.org. zen.spamhaus.org. 46681 IN NS r.ns.spamhaus.org. zen.spamhaus.org. 46681 IN NS s.ns.spamhaus.org. zen.spamhaus.org. 46681 IN NS t.ns.spamhaus.org. zen.spamhaus.org. 46681 IN NS x.ns.spamhaus.org. zen.spamhaus.org. 46681 IN NS y.ns.spamhaus.org. zen.spamhaus.org. 46681 IN NS 1.ns.spamhaus.org. zen.spamhaus.org. 46681 IN NS 3.ns.spamhaus.org. zen.spamhaus.org. 46681 IN NS 4.ns.spamhaus.org. zen.spamhaus.org. 46681 IN NS 8.ns.spamhaus.org. zen.spamhaus.org. 46681 IN NS a.ns.spamhaus.org. zen.spamhaus.org. 46681 IN NS b.ns.spamhaus.org. ;; ADDITIONAL SECTION: 1.ns.spamhaus.org. 10373 IN A 218.189.175.50 1.ns.spamhaus.org. 10373 IN A 220.181.15.205 3.ns.spamhaus.org. 10373 IN A 203.81.36.6 ;; Query time: 72 msec ;; SERVER: 195.7.224.57#53(195.7.224.57) ;; WHEN: Tue Dec 4 02:00:17 2007 ;; MSG SIZE rcvd: 511
  3. GraemeL

    exchange 2003 sp2 server dnsbl problem

    NXDomain is the reply you should expect to see if the IP you are testing is not listed on the blocklist you're testing against.
  4. GraemeL

    Samsung SmartEther SS6016NTT Router

    Not quite sure from your description, but I may have an explanation for you. Early fast ethernet was all 100BASE-T which was half duplex (i.e. single channel over a single twisted pair). This wasn't a problem for most users, but in some applications there was a need for fast bi-directional data exchange. One solution was to make a device with two 100BASE-T connections and tie them together in such a way that they appeared to be a single full duplex interface. One channel for uplink and one channel for downlink. 100BASE-TX came along with full duplex (two channels over two twisted pairs) and made the kit obsolete. Cat-5 contains 4 twisted pairs, so you could run two 100BASE-TX connections over it, splitting out the pairs to two RJ45s at each end or doing some magic in the NIC.
  5. GraemeL

    [Resolved] SPAM Header/Server help!

    You may well still get complaints people using your proxy to comment spam or using it to launch attacks against other systems. I hope your ISP is understanding. I wont even comment on the possible liability issues.
  6. GraemeL

    [Resolved] SPAM Header/Server help!

    David is correct. The open proxy is your problem, kill it and you will stop relaying spam.
  7. GraemeL

    Zen/Spamhaus and abuseat.org lookups

    The cbl (and njabl) data is added to zen (actually to xbl which is included in zen) by regular zone transfers and not in real time. The xbl FAQ says the transfers happen every 15 minutes. Personally, I only used zen at the MTA for a short time before going back to querying cbl, njabl, pbl and the sbl. Both njabl and cbl are extremely dynamic and I had a noticeable increase in leakage when querying zen.
  8. GraemeL

    RBN Foiled again

    They blocks are actually in RIPE address space (not APNIC as claimed by the article) and still seem to be allocated to RBN front companies. They all have registration addresses in China/Hong Kong/Taiwan and were being advertised via Chinese ASs (Spamhaus list). Strange that the Chinese seem to be willing to host so many scams, but stopped advertising the RBN space so quickly. If only somebody at RIPE would look into the companies behind the allocations and ask them to prove that they actually have legal business addresses (not PO boxes) in the RIPE area. If they don't, the allocations violate RIPEs own rules. On the bright side, Yambo Financials may still be pumping out the spam, but their domains all resolve to RBN space that's not currently routable. Edit to add: Oops, forgot to mention that there is a blog dedicated to tracking the activities of the RBN.
  9. If you have a SpamCop email account and have Thunderbird configured to connect to both Spamcop and Gmail via IMAP, then it's all very simple. All you need to do is select the spam in gmail, right click -> move to -> Spamcop -> Inbox -> held mail. Then go to your reporting page on Spamcop and either quick or normal report it. No messing around with plugins or forwarding. Oh, remember to set up your mailhosts for Google too.
  10. GraemeL

    Esperanto

    Mi havas sufiĉ de problemo pri La angla kaj estas mia denaska lingvo.
  11. GraemeL

    87.194.122.32 problem

    This has been a tough learning experience for Pedro, but I think he's about to come to the end of it now. He now has: Updated anti-virus software on his machines. A firewall installed. Removed all obviously weak user/password combinations. The Senderbase statistics for today show a 0.0 magnitude for his IP address. I have made a few more recommendations to him in PMs, but everything that I would consider critical has now been taken care of. Although it took longer than would have been optimal, I think we're close to closing this one off now. Thanks to Pedro for working through getting his systems cleaned up.
  12. GraemeL

    Screwing with "Adknowledge Rewards"

    I've tried several methods for seeding spam traps. The address I seeded by filling out unsubscribe forms was by far the most successful and accounts for over 80% of my spamtrap hits.
  13. GraemeL

    87.194.122.32 problem

    He doesn't have a firewall... He now knows that that was a bad decision and (I think) has people working to rectify it.
  14. GraemeL

    87.194.122.32 problem

    Every bit of it needs to include alternate data streams on every file on the box. You should also do a full scan with Rootkit Revealer. Even if those checks were run, my level of confidence in the integrity of the box would still be low. Once there is a chance that the box has been compromised, you can never be sure that it can be trusted. I replied to your other point in a PM as it included sensitive information.
  15. GraemeL

    87.194.122.32 problem

    Correct. I've exchanged a couple of PMs with him in the last 24 hours going into more detail, which is why I didn't reply to the thread here again.
  16. GraemeL

    Auto response to spamcop report

    And in response, thus spake the Oracle: 'Fraid not.
  17. The problem is that SA has miss-identified the mails in the 1st place. He has spam that SA identified (and possibly scanned with the Bayes engine (see below)) as ham. While the Bayes engine can be told that a mistake was made, it needs a real human to identify that mistake (whether the rest of the process is automated or not). Brandioch, you obviously already know a lot about the workings of Spamassassin, so forgive me if you know this part too. The SA Bayes autolearn function doesn't work on all mail that has been scanned, it will ignore mail that is around the scoring borders (I haven't done the research to identify what the actual rules are). If you have terse reporting turned off, you can see what the Bayes engine actually did with the mail. The three results shown in the mail headers are: autolearn=spam - The engine learned from the mail treating it as spam. autolearn=ham - The engine learned from the mail treating it as ham. autolearn=no - The score was close to the border, so no Bayes learning was performed. So even if SA identified the mail as ham, it doesn't necessarily follow that the Bayes engine modified its tokens based on the mail content. It should also be pointed out that a small amount of poisoning results will not have a significant effect on the reliability of the classifications within a large corpus of ham and spam. In situations where the size of the training corpus is small, it could have a large effect. This is why SA will not score on the Bayes engine results until tokens have been built from a significant corpus of both spam and ham. Read up on Bayesian Belief Networks if you want to dig into the details .
  18. GraemeL

    [Resolved] XP Recovery issues

    In this kind of situation, threatening to reprogram the thing with a fire axe sometimes helps. Sorry, nothing useful to add, but it seemed like you needed some sympathy. Edit to add: Sometimes actually reprogramming the thing with a fire axe helps even more.
  19. GraemeL

    Recent Russian Botnet attacks

    Oh, in that case, it's probably Yambo Financials. They've been hitting me too. Around 99.5% of their attempts are being rejected with 5xx responses. So far, all that have gotten through have been to a single spam trap and get automagically quick reported.
  20. GraemeL

    Recent Russian Botnet attacks

    I would probably just turn down the volume on the firewall logging to a more useful level and ignore them. If you're not running services on ports, then receiving a log entry when something tries to send a SYN is just noise that you don't need. If you're using iptables, you can get a summary showing you hits on individual rules without having each hit clog up the log file. Then you scan the individual logs for services that you are running and only add firewall rules to block IPs trying things that might actually result in a compromise. I pretty much only log two things for iptables; Cyveillance IPs, because I get a warm and fuzzy feeling when they bounce off the firewall, and SSH connections. My SSH port is protected by a port knocking setup to prevent brute forcing access, but as an extra precaution, anything that attempts to hit the blocked port three or more times in a 24 hour period gets all traffic blocked for seven days. Of course, this relies on my not being stupid enough to realize that I forgot to give the secret knock and lock myself out when I'm trying to get remote access. Summary: Turn down the noise and focus on attacks against services that you are running.
  21. GraemeL

    87.194.122.32 problem

    Had a quick look at everything that I listed previously. The only thing that seems to have been done is that remote access has been removed from the machine. The box still has AUTH LOGIN enabled and still has an administrator equivalent account with a comically easy password. This would suggest that the box has not been formatted and rebuilt from scratch. You have no way of knowing if the box has been rooted with multiple back doors installed on it. The box continues to hit Spamcop spamtraps (they're only known to Spamcop staff, I have no idea what they are) as well as being reported by Spamcop users. At this point, all I can do is reiterate my point five above in a more forceful manner: I believe that your current "tech people" are not competent to maintain corporate servers on the internet. I strongly suggest that you replace them with people who have an understanding of running servers in a secure manner.
  22. spam is dynamic and so are SA rules. The rules and scores associated with them don't only change with version releases, they are updated every two or three weeks. Run "sa-update" to get the latest ruleset. spam also varies from site to site and the SA rules are a compromise designed to catch the largest amount of spam for the fewest false positives based on a large sample of spam and ham. You can change the scores for any rules that you find problematic by editing SAs local.cf file. The following will disable the rules causing you problems: score RCVD_IN_DNSWL_LOW 0 score RCVD_IN_DNSWL_MED 0 score RCVD_IN_DNSWL_HI 0 Also, you should not rely on the Bayes algorithm auto-learning where the score has produced an error. Tell it that it got it wrong. Copy false negatives into a bad-spam box and false negatives into a bad-ham box. Run "sa-learn --spam --mbox /path/to/bad-spam" and "sa-learn --ham --mbox /path/to/bad-ham" (Replace --mbox with --mbx if you're using mbx instead of mbox. Use --folders=/path/to/bad-spam" if you're using maildir.) Finally clear out the mailboxes ready for another run. It's fairly simple to write something to automate all of that.
  23. Yes, the test adds a negative number to the score of the mail being parsed. # DNSWL score RCVD_IN_DNSWL_LOW 0 -1 0 -1 score RCVD_IN_DNSWL_MED 0 -4 0 -4 score RCVD_IN_DNSWL_HI 0 -8 0 -8 That's in 50_scores.cf which is part of the default ruleset released with SA.
  24. GraemeL

    Amazing reduction in Spam

    I've seen an increase of spam delivery attempts of between 300% and 400% to my own server in the last two days. spam getting delivered to my spam traps (and thus auto submitted to SpamCop) has approximately doubled over the same period. All of this increase appears to be from the same viagra spammer. Looks to me that's it's just a general increase in output from one spammer and not directed at SpamCop. On the plus side, none of them have actually ended up in my real inbox.
  25. GraemeL

    87.194.122.32 problem

    Thanks, but it was all pretty simple really. Three terminal windows and four commands. dig -x 87.194.122.69 rblcheck 87.194.122.69 salt 87.194.122.69 nmap -O -P0 -sS -v -v 87.194.122.69 Sit back and wait for the results. The machine was pretty slow, so the password scan took quite a while to finish. Not very subtle, but there's no reason to be when you're trying to help somebody else out. Any IDS on the network would be lighting up like mad. Though from the way things looked, I think it unlikely that they have one. Anybody with enough knowledge to be running an IDS wouldn't be making as many mistakes in basic security.
×