Re: [PHP] Delivery reports about your e-mail

2005-06-16 Thread Sean Straw / PSE

Yes, it would be nice if the list didn't relay this obvious cruft.

I'm s*bscribed to quite a few discussion lists, and php-general seems to be 
the ONLY one relaying these malware messages and the claims of virus filters.


It looks rather like php-general is operating as an open list, seeing as 
some of the addresses these messages are coming from clearly shouldn't 
already be s*bscribed to the list, and the malware responsible for most of 
it wouldn't actually perform a s*bscription.


At a minimum, I'd block the handful of known forgery addresses, plus block 
postmaster@ and mailer-daemon@ messages from reaching the list.  Yea, 
bummer for the handful of people who use postmaster for their s*bscription 
address (which is contrary to the purpose of the postmaster address, so no 
loss there).  I'd be quite happy if the list didn't accept attachments 
either, but that would probably be a bit much to ask.


The appropriate solution would be to configure lists.php.net and any other 
php.net mail hosts to use SMTP AUTH, and set them up with TLS certificates 
and trusted relationships among one another using TLS (this is easy to do, 
at least in sendmail - but php.net is running qmail...).  After that is 
done, set php.net hosts up to REJECT messages claiming to be from php.net 
(proper AUTH or TLS will circumvent this rejection).  End result: no more 
forgeries through the php.net servers.

---
 Please DO NOT carbon me on list replies.  I'll get my copy from the list.
 Founding member of the campaign against email bloat.

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



RE: [PHP] Hanmir I'm gonna kill you, you son of a..........

2003-10-17 Thread Sean Straw / PSE
This thread was flagged as probable Sp*am / twitmail at my server because 
of the abundance of punctuation in the subject, but on reviewing the sp*am 
report, I couldn't belp but look into what this thread must be about.

that [EMAIL PROTECTED] is REJECT'd. But for some reason the emails still come
through. All my other REJECT rules work, but just not this one.
Try using connect:(mailhost).hanmir.com on the LHS of your access db 
entry.  Be sure to set it to whatever the hanmir mailhost is, and reject it 
with an appropriate permanent failure message.

I can only imagine that the reason is because the address sendmail is
checking does not end up being hanmir.com. BUT I looked through the
email headers and the hanmir.com domain is plastered all over the place!
Anyone know what's up?
Well, after this message, I suspect that I may be blessed with an autoreply 
that I too can check out.

However, anyone processing mail on a *nix box and has a proper shell 
account there (even if you download and handle your email via POP from 
there) should seriously consider using PROCMAIL to handle their incoming 
email - it's trivial to deal with problem messages.  Easy to set up a 
twitlist to filter out messages from individuals who send autoreplies or 
suffer diarrhea of the keyboard.  Poof, gone.  No further interraction on 
your part is necessary.

If they were auto-replies for instance, one might auto forward them to an 
abuse account (this here is a rough sketch - I don't have the actual 
address of this moron, nor do I know if his domain has an abuse address - 
though if he's hosted at some service, the abuse address THERE might be 
appropriate - if indeed this hanmir is hanmir.com, it looks like an 
organization bigger than just one moron sending autoreplies):

:0
* ^From: [EMAIL PROTECTED]
* !^X-Loop: [EMAIL PROTECTED]
| formail -A X-Loop: [EMAIL PROTECTED] | $SENDMAIL [EMAIL PROTECTED]
With a slightly different invocation, it'd be possible to insert a 
complaint message in there and tack the original message and headers onto 
the tail end of the body, so that the message to abuse is actually a 
repetative complaint about the autoreply.

---
 Please DO NOT carbon me on list replies.  I'll get my copy from the list.
 Sean B. Straw / Professional Software Engineering
 Post Box 2395 / San Rafael, CA  94912-2395
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


Re: [PHP] Re: event cache management (no, not code cache) -- W32/Nimda filter

2001-09-22 Thread Sean Straw / PSE

At 23:13 2001-09-21 -0500, Richard Lynch wrote:
You are going to spend a *LOT* of time re-doing the work that went into SQL
db that you have eliminated...  Re-consider.

I wanted to make the module independant of an SQL service so that it could 
reach a wider audience by having fewer system requirements.

Under LINUX, so long as your data is less than 4K (?),
fopen(...,'a')/fwrite()/fclose() is atomic.  So if you are just dumping out
IP+timestamp and even some minimal data, you are set.

I'm considering going binary with the data, which means about 12 bytes per 
record, and makes them fixed length.  I can purge an item from the cache 
by overwriting the fields as allzero.  Problem is efficiently reading and 
writing the binary data between an array and the file.  Seems I'm going to 
spend more time massaging the data (either to convert it to/from binary 
form, or to split it into two arrays), than actually processing it.

If you are *not* using LINUX, your other option is, in fact, to flock() the
file.  You open it for reading, flock() the handle, fopen()

Yes, I'm well aware of the need to file lock.  My concerns lie within 
having to load the cache db, scan it for a match, deal with updating it as 
necessary, and whatnot in a modular method -- if I open and close the file 
between the lookup and update functions, some other process may update the 
file with the very same IP that I'm dealing with now.  So I've really got 
to open it and keep it open (and locked) until I've completed all my 
determination and updating.  Bugger.

You should also use http://php.net/register_shutdown_function to be sure you
never leave a file flock'ed if PHP pukes or something.

Good pointer.

Perhaps even a cron job to release any flocks older than XXX time somehow...

Hmm.  This sounds like something PHP should get a new function for: perhaps 
when a lock is established, an expire could be set by the locking function, 
and sometime later, when another PHP process attempts to open the file, PHP 
would realize it is a stale lock (as defined by the registered lock 
expiration), and remove it...  I'm not on PHP-Dev though.

Even *with* LINUX, at some point, you are going to want to shrink the file
so it doesn't grow to monster proportions, but you only want to throw away
the really old entries...

What I was thinking is that whenever a lookup was performed and resulted in 
an expired entry, if the expired entry was older than say, 1/2 the expire 
time, we'd take the opportunity right now to clean up the file.

You see, there's just all sorts of nasty things you need to worry about if
you go this route, and you really were better off with SQL where it's all
taken care of...  Re-consider again. :-)

The design consideration here is that an SQL dependance means anyone who 
might want to use the module (this is for dealing with CodeRed and 
W32/Nimda and no doubt the next IIS worm that strikes) must do SQL setup 
for a new database, etc.

oh, and after verifying that the whois protocol is indeed as trivial as I 
thought is was, I've dealt with that - so at the moment, my script isn't 
dependant upon any external utilities (obviously, support for updating a 
firewall would require an external script (fired up from cron), but that 
isn't required unless you're going to actually enable the firewalling 
capability, and it still isn't something that is exec'd from the PHP script).

---
  Please DO NOT carbon me on list replies.  I'll get my copy from the list.

  Sean B. Straw / Professional Software Engineering
  Post Box 2395 / San Rafael, CA  94912-2395


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP] nimda, etc.

2001-09-21 Thread Sean Straw / PSE

At 13:48 2001-09-21 -0700, Bill Rausch wrote:
 sleep( 300 );

I felt that if nothing else I could slow the worm down a little by
wasting its time before it races off to the next potential target.
Does what I'm doing make any sense or am I all confused?

I do like the concept behind the sleep idea, but this is going to tie up 
acesses to *YOUR* server, which means you're literally setting yourself up 
for a DoS.  I doubt that was a design goal.

I think setting up a script which hands off the vitising IP address to your 
firewall and stealths the requests would be much better.  If I could get an 
answer to a cache implementation question I posted here this morning, I'd 
be moving along to providing such a facility to those interested...

FTR, the implementation I have in place right now is invoked via a 
rewriterule in apache, so I don't log 404 errors.

---
  Please DO NOT carbon me on list replies.  I'll get my copy from the list.

  Sean B. Straw / Professional Software Engineering
  Post Box 2395 / San Rafael, CA  94912-2395


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




[PHP] event cache management (no, not code cache) -- W32/Nimda filter

2001-09-21 Thread Sean Straw / PSE


I'm working on something to deal with the W32/Nimda worm traffic, and in 
order for this to work, I need a cache management function - basically, as 
an event occurs, I check to see if the source IP is in the cache file 
already - if not, it gets added along with the current timestamp and 
actions are taken.  If it is in the cache, the original timestamp plus the 
expiration value is compared against the current timestamp - if it isn't 
expired, we just quit processing, whereas if the sum is less than the 
current time, then the entry is expired, and I'd update the cache timestamp 
to reflect the current event, while going and performing the actions (as if 
it wasn't there at all).

One aspect of this is dealing with sending emailed notifications to 
(ir)responsible parties for the hosts in question (rDNS - MX, and IP 
delegations are both used).  This is a processing impact which we'd simply 
not want to incurr for every Nimda hit - thus the need to keep track of 
which hosts we've dealt with in the previous 'n' hours and just drop them 
if we've seen them since.

I don't want to use an SQL DB, primarily because I'd like to make the 
script as self sufficient as possible

I haven't figured out how to efficiently deal with reading and writing a 
file which may be getting tweaked by a concurrent session - should the PHP 
script immediatley open and flock the cache file and keep it locked until 
it has completed operations, even though it may not need to write to the 
file (i.e. the entire decision making process should be within the confines 
of an flock()?)  Are there any efficiency tricks for loading a 
2-dimensional array from a file (source IP + timestamp)?  Is there some way 
I can make a daemon with PHP (manage the cache in one process while 
answering queries from other processes)?

I'm also looking to construct a script which may be executed under a cron 
job, which will add new hosts to the system firewall (either on the local 
host, or quite possibly, at the WAN interface, thereby protecting all the 
hosts on the LAN).  If anyone has already tackled such a thing, I'd 
appreciate hearing about it.

Also, does anyone have a whois implementation in PHP (the idea being to 
avoid exec'ing another process on the system if at all possible).
---
  Please DO NOT carbon me on list replies.  I'll get my copy from the list.

  Sean B. Straw / Professional Software Engineering
  Post Box 2395 / San Rafael, CA  94912-2395


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]