|
|
Home | Switchboard | Unix Administration | Red Hat | TCP/IP Networks | Neoliberalism | Toxic Managers |
| (slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and bastardization of classic Unix | |||||||
| Malware | 2019 | 2018 | 2017 | 2016 | 2015 | 2014 | 2013 | 2012 | 2011 | 2010 |
| 2009 | 2008 | 2007 | 2006 | 2005 | 2004 | 2003 | 2002 | 2001 | 2000 | 1999 |
|
|
Switchboard | ||||
| Latest | |||||
| Past week | |||||
| Past month | |||||
 |
 |
 |
Some business and technology professionals are running out of patience. "The issues around these vulnerabilities are escalating to the point where it's not just CIOs or CTOs, it's corporate officers, it's boards of directors asking: 'What are we going to do?'" says Ruth Harenchar, CIO of Bowne & Co., which last week scrambled to patch 4,500 Windows PCs and 500 servers in the United States and more overseas. "The situation appears to be getting worse, not better."
The patching work has thrown Bowne & Co.'s technology projects off schedule. Now, the specialty-printing-services company is assessing its options. Among them: redesigning its network around a thin-client model to reduce the number of PCs running Windows and, on other machines, migrating to Linux. "It's getting to be enough of a burden that you have to seriously start thinking about alternatives," Harenchar says.
Raymond James & Associates has assembled a team of IT staffers to manage the constant patching. "Organizations have to mobilize and realize this is going to be a way of life for the foreseeable future," says VP of IS Gene Fredriksen.
The financial-services firm, with offices around the world, last week began the arduous task of patching 10,000 PCs and 1,000 servers. "The pressure is on," Fredriksen says. "Anybody that isn't patched by the weekend is going to have trouble." The fear is that the latest vulnerability leaves Windows computers open to a Blaster-like worm. "There's a very good chance that a worm is going to be developed" to take advantage of the latest security holes, says ISS's Ingevaldson.
"People are getting fed up," says Lloyd Hession, chief information security officer at financial-network provider Radianz, adding that the number of Windows patches is reaching "epic proportions." The situation is causing more than just a few disgruntled customers to re-evaluate how much they use Microsoft products. Says Gartner security analyst John Pescatore, "There's definitely a very large trend towards that."
|
|
|
Four new threats expose failure to apply simple patches to vulnerable systems. The damage caused by four significant new viruses in recent days has highlighted how poor patching and lax security are making life easy for virus writers. The worldwide alert over the Blaster worm, and its subsequent infection rate, has flagged up the failure of many IT managers to ensure that systems are properly patched.
Related articles
|
|
|
The most important thing Sobig.F proved is that most enterprise AV products are really outdated technology and should be modernized or abandoned (or at least reconfigured). Some proved to be irrevocably stupidly designed. The main damage from the worm was not the infections (although the users proved that they learned nothing from the Klez; to a certain extent Sobig represented an Internet wise quiz of users IQ ;-) itself, it used an old mechanism and can be easily stopped on the gateway, but millions and millions of messages that gateway AV systems delivered to wrong users (the "from" address was spoofed, like in Klez.H ). And those mails really put the users under substantial stress. Paradoxically the most affective systems to fight Sobig were spam filters ;-)
Again, in the corporate environment worm is effective only if executable attachments are allowed on the virus gateway. So chances are pretty slim and the main stream of letters were from home users to corporate directories.
Actually there is nothing interesting in this worm other then tremendous success of the an old-fashioned scheme. May be the worm datamines the harddrive for addresses more effectively then its predecessors but that's it.
All-in-all the story was more about the number of naive people and stupid AV software then anything else.
One point underscored by the new SoBig variant is that computer users are still ignorant about the consequences Like Klex.H the worm invalidated the old advice "Don't open attachments unless you know who it's from." It should be "Don't open an attachment unless you are expecting one."
|
|
|
I suspect that in a corporate network with 10K or more workstations spreading
into several geographical locations (plus remote users, business partners,
outsourcers) such a worm can probably survive for a month or more. With the
typical level of tech support in a large corporation I suspect this worm is
still running in many large corporate networks, so they are not down just
because the replication mechanism is not efficient and the virus has no payload.
And right now I do not know how new type of the same worm can be prevented after
it
sneaks into corporate network (if it uses ports that might cripple corporate
network if filtered on routers). I
All-in-all I would think about it as something that really might interest all three letter agencies as the effect on corporate networks of similar worms can be substantial.
The exploit itself is very close to 'dcom.c' and so far appears to use the "universal Win2k" offset only. Infection sequence:
msblast.exe is packed with UPX and will self extract. The size of the binary is about 11kByte unpacked, and 6kBytes packed. MD5sum packed: 5ae700c1dffb00cef492844a4db6cd69 (6176 Bytes). Ports
Discussion points:
1. If the company does not use Kerberus or Oracle 9i then the port 4444 represents a weak link in the worm propagation scheme and can be blocked on all routers for a considerable period of time (unlike port TCP 139 that can be blocked only temporarily at the peak of epidemics). See Cisco Security Notice W32.BLASTER Worm Mitigation Recommendations
2. Registry hardening and control is now a viral part of corporate AV defense. See for example RegistryProt
3. Most AV vendors fails miserably and were unable to disinfect the worm until Monday, Aug 10. If you add the fact that many corporate signature replication schemes are not very reliable of fast that means that they did almost nothing to prevent the spread of the worm. F-secure was/is especially bad: unable to disinfect automatically even a week after the first appearance of the worm. It look they are still living in a file virus world and refuse to adapt to a new situation (situation the repeats they misfortunes with fighting macro viruses :-). In many cases installed F-secure can be considered as to be a Trojan horse that just slows PC down without much return on investment ;-) WormGuard and similar tools "worm watchers" might now have an edge is a corporate environment. At least they do not slow i/o that much.
4. In case Netware is used for file sharing and printing, custom disinfection tools can be run via login script. That provide a nice opportunity to fight corporate redtape. Both Symantec and F-secure have disinfection tools:
- F-secure F-LOVSAN tool ftp://ftp.f-secure.com/anti-virus/tools/f-lovsan.zip
- Symantec W32.Blaster.Worm remover
[Aug 5, 2003] Mimail: a new virus that uses IE exploit. Stressed the necessity of IE patching in corp. env. and revamping of email infrastructure to include dedicated checkpoint both inbound and outbound mail.
Discussion points:
1. If the company does not control communication to internal SMTP server this now spells troubles. If the company uses Lotus Notes then the first step in improving mail security against similar worm attacks would be prohibiting to communicate the internal SMTP server with any server/workstation that does not have a valid DNS entry (most DHCP servers do not provide automatic DNS resolution). I think that this is the most viable (and reasonably effective) first step in improving email security from similar viruses/worms attacks.
2. If the network uses an internal DNS root and namespace, where all authority for DNS zones is internal then email infrastructure is more secure but also more complex. This complete internal/external DNS separation significantly complicates email routing (along with other problems). But it serves as an effective tool to block worms propagation outside.
3. After mimail virus, the internal SMTP server became a more critical part of AV defense because this is the point where virus communication will be directed to in the case a new worm/virus will be able to find it
4. Spam filters were more effective against the worm the first two days then any AV products :-)
|
|
|
Description: RegistryProt is a 100% free, standalone, compact, low-level realtime registry monitor and protector, that adds another dimension to Windows security and intrusion detection. By monitoring important locations and keys in the Windows system registry, RegistryProt will alert whenever a key is added or changed, and then give the option of accepting the key change, reverting back to the original key setting, or deleting the key. RegistryProt's most useful attribute is that it will detect the vast majority of Trojans at the exact moment that they infect/install themselves into your system, and as such provides a new dimension in Trojan and intrusion detection.
RegRun 3 Security Suite RegRun Watch Dog provides silent monitoring of the startup programs during your Windows working session.
Monitoring Registry Changes - Page 1-3 How to monitor Registry?
It's *simple*, the Windows API function RegNotifyChangeKeyValue is capable of notifying the caller (your "Delphi code") about changes to the attributes or contents of a specified registry key. It even knows how to notify about changes that happened in the specified (Registry) key and all of its subkeys.
This is, in general, how the RegNotifyChangeKeyValue function operates, and how to make it work in the way you want it to:
You supply the function with an open Registry key handle and a Windows event object, plus some other attributes,
The function then uses the event to signal when a change occurs in the specified key,
The process of waiting for events needs to be handled in a (separate) thread, so that the main program is not blocked during the wait,
When a change occurs, you send a message to the window (form) that initiated registry monitoring, Monitoring continues (trhead runs) until you tell it to stop. RegNotifyChangeKeyValue
First, let's look "into" the RegNotifyChangeKeyValue function. As with the most API functions, Delphi enables you to call it directly since it is declared in the Windows unit.Here's the declaration:
function RegNotifyChangeKeyValue( hKey : HKEY, // handle of key to watch bWatchSubtree : LongBool, // flag for subkey notification dwNotifyFilter : Cardinal, // changes to be reported hEvent : Cardinal, // handle of signaled event fAsynchronous : LongBool // flag for asynchronous reporting ) : integer;A short description of the parameters:
hKey - Specifies an open key in which to look for changes. For example 'HKEY_LOCAL_MACHINE/Software/ADP'
bWatchSubtree - Specifies whether to watch for the changes in all the subkeys of the hKey parameter
dwNotifyFilter - Specifies a set of flags that control which changes should be reported. The value of this parameter can be a combination of the following values
REG_NOTIFY_CHANGE_NAME - subkey is added or deleted
REG_NOTIFY_CHANGE_ATTRIBUTES - attributes of the key are changed
REG_NOTIFY_CHANGE_LAST_SET - value of a key is changed, added or deleted
REG_NOTIFY_CHANGE_SECURITY - key security descriptor is changed
hEvent - handle to the event that gets fired
fAsynchronous - how to signal the event.
OK, all set. Now we proceed to building a thread object with the main function of monitoring the Registry.
But first, a note. If you have ever tried creating such a project yourself and were constantly having problems like: "it does not work on subkeys" or "it fires only once" or similar, ... read on ... all the problems are solved on the next page!Before we start adding code to a sample Delphi project capable of monitoring Registry changes we have to create a new thread object - the one that, in a loop, waits for a change to happen.
For the sake of simplicity we'll add this thread class in an existing project. First, start Delphi. By default a new project with one form is created. Second, add a TMemo component to that form. This is all we need, any change to the Registry will be added to the Memo. Now, we move onto creating that thread...
The TRegMonitorThread Class
To create a new Thread object, you simply point to (main Delphi menu) File | New | Other and select "Thread Object", a "New Thread Object" dialog box will ask you to specify the name for your class.
Name it 'TRegMonitorThread', click OK. This will add a new unit to your project, with a skeleton code (and an empty Execute function) that defines the TRegMonitorThread class as a class derived from TThread.Note: if you have never worked with threads in Delphi - why not start now! Either way, "Threading in Delphi" has all the information about creating multithread applications with Delphi that you can think of.
Now, I'll show you some code snippets from the TRegMonitorThread class. Later, you'll have the option to download all the code from the article.
Let's see. The main code goes in the Execute procedure of the thread object. As explained in the beginning of the article, the code in the Execute procedure is in fact one big loop - executes until you terminate the monitoring process. In the loop, the code calls the WaitForSingleObject API that enters a wait state and uses almost no CPU cycles until a condition is met. The condition we are waiting for, is the event called by the RegNotifyChangeKeyValue function.
This is how the above looks when talking Delphi language:
procedure TRegMonitorThread.InitThread; begin FReg.RootKey := RootKey; if not FReg.OpenKeyReadOnly(Key) then begin raise Exception.Create('Unable to open registry key ' + Key); end; FEvent := CreateEvent(nil, True, False, 'RegMonitorChange'); RegNotifyChangeKeyValue(FReg.CurrentKey, 1, Filter, FEvent, 1); end; procedure TRegMonitorThread.Execute; begin InitThread; while not Terminated do begin if WaitForSingleObject(FEvent, INFINITE) = WAIT_OBJECT_0 then begin fChangeData.RootKey := RootKey; fChangeData.Key := Key; SendMessage(Wnd, WM_REGCHANGE, RootKey, LongInt(PChar(Key))); ResetEvent(FEvent); RegNotifyChangeKeyValue(FReg.CurrentKey, 1, Filter, FEvent, 1); end; end; end;Note: The Execute function first calls the InitThread procedure that uses the values of the properties of the class to create the event and to make the first call to RegNotifyChangeKeyValue function. The properties of the TRegMonitorThread class provide a simpler way for a developer to supply values to the RegNotifyChangeKeyValue function and other structures defined inside the thread class.
Now, what happens when the wait loop traps a Registry change?
The fChangeData is a record type variable (exposed as a read-only property) in which we save the current value of the Key where the change has occurred. The code upon notification sends a user defined message to the window (Wnd parameter) that called the monitoring thread. And finally, we call the RegNotifyChangeKeyValue again.This is, more or less, everything you need to enable Registry monitoring using Delphi. But, and there is always a "but", due to some situations when monitoring sub-keys is not working you'll need to redeclare the RegNotifyChangeKeyValue function by changing some parameters from Boolean to Integer, like this:
Next, you are ready to add the code in the main project to call the TRegMonitorThread. Since we now have developed a thread that monitors the Registry and listens to specified changes, let's see how to call the monitoring code from a Delphi project. If you recall, you have dropped a TMemo component on a form, when any specified change occurs, the change will be reported in this memo.
An example of usage
First, add a variable of type TRegMonitorThread in the interface var section (under the Form1: TForm1; line). Second, add a declaration of the procedure that will handle a message received from the thread class, in the private part of the Form1 declaration, and finally add the following code in the OnCreate event of the Form:
procedure TForm1.FormCreate(Sender: TObject); begin RegMonitorThread := TRegMonitorThread.Create; with RegMonitorThread do begin FreeOnTerminate:=True; Wnd := Form1.Handle; Key := 'Software\ADP'; RootKey := HKEY_LOCAL_MACHINE; WatchSub := True; Resume; end; end;Next, we add the code in the message handling procedure
procedure TForm1.WMREGCHANGE(var Msg: TMessage); begin with Memo1.Lines Add('-----------------------------------'); Add('Registry change at ' + DateTimeToStr(Now)); Add(IntToStr(RegMonitorThread.ChangeData.RootKey) + ' - ' + RegMonitorThread.ChangeData.Key); end;The actual WMREGCHANGE procedure is declared as
procedure WMREGCHANGE(var Msg : TMessage); message WM_REGCHANGE;The above procedure responds to a WM_REGCHANGE message defined in the TRegMonitorThread class as a user defined message.
This is how the "program" looks at run time (after some manual Registry editing)
As you can see, the code "only" reports that a change has been captured, it does provide the time of the change but no other information like, for example, the name of the key added / deleted / edited.
After you have trapped the change in Registry you could, for example, iterate through all the keys you are interested in and compare them to some values that *should* be there. All in all, what you will do with the change remains for you to handle.Source code
That's it. As I always love to say: "as simple as only Delphi can be!". The next page of the article provides the full source to both the TRegMonitorThread class and the sample project.
If you have any questions please post to the Delphi Programming Forum.
{ Zarko Gajic, BSCS About.com Guide to Delphi Programming http://delphi.about.com email: [email protected] free newsletter: http://delphi.about.com/library/blnewsletter.htm forum: http://forums.about.com/ab-delphi/start/ }
[Jan 25, 2003] SQLSlammer punished some corporate suckers who do not at least quarterly patch their OSes and applications :-). The worm, exploiting an old flaw in Microsoft SQL Server, underscores a dirty little secret in the IT industry: administrators are slow to fix even widely publicized problems. The worm (also called Worm.SQL.Helkern exploits an old (see July 2002 CERT advisory) vulnerability in SQL server.
Discussion points for the classroom:
People need to do a better job about fixing vulnerabilities because in this case they cause other more responsible people to suffer downtime. Also why so many database servers were connected directly to the internet - any database server should only accept connections from trusted hosts. It Internet a sucker paradise ?
One Slasdot reader aptly put it:
...Yes, you still need to patch, use non-blank SA passwords and the other things you suggest, but if you have an SQL server (any SQL server) directly visible to the Internet then you are either a fscking moron or have a very abnormal circumstance. A database server is a backend server, and should be completely hidden from the Internet by not one but two layers of firewalls.
The initial report of the worm can be seen at BugTrack. More technical description can be found at kaspersky.com. Here is a short descriptive summary for Softpanorama users:
The main lesson of this worm is simple: you need to patch your systems or... Three types of unpached for this particular vulnerabilty (since July 2002) systems (Windows NT and Windows 2000 with a particular version of SQL server engine installed) were affected:
- Microsoft SQL Server 7.0; Microsoft SQL Server 2000; Microsoft SQL Server Desktop Engine 2000
- In addition, developers using Microsoft's Data Engine 1.0 and Microsoft Desktop Engine 2000 may not have known they were vulnerable to the worm. The software is included in Visual Studio .NET, ASP.NET Web Matrix Tool, Office XP Developer Edition, MSDN Universal and Enterprise subscriptions and Microsoft Access. MSDE is also included in Microsoft Application Center 2000.
This is a tiny (376 bytes) worm that start spreading ~ at 11pm EST January 24, 2003. Some random screen shots and information about the worm can be found HERE. [digitaloffense.net]
Around midnight a lot of IDS sensors registered an huge increase in the number of source IPs scanning for 1434/udp. The attacks lasted almost 12 hours (probably up to noon Saturday, Jan 25, 2003) until most affected SQL servers were brought down (it took some some due to Saturday). Sites monitoring the health of the Internet reported significant slowdowns globally. Here are some raw data (It looks like the data collector did not understand what was happening) :
MASSIVE DDOS ATTACKS ALL OVER U.S.
We are monitoring massive Distributed Denial of Service attacks all over the U.S. tonight starting at around 11:30 PM CST. As many as 5 of the 13 root nameserver have been down, up to 10 with massive packet loss (xx%):
Internet Status to Root Name Servers
Date: Fri Jan 24 21:37:00 PST 2003Place Address Packet Loss Time: Min/Avg/Max
Root b.root-servers.net 53% 25/40/48
Root c.root-servers.net 0% 82/82/82
Root e.root-servers.net 20% 16/29/33
Root f.root-servers.net 26% 17/27/32
Root h.root-servers.net 20% 91/101/108
Root i.root-servers.net 26% 190/199/205
Root j.root-servers.net 26% 81/91/96
Root k.root-servers.net 64% 172/188/201
Root l.root-servers.net 0% 5/5/6
Root m.root-servers.net 33% 160/171/205
GTLD b.gtld-servers.net 26% 52/63/67
GTLD c.gtld-servers.net 31% 85/93/95
GTLD d.gtld-servers.net 13% 88/100/103
GTLD f.gtld-servers.net 22% 38/50/57
GTLD i.gtld-servers.net 0% 198/200/203
GTLD k.gtld-servers.net 24% 90/100/105
GTLD l.gtld-servers.net 33% 128/138/171
All backbone providers are suffering major packet loss (XX%):Place Address Packet Loss Time: Min/Avg/Max
AboveNet ns.above.net 28% 53/64/66
AGIS ns1.agis.net 26% 62/74/78
AlohaNet nuhou.aloha.net 35% 84/94/98
ANS ns.ans.net 26% 83/97/100
BBN-NearNet nic.near.net 28% 91/114/572
BBN-BARRnet ns1.barrnet.net 26% 16/26/32
Best ns.best.com 35% 79/89/95
Concentric nameserver.concentric.net 35% 18/31/56
CW ns.cw.net 28% 88/98/105
DIGEX ns.digex.net 31% 78/86/91
ENTER.NET dns.enter.net 28% 91/104/108
Epoch Internet ns1.hlc.net 33% 37/48/52
Flash net ns1.flash.net 17% 80/92/94
GetNet ns1.getnet.com 20% 40/52/56
GlobalCrossing name.roc.gblx.net 24% 85/97/104
GoodNet ns1.good.net 31% 83/92/97
GridNet grid.net 20% 80/92/101
IDT Net ns.idt.net 20% 91/104/121
Internex nic1.internex.net 26% 18/31/35
MCI ns.mci.net 22% 91/103/107
MindSpring itchy.mindspring.net 15% 75/88/106
NAP.NET ns2.nap.net 20% 73/85/94
PacBell ns1.pbi.net 0% 89/89/90
Primenet dns1.primenet.net 20% 31/41/45
PSI ns.psi.net 0% 82/84/160
RAINet ns.rain.net 31% 40/49/53
SAVVIS ns1.savvis.net 31% 88/99/102
SprintLink ns1.sprintlink.net 11% 15/27/35
UUNet,AlterNet auth00.ns.uu.net 26% 89/98/103
Verio-West ns0.verio.net 22% 31/42/47
Verio-East ns1.verio.net 22% 86/96/101
VISInet ceylon.visinet.ca 20% 102/116/188
MoonGlobal-ClubNET ns.clubnet.net 0% 0/1/2
MoonGlobal-Netway dns.nwc.net 4% 6/6/7
MoonGlobal-Netxactics verdi.netxactics.com 4% 6/6/7
InterWorld ns.interworld.net 0% 4/4/5It's massive, no word on source yet. We are watching it closely.
Brad G
www.americanintelligence.us
American Intelligence
All-in all worm created a DoS-style multicast attack overloading routers and bringing some corporate Intranets down. Looks like the worm had found one of their extranet apps based on SQL Server , hopped over the firewall, and then was inside. Their internal network collapsed under the load. Quite embarassing, IMHO. Some bank networks were affected for a a large part of Saturday
SEATTLE (Reuters) - Bank of America Corp.
said on Saturday that customers at a majority of its 13,000 automatic teller machines were unable to process customer transactions after a malicious computer worm nearly froze Internet traffic worldwide.
Bank of America spokeswoman Lisa Gagnon said by phone from the company's headquarters in Charlotte, North Carolina, that many, if not a majority of the No. 3 U.S. bank's ATMs were back online and that their automated banking network would recover by late Saturday.
Web traffic slowed suddenly and dramatically worldwide for hours after a fast-spreading computer worm clogged pipelines of the global network carrying data, Web pages and e-mail, officials said. The worm sends multicast packets to randomly generated IP addresses, meaning with only one "send" command hits all the 255 machines in a C-subnet, more than that in B subnet (some corporation use net mask 255.255.0.0 or something like that on the intranet). All infected SQL servers with Windows 2000 try to connect to other randomly selected IP addresses in an endless loop.
The worm attacks only unpatched MS SQL servers. Because the MS SQL servers are often installed on the same computer as Web server and has direct connection to the internet this worm brings down servers that are not protected by the firewall (the worm uses 1434/udp to exploit a buffer overflow in MS SQL server and this port should be blocked).
It looks like mainly portal attack. In a few cases internal users also are affected as the worm spread to the intranet because of primitive architecture, errors in configuration or both.
The disinfection consists of bringing affected servers down and installing the patch. Please note that this worm is not a massmailer: it does not send any e-mails.
Those companies which use NAT on the Intranet and/or do not run SQL servers on DMZ at all were not affected.
If necessary recheck and correct firewall rules as for port TCP and UDP port 1434.
The worm only spreads as an in-memory process: it never writes any files to the hard drive. In this sense it is similar to the Code Red from July 2001. As the worm does not infect or create any new files, an infected machine can be cleaned by simply rebooting the machine.
However, if the machine is connected to the network without applying patches for MS SQL Server it might be reinfected.
For patch information, see:
http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/bulletin/MS02-039.aspHere is an interesting Slashdot discussion:
Re:As I said in a previous post... (Score:5, Informative)
by Anonymous Coward on Saturday January 25, @08:08AM (#5156319)What the heck was it doing open in the first place?
When the SQL Server 2000 client Net-Libraries connect to an instance of SQL Server
2000, only the network name of the computer running the instance and the instance
name are required. When an application requests a connection to a remote computer,
Dbnetlib.dll opens a connection to UDP port 1434 on the computer network name
specified in the connection. All computers running an instance of SQL Server 2000
listen on this port. When a client Dbnetlib.dll connects to this port, the server
returns a packet listing all the instances running on the server. For each instance,
the packet reports the server Net-Libraries and network addresses the instance is
listening on. After the Dbnetlib.dll on the application computer receives this
packet, it chooses a Net-Library that is enabled on both the application computer and
on the instance of SQL Server, and makes a connection to the address listed for that
Net-Library in the packet.So the UDP 1434 port is open when the SQL Server is started to listen all the clients
with any IP address on this port. SQL Server only receives the packet from the client
on this port to determine which instance the client attempts to access and return the
related information of the SQL Server to the clients. Then, the clients can create
the connection to the SQL Server with the protocol enabled on the server side.
One at our site cut itself off from the net... (Score:2)
by weave (48069) <[email protected]> on Saturday January 25, @07:51AM (#5156248)
(http://www.weaverling.org/ | Last Journal: Thursday November 21, @02:34PM)A server at one of our campuses (a college, campuses all over the state) got infected around 0900 UT and started hammering the hell out of our WAN and their local LAN, sending 10.4MB/sec through the router and then 1.2MB/sec out our internet line (bytes not bits). It stopped about an hour later. Turns out it flooded the router so hard it looks like that router has shut down. I can't ping a darn thing inside that campus now.... Fitting justice.
Re:First hand report (Score:5, Insightful)
by Dynedain (141758) <slashdot@anthonR ... com minus distro> on Saturday January 25, @02:04PM (#5157757)
(http://www.anthonymclin.com/)No, once this blows over it's time to apply the fucking patch. It's been available for six months mind you.
The patch does not affect routers stupid. Just because his routers are all lit up with massive amounts of traffic, does not mean that his servers are unpatched!
My link was down for 4 hours from the flooding with everything all lit up, and I'm not even running an SQL server.Re:One at our site cut itself off from the net... (Score:4, Interesting)
by weave (48069) <[email protected]> on Saturday January 25, @09:00AM (#5156475)
(http://www.weaverling.org/ | Last Journal: Thursday November 21, @02:34PM)Looks like this post to bugtraq explains why that router at my college died from this: "Tier 1 backbones are reporting a bad night: routing instabilities, one major dropped most of its peering for a while, the volume from this triggers the Cisco netflow switching bug and is causing routers to lock up at places, etc."
ISP's fault? (Score:3, Interesting)
by YellowElectricRat (637662) on Saturday January 25, @06:21PM (#5158950)When will the ISPs start getting off their respecitve behinds and start doing something about this? With the broadband ISPs subnets accounting for so much of the destructive power of these DDoS attacks, they have a responsibility to at least attempt to ameliorate their impact. It's not hard to set up simple routing rules to at least curb some of these attacks. Hell, a lot of ISPs still even route spoofed IP packets out of their networks - this is nowhere near acceptable. Realistically, there is no real application for a constant stream of ICMP traffic coming from a single node - there should at least be a maximum allocatable bandwidth for ICMP set at the ISPs gateway. Obviously UDP and TCP based floods are more difficult to manage, but throttling ICMP based floods would be a step in the right direction.
All this is IMHO, of course - users have a responsibility to secure their machines, obviously, but it's going to be a hell of a lot easier to secure a few gateways and routers than a million home PCs.
Re:Egress filtering (Score:1)
by fimbulvetr (598306) on Sunday January 19, @08:53PM (#5116092)Part of the problem is all the totally clueless ISPs which don't do proper egress filtering. That is, they don't filter out outgoing packets with falsified sender addresses >> Clueless eh?
If I am assuming correctly, the general public in the world has had years to pick up trash in the ditches and fields left by a small percentage of the non-caring population. But I still see very few people doing this, possibly the same percentage of ISP's who perform these big brother techniques.
Come to think of it, what sysadmin is going to give you the time of day?
With internet service battling for the ~$4.95/mo arena, I don't see much use in hiring but one sysadmin for this position, and making sure he can handle hundreds of thousands of people a month with his setup, pay him $200k/yr, and outsource the tech support.
The day ISPs start keeping the bad guys away from you is the day you convince the general public that internet access is really worth that few extra bucks, and next time, choose your local ISP.
Once this is accomplished, I'll configure my router to that specification, and we can go on our merry ways.
Until then my routers stay the way they are, you can have your "Make the internet a safer place" cult, and we may see each other again.
My schema is designed for maximum scalibility, minimum filtering (due to load), and most of all, 99.999.
[Jan 24, 2003] Could Attack on DALnet Spell End for IRC By Thor Olavsrud
For at least a month, distributed denial of service (define), or DDOS, attacks have been crippling DALnet, one of the world's largest Internet Relay Chat (define) networks, bringing it to its knees and raising the possibility that many hosting providers may refuse to host IRC servers at all.
"DALnet is presently suffering extensive and prolonged Distributed Denial of Service attacks against our IRC servers, Web server, mail servers and DNS systems," DALnet said on its Web site. "These attacks are causing great inconvenience and financial loss to many of the organizations that host our services, as such some of them have suspended or discontinued their support of DALnet."
IRC, developed by Jarkko Oikarinen of Finland in 1988, allows people connected anywhere on the Internet to join in live discussions. Each discussion is on a "channel," and many people can join at once. DALnet was one of the earliest IRC networks, formed by users of EFnet (Eris Free Network) in June 1994 because of the netsplits (caused when the connection of one or more servers in a network is broken) and lag that were plaguing that network. DALnet pioneered Services, which allowed users to control their presence online without being harassed or having channels stolen from under them.
But these days DALnet -- which is manned by volunteers and run with equipment and bandwidth donated as a service to the Internet community -- is hanging on by a thread as sustained DDoS attacks flood its servers and even threaten the networks that host its servers. The attacks have forced DALnet's administrators to take down most of its client servers and leave them down rather than risk taking down its hosts.
"Yes, as you all know, DALnet has been attacked again by criminals who, for reasons known only to themselves, choose to spoil the enjoyment of so many," Emma/Curve, chief editor of the DALnetizen ezine and one of DALnet's administrators, wrote in the January issue of the ezine. "These latest attacks are worse than any of the server administrators have seen before, attacks large enough to cripple the networks which host our servers, let alone the servers themselves."
The attacks come in the form of 'botnets,' whole networks of malicious bots (define), created by Trojans (define), which flood DALnet's network with packets. According to Curve, those packets are coming in at a rate of Gbps (define).
"It's no secret that DALnet has suffered massive attacks recently, far greater than anything we've seen before," she said. "We've been ravaged by DDOS attacks in the Gbps range, attacks which are not just crippling our IRC servers, but causing disruption to the providers who host those servers."
She continued, "Why do I say that more than DALnet is at stake? Well, because the more these people amass herds of infected computers (botnets) to attack IRC servers with, the more service providers will quickly come to the conclusion that hosting an IRC server is a liability. Already many providers simply won't countenance hosting an IRC server and if this random vandalism continues, the harder it will be for non-profit IRC to continue in any reasonable form at all. That could jeopardize the future for all IRC networks, not simply DALnet."
The Trojan spreads through e-mail, or even when a user visits a Web site with a bit of hidden code, and the users won't know unless their anti-virus software is up to snuff. Once the Trojan makes its way onto a machine, the next time that computer connects to the Internet the Trojan will start up an IRC client and connect to a server -- often an IRC server set up on a shell account and paid for with a stolen credit card. The Trojan then creates a bot which is programmed to join a certain channel once it has connected.
A successful Trojan which has propagated widely can fill a channel with bots. Curve said she and other members of DALnet's Exploits Team have seen channels with as many as 4,000 to 5,000 bots -- each a home computer infected with a Trojan. A collection of such bots in a channel is a botnet.
Once the person who wrote the Trojan comes online, the botnet is waiting for him, and he can use it for a number of things, the worst being a DDOS -- using hundreds or thousands of bots to send data to a server until its connection becomes saturated and it crashes. Not only does such an attack inconvenience chatters using IRC services, it can also affect the service providers who host IRC servers, preventing their customers -- even ones who don't use IRC -- from going online.
"It could be surmised that people who launch DDOS attacks know their intended target and can find enough bandwidth to bring the target down," Aaron Schultz, a provider of DALnet hosting, wrote in the January issue of DALnetizen. "The problem that most don't seem to think about are the related networks which also get hit. The small ISP which has an infected customer who suddenly starts using all available bandwidth, the nationwide latency created on some networks due to the amount of packets or the small businesses that have servers on a network near the intended target."
"Another example of innocent targets being hit are when ISPs experience nationwide latency and regional outages due to these attacks," he wrote. "Are the attacks that I receive that have caused such major outages attacks on me, or the entire U.S.? And should all of the ISP's Southern California customers be taken offline just because of someone's disagreement with DALnet? No."
DALnet administrators continue to hold out hope that the situation can be resolved. DALnet said it is working with a number of law enforcement agencies to track down those responsible, has lodged complaints with the ISPs it has been able to trace, and has the help of experts in dealing with DDOS attacks.
So when will the attacks stop? "We don't know," DALnet said. "They will stop when either the attackers decide to stop attacking, the attackers get arrested or shut down by their ISPs, or when DALnet runs out of goodwill from its sponsors and is forced to close."
Anyone with information about the attacks is asked to submit it to DALnet's contact form.
See also EnterTheGame (an IRC network with ~10K users) had some attacks this summer, but they eventually tracked down the attacker and he was raided by the FBI - see the press release [enterthegame.com].
The end of Dalnet != The end of IRC (Score:2, Insightful)
by windows (452268) on Saturday January 25, @06:41PM (#5159025)I don't like that one of the linked articles suggests an end of IRC. Any server can be DDoS'd and there's nothing that makes IRC more vulnerable than any other service being provided. In general, the IP addresses of hubs are hidden from ordinary users, the the worst damage that can be done is taking some client servers offline. Yes, the kiddies get large botnets, but that doesn't mean they win. There were times a few years ago that most EFnet servers were offline for days, and that EFnet logs many servers during that time. But the kiddies were never able to destroy the network, and it's come back stronger than ever. If anything, the kiddies didn't hurt the network, they made it better. There's a chanfix, inspired by the attacks, to restore opless and some taken-over channels. This goes a long way to preventing attacks. Most of the EFnet attacks were motivated by channel disputes.
Undernet has hid which server a user is connected to and has disabled commends such as
/links. There's now a +x mode which if a user is logged into X/W, hides the user's host. Where I'm going with this is the best IRC networks generally survive the attacks and are stronger in the end. I don't think an attack on Dalnet is the end of IRC.
While I'm no expert on this, as a longtime user of IRC, in the past couple years I've seen a huge rise in the number of users who send you a website to visit upon joining a channel. Some networks take the steps of helping these users remove the trojan, or removing them from the network. On the other hand, some networks do nothing to solve these problems. If these are the same trojans that provide DDoS bots, opers could be doing a lot more to track down and solve the problems. I, for one, often report these to EFnet opers, and the opers are almost always quick to remove the user from the network.
What's my point in all of this? With some common sense, some coding skills, and opers who are willing to help, a network can solve a lot of its problems. If EFnet and Undernet managed to overcome DDoS attacks many times in the past, one wonders why Dalnet wasn't able to.
And the end of Dalnet doesn't mean the end of IRC. Other networks are better prepared to deal with this sort of thing, and can survive much more than Dalnet has. While the article raises valid concerns, it's written from the standpoint of someone who doesn't seem to know much about other networks.
Anyway, I hope Dalnet doesn't just cease to exist. Somehow I doubt it will, though.
DALnet (Score:5, Informative)
by lvdrproject (626577) on Saturday January 25, @07:05PM (#5159144)
(http://www.skylagoon.com/private/lav/)This is the first i've heard about the other two stories-within-the-story here, but DALnet has been the constant bane of people wanting to get things done (and/or chat) for quite some time now. The DDoS attacks have been going on for a long time, but they really came to a peak a few months ago, where it became extremely difficult to stay connected to DALnet for more than a few hours at a time (at which point you would have to reconnect, usually to a different server, since the servers seemed to just take turns dying). There have been at least two, possibly three or four, occasions where DALnet just shut down completely for a period of at least a few days (this latest one being in the range of like a week). After the first "big" DALnet shut-down, it seems a lot of channels moved to other networks; most of these channels have even gained numbers. Seems even if DALnet does return, a lot of the channels that left it will stay on their new-found networks. The few anime channels that came back to DALnet are very slowly gaining back their numbers, but they're nowhere near the levels they used to be. As of right now, the highest count is 51 users, which is really low for a DALnet anime channel. Highest warez channel count is 68, which is also really low for a DALnet warez channel. And even the MP3 channels, which probably were some of the biggest channels on DALnet, have lost major numbers. I seem to remember them being in the area of like 600+; current count is 166. So yeah, DALnet has really been taking it in the ass.
General consensus around the parts i hang out seems to be that losing DALnet wouldn't be such a bad thing. We'd all move our channels to other networks, and be done with it. Chat channels would really love EsperNet or IRCnet, and warez/MP3/ISO/PlayStation/etc. channels have a half-dozen networks to choose from, most notably EFnet (though i despise it). Anime channels would thrive on Aniverse. DALnet was great, but, unless things see a really dramatic improvement, i think there are many that would agree that it needs to be put out of its misery as soon as possible.
What has made this all really lame has been the fact that DALnet hasn't really said anything about this. Their eZine (the DALnetizen) has truly been the opposite of helpful throughout this whole ordeal. It seemed as though DAL was almost oblivious to what was happening. There would be a paragraph about Christmas, a paragraph about the benefits of PHP, a paragraph about poems, a paragraph about some new op or something, and then tucked away in a little corner would be a little sentence or two along the lines of "ps dalnet si getitng ddosed pls bare w/ us thx". After this most recent attack, however, they've started to get their act together a bit, and have posted a lot more information regarding the situation. Information can really be helpful to their users, if they want to keep them.
Also not helping the situation are rumours(?) to the effect that the DALnet administration has resorted to childish finger-pointing, and have pretty much detached themselves from each other. DALnet isn't really doing a very good job of assuring its user base that it'll be alright.
:/ Hopefully, if DALnet is to survive, this will be remedied. And, finally, the biggest blow to DALnet has been the de-linking of several of its (best) servers. Almost all of the "good" servers, the ones that everyone had as their first picks, have disappeared. Even the "fall-back" servers seem to be gone. Evidently DALnet is picking up a few new (or renamed, maybe, i can't be sure myself) servers, even in light of the attacks, however.
So DALnet's fate is really unknown. No one can be sure, but for now it's functioning, at least in the sense that it has the ability to carry users. Who knows, though, it could be down again tomorrow.
SecurityFocus/Developing Open Source AntiVirus Engines
According to its Web site, the OpenAntivirus Project is "a platform for people seriously interested in antivirus research, network security and computer security to communicate with each other, to develop solutions for various security problems, and to develop new security technologies." Among these technologies are ScannerDaemon, VirusHammer and PatternFinder, which are "a first implementation of a GPLed virus scanner written in Java."
This article will take a look at the OpenAntivirus AV engine, assess its progress so far, and offer some suggestions of how the developers can continue to develop it. While some of the commentary in the following sections may be fairly critical, the purpose of this paper is not to flame the OpenAV project or its developers but, on the contrary, to salute their efforts. Hopefully, this article and the comments herein will make a significant contribution to the development of a viable, working open source antivirus product.
Google matched content |
...
Society
Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers : Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism : The Iron Law of Oligarchy : Libertarian Philosophy
Quotes
War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda : SE quotes : Language Design and Programming Quotes : Random IT-related quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard Shaw : Mark Twain Quotes
Bulletin:
Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 : Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law
History:
Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds : Larry Wall : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting Languages : Perl history : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history
Classic books:
The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month : How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite
Most popular humor pages:
Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor
The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D
Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...
|
|
You can use PayPal to to buy a cup of coffee for authors of this site |
Disclaimer:
The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.
Last modified: March, 12, 2019
