Check your email servers - blackholes.us DNSBL is dead
Aaron let us know about a discussion thread on the NANOG mailing list about issues with the blackholes.us DNS block list (DNSBL):
The issue is the maintainer of the blackholes.us DNSBL shut the list down some time back and the IP address space that the DNS servers for it were on was given back to ARIN. That address space has since been re-allocated to a new company and they are getting tired of the continual inbound DNS queries to the IP address of the old server. Apparently they have now stood up a DNS server to answer those queries with a wildcard record that effectively returns "yes, the IP you are inquiring about is a spammer". As a result, lots of mail relays that are still configured to do lookups against this DNSBL are now being told that everyone on the Internet is a spam source.
According to this post in the news.admin.net-abuse.email Usenet newsgroup, the DNSBL was shutdown 2 years ago.
If you are an email administrator, please check your RBLs to see if you are still submitting queries to blackholes.us and remove it from your configurations if you are. You should also review any other RBLs you are using to ensure that they are still in operation as well.
New variation of SSL Spam
We've received numerous emails about this already today. This is an update to a diary we did earlier this week.
The body of the spam today is:
Dear user of the <some company> mailing service! We are informing you that because of the security upgrade of the mailing service your mailbox (<user>@<some company>) settings were changed. In order to apply the new set of settings click on the following link: The email contains a link with a file to download. Some of the files we have seen are: settings-file.exe MD5: 0244586f873a83d89caa54db00853205 settings-file2.exe MD5: e6436811c99289846b0532812ac49986 The files are being detected by some anti-virus software programs at this time as Zbot variants. Thanks Jon, Frank, iTinker, Nick and others for your reports on this.
Odd Apache/MSIE issue with downloads from ISC
This diary is a bit unusual in that the problem here is very close to home, the ISC/DShield website. But I figure among all of our readers, there may be one who can help. I have seen others describing the same issue, but so far I haven't found a solution.
The problem:
Users who download our log submission client using Internet Explorer frequently receive truncated files. Firefox appears to download them fine. In either case, the server logs a "200" status and the file size in our Apache access log is correct (about 2.2 MBytes). However, the users only receives 200-300kBytes. A packet capture confirms that only 200-300kBytes got transfered. As MSIE starts the download, it does display the correct file size (and the content-length header is correct)
Some of the issues we excluded:
mod_security, firewall, IPS
Also note that the downloads work fine with Firefox, so the server is perfectly capable of sending the file. Any help is appreciated.
Link to the file: http://isc.sans.org/clients/cvtwin-setup.exe
Here is a packet dump of the end of the connection:
IP client.54436 > server.80: Flags [.], ack 193105, win 32850, length 0 IP server.80 > client.54436: Flags [.], ack 646, win 1783, length 1460 IP client.54436 > server.80: Flags [.], ack 196025, win 32850, length 0 IP server.80 > client.54436: Flags [.], ack 646, win 1783, length 1460 IP server.80 > client.54436: Flags [FP.], seq 215005:216465, ack 646, win 1783, length 1460 IP client.54436 > server.80: Flags [.], ack 198945, win 32120, length 0 IP client.54436 > server.80: Flags [.], ack 200405, win 32850, length 0 IP client.54436 > server.80: Flags [.], ack 203325, win 32850, length 0 IP client.54436 > server.80: Flags [.], ack 207705, win 32850, length 0 IP client.54436 > server.80: Flags [.], ack 210625, win 32850, length 0 IP client.54436 > server.80: Flags [.], ack 212085, win 32120, length 0 IP client.54436 > server.80: Flags [.], ack 213545, win 32850, length 0 IP client.54436 > server.80: Flags [.], ack 216466, win 32120, length 0 IP client.54436 > server.80: Flags [F.], seq 646, ack 216466, win 32850, length 0 IP server.80 > client.54436: Flags [.], ack 647, win 1783, length 0
------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter
Cyber Security Awareness Month - Day 14 - port 514 - syslog
Often times, if hackers or worms break into your computer, they will try to delete the logs on the local computer to help hide their tracks. Having all your computers submit their local logs to a central log server will help you maintain copies of those logs. Even if a bad guy isn't trying to delete your logs, its also a good way to aggregate log data and to review it centrally using tools such as Swatch, Logsurfer or SEC to see if there are unusual events occurring on your systems. These three tools all allow you to build a set of rules to help filter the log traffic. Messages that are 'normal' noise can be ignored and messages that are indicative of unusual activity can generate an alert to notify your admins to review the activities.
There are 3 main syslog packages at this time:
1) syslog - the original syslog program. This only supports sending messages to the central log server over UDP. As such, you have no guarantees that the messages will get to the central server. Because it is UDP based, it is important that you use a firewall to block inbound UDP syslog traffic from the Internet. This is so malicious users can not send in a flood of syslog entries that result in filling up the filesystem on your central syslog server.
2) syslog-ng - in the spirit of Star Trek, this is 'syslog - the next generation'. syslog-ng includes support to submit logs to a central server using TCP, so it can compensate for packets that got lost due to network issues or slow down sending if there is network congestion. syslog-ng also can use supplemental tools, such as stunnel to encrypt the log traffic between the source and the central log server using SSL.
3) rsyslog - this is the latest syslog replacement. It can use TCP as well for more reliable communication. It now has native encryption support built-in, eliminating the need to use a second tool like stunnel to secure the network communication. It can also use MySQL as a storage backend rather than flat text files. This is useful for tools such as phplogcon which can be used to visualize the log data.
For environments with Windows systems, there are add-ons you can install to allow you to submit your various Windows event logs to a syslog server as well. Some examples of these products are winlogd, SNARE, and a Perl module Win32::Syslog.
Comments