Re: Mail relay attempts
On Thursday, Aug 29, 2002, at 09:34 US/Eastern, Nathan E Norman wrote: This is why all ISPs should apply filters at their ingress/egress points. Unfortunately, many do not. While I don't want to start a flame war here, as all discussions of this topic seem to become, I'd just like to point out there are very legitimate arguments that egress filtering is a bad thing. IP routing does not have to be symmetric. It is for certain situations very useful to have data come in one connection and leave another. Even if those connections are from different ISPs. A recent time I did this was to transition to a new hosting facility; the router at the old facility was configured to forward data to the new facility over a GRE tunnel, where it was then passed through static NAT. The data coming out of the new facility was sent out with the old facilities IPs as the source. Tunneling that would of been bad, because the outgoing traffic was much, much, larger than incoming. Another thing reverse path filtering breaks is having a mobile IP address. Say you take your laptop with you --- it can be very useful to have a constant IP address, especially if you want to keep, e.g., a ssh connection open. That is fairly easily done by tunneling packets sent to that address to the actual IP of the laptop. Data sent out from the laptop is sent with the mobile IP address as source. No reason to tunnel it back, that just wastes bandwidth and slows things down more. Spoofed addresses are annoying. However, it's not really something that can be fixed. Please don't break useful features while failing
Re: Mail relay attempts
Adam Majer wrote: I know. It is crazzy. I actually would like to see some sort of a better defence than just standing there uselessly. I mean, in real life if a country (community etc..) gets attacked by another, there is usually a war and someone is tought a lesson. But here, all we do is sit arround do nothing. Actually a better analogy would be turning people away at the border. In the USA we have the INS who manage who enters and leaves the country. When aliens cross into the country illegally you could compare that to an intrusion. Ports, be them digital or real share the same security protocols when you think about it. It isn't worth going after those you turn away. -davidu
Re: Mail relay attempts
Simple. Random IP-address block scans. Having the box live on the 'net alone guarantees that it will get some random hits. Prepare to see lot more of them from here-on. Script-kiddies, trying to find suitable hosts for their mass exploitation tools. Worms, eagerly propagating on their own means; And spammers (spammerbots?) trying to find open relays they could abuse. The only thing you can do is to make damn certain your box does not become part of the problem. I know. It is crazzy. I actually would like to see some sort of a better defence than just standing there uselessly. I mean, in real life if a country (community etc..) gets attacked by another, there is usually a war and someone is tought a lesson. But here, all we do is sit arround do nothing. I usually get about 20 probes per day for ssh or relay. And for other ports, well, 1808 234K DROP all -- * * 0.0.0.0/00.0.0.0/0 over 10 day period. I realize, that's nothing if you are an ISP. LOL, imagine what microsoft.com has to be getting!!! - Adam
Re: Mail relay attempts
Hi Peter. Peter Cordes wrote: [tarpit for attacking worms] I remember hearing about people doing exactly that. Maybe it was mentioned on /. or the local LUG mailing list (http://nslug.ns.ca/). Sounds interesting. The LUG website is unreachable at the moment, but I will dig the slashdot archives about that. Thanks for the hint. Bye, Mike
Re: Mail relay attempts
* Quoting Jones, Steven ([EMAIL PROTECTED]): Ive found port sentry really good for detecting port scans and then routeing the return packets to no where. That makes you open to DoS-Attacks. Someone could scan you with spoofed source-IP and disconnect your box. A tarpit is a much better aproach than a (dynamic) blocklist. - Rolf
RE: Mail relay attempts
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 If you use Iptables and you block spoofed addresses with Iptables, will that stop the spoofing in their tracks, therefore decreasing the chance of a DOS? Sincerely, Daniel J. Rychlik Money does not make the world go round , Gravity does . - -Original Message- From: Rolf Kutz [mailto:[EMAIL PROTECTED] Sent: Thursday, August 29, 2002 5:18 AM To: [EMAIL PROTECTED] Debian. Org Subject: Re: Mail relay attempts * Quoting Jones, Steven ([EMAIL PROTECTED]): Ive found port sentry really good for detecting port scans and then routeing the return packets to no where. That makes you open to DoS-Attacks. Someone could scan you with spoofed source-IP and disconnect your box. A tarpit is a much better aproach than a (dynamic) blocklist. - - Rolf - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: PGP 7.1.1 iQA/AwUBPW37regW0zo5qpEdEQI9XwCgzHZe9C/qZdY+sbKnVaQ3q/CY9aQAn2gi bQCMFujuUVmVOexSO2eLeYbh =JyBm -END PGP SIGNATURE-
Re: Mail relay attempts
On Thu, Aug 29, 2002 at 05:47:10AM -0500, Daniel J. Rychlik wrote: If you use Iptables and you block spoofed addresses with Iptables, will that stop the spoofing in their tracks, therefore decreasing the chance of a DOS? Not necessarily. You can stop blind spoofing attacks where ip's belonging to one NIC are not allowed to appear from another, something which is also stopped by a debian if the option is set in /etc/network/options. A problem with this is that FreeSWAN forces you to disable the anti-spoof protection on the NIC used by the tunnel and they don't seem to think it worthwhile to fix the problem. Another class of spoofing iptables can stop is if you are blocking any incoming connections that are not associated with an existing outgoing connection. However if you have any external access whatever, spoofing attacks are possible, not only for DOS but for more interesting blind attacks, particularly if someone manages to predict a sequence number and capture a connection. (Linux is fairly immune to prediction fortuneately.). -- -- Nuke bin Laden: Dale Amon, CEO/MD improve the global Islandone Society gene pool. www.islandone.org --
Re: Mail relay attempts
On Thu, Aug 29, 2002 at 05:47:10AM -0500, Daniel J. Rychlik wrote: If you use Iptables and you block spoofed addresses with Iptables, will that stop the spoofing in their tracks, therefore decreasing the chance of a DOS? No. For example, let's say someone manages to spoof mailout.aol.com [1] and then connects to you. You will now block all mail from AOL (hmm, perhaps that's a bad example :) In other words, unless the source address is a reserved address or one of your local addresses, you really don't know if it's spoofed or not (barring some sort of cryptographic challenge, like IPSEC). This is why all ISPs should apply filters at their ingress/egress points. Unfortunately, many do not. -- Nathan Norman - Micromuse Ltd. mailto:[EMAIL PROTECTED] Whenever men attempt to suppress argument and free speech, we may be sure that they know their cause to be a bad one. -- R. G. Horton [1] I made up that host name; you get the idea. pgpmj91iBlucP.pgp Description: PGP signature
Re: Mail relay attempts
On Wed, Aug 28, 2002 at 11:49:36AM +0200, Michael Renzmann wrote: I'll add another one to that: I started using syslogd-sql, which is a modified version of the syslog 1.4.1 that also allows logging to a MySQL database. I hope it is a step in the right direction to use advances SQL queries in order to support analyzation of logfiles. Any opinions on that from the more experiences ones on this list? :) It would be nice, but I don't know if syslog-ng supports it... it might, I just don't remember seeing it the last time I read the manual. And of course if you really want to get hardcore on logs, you would need a printer (or a write-once media ) on your master logging server and you'd keep the results forever. Depends on who you're working for. I think if I were going to use sql analysis I'd consider doing it on a different machine than the hardened logger. For hardened read simple, stupid, and understandable. -- -- Nuke bin Laden: Dale Amon, CEO/MD improve the global Islandone Society gene pool. www.islandone.org --
Re: Mail relay attempts
On Thursday, 29 August 2002, at 16:57:09 +0100, Dale Amon wrote: I'll add another one to that: I started using syslogd-sql, which is a modified version of the syslog 1.4.1 that also allows logging to a MySQL database. I hope it is a step in the right direction to use advances SQL queries in order to support analyzation of logfiles. Any opinions on that from the more experiences ones on this list? :) It would be nice, but I don't know if syslog-ng supports it... it might, I just don't remember seeing it the last time I read the manual. As far as the documentation says, there is no out-of-the-box support in syslogng to log remotely to an SQL database. However, maybe destination type program() could be useful: when syslogng starts and sees a program() destination, it forks a copy of the program and keeps it open to send (via stdin) log strings that the program should dispose of properly. This program can be a 50-line PERL script, but I don't know if this ad-hoc solution could be deemed solid enough for a production system (I didn't try it myself). -- Jose Luis Domingo Lopez Linux Registered User #189436 Debian Linux Woody (Linux 2.4.19-pre6aa1)
Re: Mail relay attempts
Hi Dale. Dale Amon wrote: The only thing you can do is to make damn certain your box does not become part of the problem. I'll add to that: make sure you actually check your logs. I use syslog-ng to bring all essential realtime logging to a hardened server; I'll add another one to that: I started using syslogd-sql, which is a modified version of the syslog 1.4.1 that also allows logging to a MySQL database. I hope it is a step in the right direction to use advances SQL queries in order to support analyzation of logfiles. Any opinions on that from the more experiences ones on this list? :) Bye, Mike
Re: Mail relay attempts
Hi. Jones, Steven wrote: Ive found port sentry really good for detecting port scans and then routeing the return packets to no where. As an addition to that idea: would it be possible to cause similar effects to HTTP-server worms with a modified tarpit? Maybe a modified version of the kernel httpd: whenever a worm attack drops in the response will be a normal website containing a bogus content (no 404), coming over the line character by character with a huge delay. Comments? Bye, Mike
Re: Mail relay attempts
On Wed, Aug 28, 2002 at 11:56:24AM +0200, Michael Renzmann wrote: Hi. Jones, Steven wrote: Ive found port sentry really good for detecting port scans and then routeing the return packets to no where. As an addition to that idea: would it be possible to cause similar effects to HTTP-server worms with a modified tarpit? Maybe a modified version of the kernel httpd: whenever a worm attack drops in the response will be a normal website containing a bogus content (no 404), coming over the line character by character with a huge delay. Comments? I remember hearing about people doing exactly that. Maybe it was mentioned on /. or the local LUG mailing list (http://nslug.ns.ca/). -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , ns.ca) The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces! -- Plautus, 200 BCE
Mail relay attempts
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This is great, Just great. I run a mail server on dsl service provided by mabell. I wrote a perl script that mails me some reports on activities on my server everyday. I wake up this morning and I have an alarm. Obviously, non of these were relayed from my server because there are only 2 private ip addresses that can use my server to relay mail. But, alas I am bothered by these attempts and I hope that I can snip this in the bud quick. Any suggestions would be of great importance and taken seriously. Please advise. ALERT:MAIL RELAY FAILURES SEEMS TO BE PROBLEMS WITH ABUSERS::: 2002-08-26 19:36:11 refused relay (host) to [EMAIL PROTECTED] from [EMAIL PROTECTED] H=mail.sopovico.pt (eircom.net) [194.38.132.105] 2002-08-26 19:36:12 refused relay (host) to [EMAIL PROTECTED] from [EMAIL PROTECTED] H=mail.sopovico.pt (eircom.net) [194.38.132.105] 2002-08-26 19:36:14 refused relay (host) to [EMAIL PROTECTED] from [EMAIL PROTECTED] H=mail.sopovico.pt (eircom.net) [194.38.132.105] 2002-08-26 19:36:15 refused relay (host) to [EMAIL PROTECTED] from [EMAIL PROTECTED] H=mail.sopovico.pt (eircom.net) [194.38.132.105] 2002-08-26 19:36:15 refused relay (host) to [EMAIL PROTECTED] from [EMAIL PROTECTED] H=mail.sopovico.pt (eircom.net) [194.38.132.105] 2002-08-26 19:36:15 refused relay (host) to [EMAIL PROTECTED] from [EMAIL PROTECTED] H=mail.sopovico.pt (eircom.net) [194.38.132.105] 2002-08-26 19:36:15 refused relay (host) to [EMAIL PROTECTED] from [EMAIL PROTECTED] H=mail.sopovico.pt (eircom.net) [194.38.132.105] 2002-08-26 19:36:15 refused relay (host) to [EMAIL PROTECTED] from [EMAIL PROTECTED] H=mail.sopovico.pt (eircom.net) [194.38.132.105] 2002-08-26 19:36:15 refused relay (host) to [EMAIL PROTECTED] from [EMAIL PROTECTED] H=mail.sopovico.pt (eircom.net) [194.38.132.105] 2002-08-26 19:36:15 refused relay (host) to [EMAIL PROTECTED] from [EMAIL PROTECTED] H=mail.sopovico.pt (eircom.net) [194.38.132.105] 2002-08-26 19:36:15 refused relay (host) to [EMAIL PROTECTED] from [EMAIL PROTECTED] H=mail.sopovico.pt (eircom.net) [194.38.132.105] 2002-08-26 19:36:15 refused relay (host) to [EMAIL PROTECTED] from [EMAIL PROTECTED] H=mail.sopovico.pt (eircom.net) [194.38.132.105] 2002-08-26 19:36:15 refused relay (host) to [EMAIL PROTECTED] from [EMAIL PROTECTED] H=mail.sopovico.pt (eircom.net) [194.38.132.105] 2002-08-26 19:36:15 refused relay (host) to [EMAIL PROTECTED] from [EMAIL PROTECTED] H=mail.sopovico.pt (eircom.net) [194.38.132.105] 2002-08-26 19:36:15 refused relay (host) to [EMAIL PROTECTED] from [EMAIL PROTECTED] H=mail.sopovico.pt (eircom.net) [194.38.132.105] 2002-08-26 19:36:15 refused relay (host) to [EMAIL PROTECTED] from [EMAIL PROTECTED] H=mail.sopovico.pt (eircom.net) [194.38.132.105] 2002-08-26 19:36:15 refused relay (host) to [EMAIL PROTECTED] from [EMAIL PROTECTED] H=mail.sopovico.pt (eircom.net) [194.38.132.105] 2002-08-26 19:36:15 refused relay (host) to [EMAIL PROTECTED] from [EMAIL PROTECTED] H=mail.sopovico.pt (eircom.net) [194.38.132.105] 2002-08-26 19:36:15 refused relay (host) to [EMAIL PROTECTED] from [EMAIL PROTECTED] H=mail.sopovico.pt (eircom.net) [194.38.132.105] 2002-08-26 19:36:15 refused relay (host) to [EMAIL PROTECTED] from [EMAIL PROTECTED] H=mail.sopovico.pt (eircom.net) [194.38.132.105] 2002-08-26 19:36:15 refused relay (host) to [EMAIL PROTECTED] from [EMAIL PROTECTED] H=mail.sopovico.pt (eircom.net) [194.38.132.105] 2002-08-26 19:36:15 refused relay (host) to [EMAIL PROTECTED] from [EMAIL PROTECTED] H=mail.sopovico.pt (eircom.net) [194.38.132.105] 2002-08-26 19:36:15 refused relay (host) to [EMAIL PROTECTED] from [EMAIL PROTECTED] H=mail.sopovico.pt (eircom.net) [194.38.132.105] 2002-08-26 19:36:15 refused relay (host) to [EMAIL PROTECTED] from [EMAIL PROTECTED] H=mail.sopovico.pt (eircom.net) [194.38.132.105] 2002-08-26 19:36:15 refused relay (host) to [EMAIL PROTECTED] from [EMAIL PROTECTED] H=mail.sopovico.pt (eircom.net) [194.38.132.105] 2002-08-26 19:36:15 refused relay (host) to [EMAIL PROTECTED] from [EMAIL PROTECTED] H=mail.sopovico.pt (eircom.net) [194.38.132.105] 2002-08-26 19:36:15 refused relay (host) to [EMAIL PROTECTED] from [EMAIL PROTECTED] H=mail.sopovico.pt (eircom.net) [194.38.132.105] 2002-08-26 19:36:15 refused relay (host) to [EMAIL PROTECTED] from [EMAIL PROTECTED] H=mail.sopovico.pt (eircom.net) [194.38.132.105] 2002-08-26 19:36:15 refused relay (host) to [EMAIL PROTECTED] from [EMAIL PROTECTED] H=mail.sopovico.pt (eircom.net) [194.38.132.105] 2002-08-26 19:36:15 refused relay (host) to [EMAIL PROTECTED] from [EMAIL PROTECTED] H=mail.sopovico.pt (eircom.net) [194.38.132.105] 2002-08-26 19:36:15 refused relay (host) to [EMAIL PROTECTED] from [EMAIL PROTECTED] H=mail.sopovico.pt (eircom.net) [194.38.132.105] 2002-08-26 19:36:15 refused relay (host) to [EMAIL PROTECTED] from [EMAIL PROTECTED] H=mail.sopovico.pt (eircom.net) [194.38.132.105] 2002-08-26 19:36:15 refused relay (host) to [EMAIL PROTECTED] from
Re: Mail relay attempts
Daniel J. Rychlik wrote: This is great, Just great. I run a mail server on dsl service provided by mabell. I wrote a perl script that mails me some reports on activities on my server everyday. I wake up this morning and I have an alarm. Obviously, non of these were relayed from my server because there are only 2 private ip addresses that can use my server to relay mail. But, alas I am bothered by these attempts and I hope that I can snip this in the bud quick. Any suggestions would be of great importance and taken seriously. Please advise. ALERT:MAIL RELAY FAILURES SEEMS TO BE PROBLEMS WITH ABUSERS::: 2002-08-26 19:36:11 refused relay (host) to [EMAIL PROTECTED] from [EMAIL PROTECTED] H=mail.sopovico.pt (eircom.net) [194.38.132.105] 2002-08-26 19:36:12 refused relay (host) to [EMAIL PROTECTED] from [EMAIL PROTECTED] H=mail.sopovico.pt (eircom.net) [194.38.132.105] 2002-08-26 19:36:14 refused relay (host) to [EMAIL PROTECTED] from [EMAIL PROTECTED] H=mail.sopovico.pt (eircom.net) [194.38.132.105] 2002-08-26 19:36:15 refused relay (host) to [EMAIL PROTECTED] from [EMAIL PROTECTED] H=mail.sopovico.pt (eircom.net) [194.38.132.105] -- SNIP --- Hi, What can I say Daniel, except welcome to the harsh reality of a postmaster. I'm running a small, some 300 users, mail server for our organization. I'm having at least a hundred probes a week checking for open eMail relays, even one korean host trying to relay SPAM. That box is blocked, naturally. There is nothing to do, except complain to the abuse department of the offenders ISP and hope they deal with the user probing or trying to relay SPAM. Complaining to Korean ISP:s is useless, sorry Koreans on the list, no offence but it's true. If your attempt is from mail.sopovico.pt, abuse is according to Spamcop: [EMAIL PROTECTED] A check with http://relays.osirusoft.com/ shows this IP beeing listed as a SPAMMER and a SPAM relay on many lists. Welcome to the world of SPAMfighting Regards /Ksrl Breitner
Re: Mail relay attempts
Hi Karl. Karl Breitner wrote: What can I say Daniel, except welcome to the harsh reality of a postmaster. Hmm, as I'm to become a postmaster in a few days, too, I would like to learn a bit more about that. Most probably this list is not intended for chat like this, so I would be happy to get some hints on where to get more information about that topic (mailing lists, FAQs, and so on). Welcome to the world of SPAMfighting I guess this means a lot of fun (well, fun at least if you are pervert ;). Our new server has an official IP since last saturday, and no domain name pointing to it yet besides a dyndns-account I abused for testing purpose. Within these three days of operation I had several persons trying to get access to our (non-public) FTP service as well as some probes for the usual IIS-holes that Nimda Co. like to abuse. How will that be if we will be publically online and known through our regular domains? brrr :) Bye, Mike
Re: Mail relay attempts
Karl Breitner wrote: Welcome to the world of SPAMfighting Our new server has an official IP since last saturday, and no domain name pointing to it yet besides a dyndns-account I abused for testing purpose. Within these three days of operation I had several persons trying to get access to our (non-public) FTP service as well as some probes for the usual IIS-holes that Nimda Co. like to abuse. How will that be if we will be publically online and known through our regular domains? brrr :) Simple. Random IP-address block scans. Having the box live on the 'net alone guarantees that it will get some random hits. Prepare to see lot more of them from here-on. Script-kiddies, trying to find suitable hosts for their mass exploitation tools. Worms, eagerly propagating on their own means; And spammers (spammerbots?) trying to find open relays they could abuse. The only thing you can do is to make damn certain your box does not become part of the problem. -- Mika Boström +358-40-525-7347 \-/ The Hell is empty, [EMAIL PROTECTED]www.lut.fi/~bostik Xand all the devils Security freak, and proud of it./-\ are here. -W.S. pgpCM2CJoUgtd.pgp Description: PGP signature
Re: Mail relay attempts
On Tue, Aug 27, 2002 at 04:11:21PM +0300, Mika Bostr?m wrote: Karl Breitner wrote: Welcome to the world of SPAMfighting Our new server has an official IP since last saturday, and no domain name pointing to it yet besides a dyndns-account I abused for testing purpose. Within these three days of operation I had several persons trying to get access to our (non-public) FTP service as well as some probes for the usual IIS-holes that Nimda Co. like to abuse. How will that be if we will be publically online and known through our regular domains? brrr :) Simple. Random IP-address block scans. Having the box live on the 'net alone guarantees that it will get some random hits. Prepare to see lot more of them from here-on. Script-kiddies, trying to find suitable hosts for their mass exploitation tools. Worms, eagerly propagating on their own means; And spammers (spammerbots?) trying to find open relays they could abuse. The only thing you can do is to make damn certain your box does not become part of the problem. I'll add to that: make sure you actually check your logs. I use syslog-ng to bring all essential realtime logging to a hardened server; I also run logcheck for hourly reports; snort for attack detection; tiger for security auditing; fascist iptables firewalling on all externally reachable machines; and of course tripwire for after the fact intrusion detection. It's a jungle out there lad.
Re: Mail relay attempts
On Tue, Aug 27, 2002 at 06:12:51AM -0500, Daniel J. Rychlik wrote: This is great, Just great. I run a mail server on dsl service provided by mabell. I wrote a perl script that mails me some reports on activities on my server everyday. I wake up this morning and I have an alarm. Obviously, non of these were relayed from my server because there are only 2 private ip addresses that can use my server to relay mail. But, alas I am bothered by these attempts and I hope that I can snip this in the bud quick. Any suggestions would be of great importance and taken seriously. Please advise. you have an SMTP server, therefore spammers *will* attempt to relay mail through it. guaranteed. sometimes only a few times per day, sometimes hundreds or thousands of attempts per day. get used to it. fortunately, your server sounds like it is not an open relay - you've done the right thing. there's nothing more you can do. you can't stop them trying. you've already done a good job in preventing them from relaying through you. btw, if your DSL service gives you a dynamic IP address you will end up on various DUL-type RBLs anyway. some mail-server operators do not want to receive mail direct from dynamic IP addresses. it's their server, their choice. craig PS: actually, the only other thing you could do is set firewall rules blocking inbound tcp port 25. if your mail server is the primary MX for your domain then you would also need a secondary MX and open the firewall for just that machine. spammers will still try - the only real difference is that you'll get entries in your kernel log rather than in your mail log. if you do this, i recommend using iptables and DROP the packet rather than REJECT itthis wastes the spammer's time while the connection times out. the downside to doing this is that spammers can relay spam to you via your secondary MX, in order to get around any local access rules you have. e.g. if you use a particular RBL service and your secondary MX doesn't, then you may as well not bother using the RBL. IMO, it's not worth having a secondary MX host unless either a) you control your secondary MX or b) your secondary MX has at least as good an anti-spam setup as you do. -- craig sanders [EMAIL PROTECTED] Fabricati Diem, PVNC. -- motto of the Ankh-Morpork City Watch
Re: Mail relay attempts
On Tue, 27 Aug 2002 at 11:32:53PM +1000, Craig Sanders wrote: PS: actually, the only other thing you could do is set firewall rules blocking inbound tcp port 25. if your mail server is the primary MX for your domain then you would also need a secondary MX and open the firewall for just that machine. spammers will still try - the only real difference is that you'll get entries in your kernel log rather than in your mail log. if you do this, i recommend using iptables and DROP the packet rather than REJECT itthis wastes the spammer's time while the To briefly add to what you can do you could email the contact responsible for the IP block in the InterNIC Whois DB. SOMETIMES you might get a reply You can also try [EMAIL PROTECTED] -- Phil PGP/GPG Key: http://www.zionlth.org/~plhofmei/ wget -O - http://www.zionlth.org/~plhofmei/ | gpg --import XP Source Code: #include win2k.h #include extra_pretty_things_with_bugs.h #include more_bugs.h #include remote_admin_abilities_for_MS.h #include more_restrictive_EULA.h #include sell_your_soul_to_MS_EULA.h //os_over=Windows 2000 os_ver=Windows XP
Re: Mail relay attempts
* Craig Sanders [EMAIL PROTECTED] [020827 17:07]: On Tue, Aug 27, 2002 at 06:12:51AM -0500, Daniel J. Rychlik wrote: PS: actually, the only other thing you could do is set firewall rules blocking inbound tcp port 25. if your mail server is the primary MX for your domain then you would also need a secondary MX and open the firewall for just that machine. spammers will still try - the only real difference is that you'll get entries in your kernel log rather than in your mail log. if you do this, i recommend using iptables and DROP the packet rather than REJECT itthis wastes the spammer's time while the connection times out. As long as it is not so much traffic that the returned packets cost money, I think a REJECT is much nicer. I do not think timeout due to DROP will have noticeable impact to the spammer, but will be the hell to anyone trying to investigate why he cannot send you mail. Hochachtungsvoll, Bernhard R. Link -- The man who trades freedom for security does not deserve nor will he ever receive either. (Benjamin Franklin)
Re: Mail relay attempts
* Quoting Craig Sanders ([EMAIL PROTECTED]): PS: actually, the only other thing you could do is set firewall rules blocking inbound tcp port 25. if your mail server is the primary MX for your domain then you would also need a secondary MX and open the firewall for just that machine. spammers will still try - the only real difference is that you'll get entries in your kernel log rather than in your mail log. if you do this, i recommend using iptables and DROP the packet rather than REJECT itthis wastes the spammer's time while the connection times out. Drop doesn't really prevent scans and spammers will scan for open ports first. If you really want to achive something like that, you should install a 'Teergrube': http://www.iks-jena.de/mitarb/lutz/usenet/teergrube.en.html - Rolf
RE: Mail relay attempts
Ive found port sentry really good for detecting port scans and then routeing the return packets to no where. :) Thing -Original Message- From: Rolf Kutz [mailto:[EMAIL PROTECTED] Sent: Wednesday, 28 August 2002 4:10 To: [EMAIL PROTECTED] Debian. Org Subject: Re: Mail relay attempts * Quoting Craig Sanders ([EMAIL PROTECTED]): PS: actually, the only other thing you could do is set firewall rules blocking inbound tcp port 25. if your mail server is the primary MX for your domain then you would also need a secondary MX and open the firewall for just that machine. spammers will still try - the only real difference is that you'll get entries in your kernel log rather than in your mail log. if you do this, i recommend using iptables and DROP the packet rather than REJECT itthis wastes the spammer's time while the connection times out. Drop doesn't really prevent scans and spammers will scan for open ports first. If you really want to achive something like that, you should install a 'Teergrube': http://www.iks-jena.de/mitarb/lutz/usenet/teergrube.en.html - Rolf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
