clutch

I am not familiar with the online variants of these scanners. I have heard of ISPs used virus scanners to check emails coming and going, and yet still miss the vast majority of worms and viruses coming through. As for McAfee, I have never had any problems when using the installed versions since v2.x.

Please stop cross-posting like you have been. We all get the hint, and we will eventually see one of these posts anyway...

Oh, and as to where I would have put it, I would have listed it under "Tweaks..." under win2k, and then made a post under "Tweaks..." in XP linking to it, and requesting that all replies be made to the first one in win2k.

Moderators cannot delete, only admins.

I just posted about this already, and CUViper is correct. This is the second thread that you have thrown all over the place. Now, if you want to use logic, then here is something for your to chew on: Why make it more difficult for people to respond to each on a given topic? Just as in this case, I responded to the cross-posting in another copy of this thread, and yet CUViper responded to this one. So, how will people know which one to respond to?

This might work for you as well: http://www.mlin.net/SMPSeesaw.shtml

Anybody here getting probed yet? My server at home got hit 4 times today (that I know of). I just started playing with ODBC logging to SQL so I could generate reports regarding usage, when I noticed this nice new "parameters" field that I have never bothered with before. Well, the reason why I noticed is that there are a bunch of "N"s followed by a specific series of characters. In addition, all four IPs were IIS boxes (1 from Spain, 2 from The Netherlands, and 1 from South Korea), all four were looking for the same file, and all four passed the same amount of info (via the parameter string, I imagine). I just wondered how many others have been swept here.

You seem to be doing it right, but do you have any sort of firewall between (including installed onto the server) you and the server? I will have to refresh my memory on the configuration of SMTP for Win2K, but when I do I may be posting again about it.

Are you all patched up for Code Red? If you get infected, one of the symptoms is the server may basically work itself to death for the worm, and then freeze up. Also, how much traffic are you seeing? You could also be getting scanned so often that IIS may be freezing with all of the hits.

Solidworks is for our Engineering dept primarily, but I use it to take existing models and tweak them for use in presentations and the like. It works rather well, and you can get a large amount of functionality for a really low price with this parasolid-based app.

Well, it appears that there's another automated tool for attacking web servers. Please look out for anything request is trying to get to the system directory. Atreyu and myself are getting pounded with the $hit out of nowhere, but URLScan has been canning all of the requests on my server.

Must have missed this one earlier, but here is what you get for options: NET SEND {name | * | /DOMAIN[:name] | /USERS} message Now, you can actually use the IP in place of the name. So, it could be: NET SEND 192.168.1.10 Test Have fun.

28MB, and the install was a couple of weeks ago. I have IE6, SP2 (with various hotfixes), Adobe Photoshop 6, Illustrator 9, InDesign 1.5, Pagemaker 7, Acrobat 5, Macromedia Flash 5 and Generator 2 extensions, MS Visual Studio 6 Enterprise Edition (with full MSDN Library install), Bryce 5, Office XP with FrontPage, Quake 3 Arena, SQL 2000 Enterprise Manager, Visio 2002 with Network Tools (and MSDE installed for use with network auto-discovery feature), McAfee VirusScan 4.5.1, Trillian, and some other stuff... I still have to install Solidworks 2001 (and plugins like CosmosWorks), but I just haven't gotten around to it. edit Oh, and Adobe GoLive! 5. I don't see why I forgot about it since I was just using it, but oh well.

Cool. While fiddling with URLScan, I accidentally, disabled the ability to use Frontpage extensions. Took a bit to figure it all out.

If you are already using IPSEC, then you are set in my eyes. You sound like you know what you are doing, and you should have great success. As for replication, I haven't messed with either version of SQL enough to have a good grip on it, but both versions of SQL 2K do support it (I know you have SQL 7, but in case you were thinking of upgrading...). Here is where I am getting our copy of SQL 2K Enterprise (single proc license): http://www.coast2coastaz.com/pcs1msft.htm The price is actually $4350, but that is a HELLUVA lot cheaper than the $17,800 that CDW quoted us. We got Exchange 5.5 from them last year, and they have had really good service. Now, here is the listing of the differences between them both main versions: http://www.microsoft.com/sql/howtobuy/choosing/default.asp

The only 2 things I can think of at the moment would be: 1. Is it possible that there is a rogue DHCP server on the network? 2. Have you tried to dissolve that DHCP pool and create another? Or better yet, have you tried to install the DHCP service on another system? Let me know.

That just means you are getting probed. If you use the IIS tool "URLScan", it will actually refer the incoming request against a set of rules, and will simply generate a 404 error and return that to the client.

First of all, Secondly, it sounds like you have a well thought out system for your network. It seems like you desire to store all the backend tier info on your SQL box, and have the web app query and return across both of your firewalls, right? If you lock down the responding traffic in the method you describe (only let it respond to the proper IP), it sounds rather strong. I do have a couple of questions though: 1. What is the nature of the information? Is it customer records (like account info) or some sort of proprietary information? 2. What is the speed of the link between them? 3. How many records do you plan on returning per session? One thing that I am not sure of (and I am actually in the process of learning) is the nature of SQL server in its replication. If you have a major amount of records to exchange back and forth, would it be possible to just have an SQL box at the co-location site replicate the database between itself and your SQL server? This would probably increase performance significantly, but would make the records more prone to "aging" (where the records on one database will not be inline with the other until their sync job kicks off) and may alleviate concerns to some extent about the security of traffic between the sites, as the exchange would ONLY occur at prescribed times, and some systems will allow for logons (like NT/2K) to only be usable within a certain time span. Now, while that may be a bit extreme (and probably not necessary), there are only a couple of things to worry about in using live transmissions between the web app and your SQL DB. Security-Generally, the only ways that somebody would get information from the DB would be to either: A. Access the SQL server directly, but you would refuse logon based on IP (spoofing could be used to send traffic in *maybe*, but it would only respond to the correct IP and not the hacker's thanks to the firewall), and B. Montior the traffic between the web app and the SQL box, but that would entail having a sniffer somewhere between the web app server (since that's the context most dynamic apps will run in, and not from the client) and the SQL box. The odds of this happening are low, and I am not well versed in the encryption methods that would be available for this mode of record exchange. Performance-If you pass a large amount of records back and forth between the web app and the SQL box (like paging records in ASP, vs a Stored Procedure) you could get a major slow down in the app over time. This is based on what I know of security, but I am sure there are much brighter people on this board in this subject than I will ever be. However, it would seem like your method should work rather well. If you do plan on exchanging information such as credit card info and the like, I would strongly suggest you talk to a professional consulting firm in your area, as they might be able to point you to VPN type tunneling (such as Shiva or even the Routing and Remote Access function of Win2K, where you can assign a key to the web server, and allow the SQL box to respond to it) such as IPSEC that can not only encrypt the traffic, but make the server seem "invisible" to systems trying to query it. I hope that helps a little, if at all...

Which tool was it? If you can tell me (just give me the URL) which one it is, I can probably help you fix it.

Cool, thanks.

Are you asking if you can use Net Send to communicate to PCs outside of your LAN (or subnet)? If so, then yes it can. What can happen is that there may be some sort of port filtering/forwarding mechanism (such as a firewall or NAT/PAT device) at the receiving end, and the communication isn't making it to the intended recipient. Although I can't find any documentation on this, I used Sniffer Pro to check on what port(s) it uses, and it seems to rely on the NetBIOS port (139) for transmission and initial sync. Now, a reply port can seem to vary (one session was 1152, another session was 2204--similar in behavior to FTP) but you would still need 139 forwarded to the workstaion in question if the target PC is behind a firewall/NAT device.

With heavy usage, my Palm IIIxe can run 1.5 to 2 months on 2 AAA batteries. And when I send sales reps and execs overseas, there's no need for power converters. Once a PPC can run for better than 2 weeks under heavy usage, I'll consider it. Until then, it's just a really cool looking toy.

I would, but oh wait, I need more than 3 hours of battery life...

Tell me how any of those virus checkers would have stopped Code Red? Funny, I have a pretty good idea that the majority of those servers had virus scanners, and yet NONE of those scanner did a damn thing about that worm. If you are simply looking for a debate as to the use of a firewall, then I will drop this as it can drag on forever. Simply put, relying on virus scanners to protect a network in a manner that a firewall would (packet detection and analysis) is a poor idea. The two types are entirely different from each other, and are meant to address two separate needs. As for being hacked "properly", there isn't such a thing. Why wouldn't you classify something as Code Red or any other use of an exploit that can not only deface a web page, but can in fact take CONTROL of a server and have it do its bidding is in fact a hack? Just because it wasn't one person that spent hours, days, weeks, or months behind a terminal trying to get financial records? Hacks don't have to be for the purpose of gaining useful information from one or more machines (like you would see in movies), but it is simply the act of accessing/controling another machine that you would not normally have access to. And finally, the insanely fast spread of that worm shows that the possibility of being hacked is very great indeed. I was getting scanned in upwards of 40-50 times an hour by other machines that were infected. These machines would not normally do such a thing, and were in fact "hacked". Not only would the use of basic firewalls have eliminated this, but some of the more advanced firewalls can also monitor what traffic is coming in and check to see if it's coded properly (as in not having alternate character sets, or using "broken" packets and flooding as in a DDoS attack). Now, I have yet to see a virus scanner do that. Because if it did, it would be a firewall.

Well, the Code Red worm is a classic case of people that had an exploit on their systems that was used to attack others. They spread much faster on the broadband networks (cable and DSL subnets) with CRII, and almost none of those systems had anything worthwhile to a traditional hacker (other than the fact it was another zombie that could be used in an attack). Now, if a simple firewall was installed using most of the defaults, port 80 wouldn't have even been open, and those machines would have never been infected. If a person that was "knowingly" hosting a website, and knew how to open/forward the necessary ports, then that person should have also been more than capable enough of installing patches. That however, is a whole other debate...