Heya.. Yesterday someone "attacked" by box by connection to several ports.. In other words, a simple portscan.. yet, since my box has "log_in_vain" enabled, so it tries to log everything to /var/log/messages, since the logfile got full and the size went over 100K, it tried to rotate the log to save diskspace. (Apr 16 21:00:00 omikron newsyslog[32137]: logfile turned over due to size>100K) My server box is a Intel Celeron 733Mhz, 384Mb of RAM.. yet it's slow from time to time since I only run ATA66 due to the old motherboard. When this "attack" occured yesterday, the box almost died and the box were working 100%.. all users who were logged in got "spammed" since the default *.emerg in /etc/syslog.conf is set to "*" .. Isn't this a quite simple way of making a DoS attack against a system? My box is running on 10mbit and the person who scanned my server were connecting from a cable connection.. Someone (even with lower bandwidth) can simply portscan a box with "log_in_vain" enabled and the box will go crazy trying to log/store it? Also, I'm not sure if it was a "general" portscan since the "blackhole" mostly slow down those quite much.. but since this had about 30-40 connections per second, it was a quite aggressive scan. I would be glad if anyone could tell me how to solve this and/or how to make sure it doesn't happen again. Regards, Jesper 'Z3l3zT' Wallin
On Apr 17, at 04:28 PM, z3l3zt@hackunite.net wrote:> > Heya.. > > Yesterday someone "attacked" by box by connection to several ports.. In > other words, a simple portscan.. yet, since my box has "log_in_vain" > enabled, so it tries to log everything to /var/log/messages, since the > logfile got full and the size went over 100K, it tried to rotate the log > to save diskspace. > > (Apr 16 21:00:00 omikron newsyslog[32137]: logfile turned over due to > size>100K) > > My server box is a Intel Celeron 733Mhz, 384Mb of RAM.. yet it's slow from > time to time since I only run ATA66 due to the old motherboard. When this > "attack" occured yesterday, the box almost died and the box were working > 100%.. all users who were logged in got "spammed" since the default > *.emerg in /etc/syslog.conf is set to "*" ..If you're running a relatively slow bus, chances are you could (maybe even "have"?) experienced this already by a completely different set of circumstances, but didn't put it together?> Isn't this a quite simple way of making a DoS attack against a system? My > box is running on 10mbit and the person who scanned my server were > connecting from a cable connection... > [SNIP]Assuming the attacker knew you had a slower bus, were running FreeBSD, had log_in_vain turned on, and ... ?> I would be glad if anyone could tell me how to solve this and/or how to > make sure it doesn't happen again.Seems to me you're hampered by your hardware, and this episode is/was just the latest symptom. Moving /var to another physical drive on a different channel will help. So would tuning /etc/syslog.conf. Of course, so would turning off the log_in_vain knob (though I like it on, too). A new ATA adapter isn't all that expensive anymore, and would boost performance overall. HTH, Dave -- ______________________ ______________________ \__________________ \ D. J. HAWKEY JR. / __________________/ \________________/\ hawkeyd@visi.com /\________________/ http://www.visi.com/~hawkeyd/
z3l3zt@hackunite.net wrote:> Yesterday someone "attacked" by box by connection to several ports.. In > other words, a simple portscan.. yet, since my box has "log_in_vain" > enabled, so it tries to log everything to /var/log/messages, [ ... ] > Isn't this a quite simple way of making a DoS attack against a system?Certainly turning on log_in_vain makes it easier to DoS a system, but it's possible to perform a DoS against anything if someone tries hard enough. Basicly, log_in_vain can be used to turn a system into a network sensor which tracks incoming connection requests. Normally, one has a firewall in place which blocks the majority of ports used by a port scan, and your sensor only detects the remainder-- ie, what you let through, in addition to any local traffic. Seeing your sensor get horribly busy like you did tends to indicate you're monitoring unfiltered Internet traffic (or your firewall is busted), in which case be prepared to possibly deal with hundreds of thousands of lines of logging per day. Or it indicates an internal machine has been virusized and is scanning the local subnet for other hosts to infect (or someone connecting a laptop to your network, etc). I've been seeing about 500 connection attempts per day per monitored IP address. For what it's worth, you provoked my curiousity enough to see what the last week looks like in terms of a histogram by port #: % zcat /var/log/system.log.*.gz | grep 'TCP.* S' | awk -F: '{print $7}' \ | awk '{print $1}' | sort -n | uniq -c | sort -nr | head -30 20654 1433 4622 4444 4458 445 3451 135 3189 139 2455 80 448 6129 270 3127 140 2745 124 4000 96 21 87 4899 80 1025 79 1080 65 5000 58 3128 41 20168 41 1981 34 25 28 3410 26 36442 23 23 17 22 15 443 13 32772 13 113 7 81 7 8000 6 8080 5 901 -- -Chuck
z3l3zt@hackunite.net wrote:> Yesterday someone "attacked" by box by connection to several ports.. In > other words, a simple portscan.. yet, since my box has "log_in_vain" > enabled, so it tries to log everything to /var/log/messages, since the > logfile got full and the size went over 100K, it tried to rotate the log > to save diskspace.This is hardware problem. Any ATA/SATA disk will suck up CPU with every disk access. The solution is to switch to SCSI. Proper partitioning would also allow you to rotate log files every 10 or 20MB instead of at 100K. For reasons exactly like this I never partition a disk for anything other than swap. If filesystems need to be separated they're put on separate (SCSI) disks. Whether you need log_in_vain or not depend on what you do with the logs. Are you compiling statistics? Running Snort or another IDE? Separating facilities into different files (other than /var/log/messages)? Reading them regularly and often? If you answered no to two or more of these questions then there's probably little to lose by disabling log_in_vain. -- Roger Marquis Roble Systems Consulting http://www.roble.com/
On Sat, Apr 17, 2004 at 04:28:35PM +0200, z3l3zt@hackunite.net wrote: [snip]> My server box is a Intel Celeron 733Mhz, 384Mb of RAM.. yet it's slow from > time to time since I only run ATA66 due to the old motherboard. When this > "attack" occured yesterday, the box almost died and the box were working > 100%.. all users who were logged in got "spammed" since the default > *.emerg in /etc/syslog.conf is set to "*" ..Not sure what that has to do with anything. The log_in_vain messages get logged at "info" level. What messages were your users seeing? -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org
Heya.. Yesterday someone "attacked" by box by connection to several ports.. In other words, a simple portscan.. yet, since my box has "log_in_vain" enabled, so it tries to log everything to /var/log/messages, since the logfile got full and the size went over 100K, it tried to rotate the log to save diskspace. (Apr 16 21:00:00 omikron newsyslog[32137]: logfile turned over due to size>100K) My server box is a Intel Celeron 733Mhz, 384Mb of RAM.. yet it's slow from time to time since I only run ATA66 due to the old motherboard. When this "attack" occured yesterday, the box almost died and the box were working 100%.. all users who were logged in got "spammed" since the default *.emerg in /etc/syslog.conf is set to "*" .. Isn't this a quite simple way of making a DoS attack against a system? My box is running on 10mbit and the person who scanned my server were connecting from a cable connection.. Someone (even with lower bandwidth) can simply portscan a box with "log_in_vain" enabled and the box will go crazy trying to log/store it? Also, I'm not sure if it was a "general" portscan since the "blackhole" mostly slow down those quite much.. but since this had about 30-40 connections per second, it was a quite aggressive scan. I would be glad if anyone could tell me how to solve this and/or how to make sure it doesn't happen again. Regards, Jesper 'Z3l3zT' Wallin
> >>>I believe that was a bug in syslogd and this bug is already fixed in both of CURRENTand STABLE for not so long.>>> >>>Eugene >>> >> >> >> Fixed you say.. I run FreeBSD 5.2.1-RELEASE-p5, yet it's there.. >> >> >> Regards, >> Jesper Wallin > > if (strncmp("RELEASE", "CURRENT", 6) != 0) > fprintf(jesper, "``in both of CURRENT and STABLE for not so long.''); > > Please, before you give sarcastic remarks back to others who are trying to help, do alittle logical thinking for yourself.> > Devon >Hello again.. Heh, it wasn't ment to be sarcastic, mean or anything else like that.. I just pointed out it's still in FreeBSD 5.2.1 RELEASE-p5.. if someone feels bad for this, sorry. Regards, Jesper Wallin
Peter C. Lai wrote:> > This is hardware problem. Any ATA/SATA disk will suck up CPU with > > every disk access. > > Only if you are running your drive in PIO mode. The system starts up using the > highest UDMA level possible and I bet (hope) he checked the sysctl to make sure > it was at UDMA66.PIO mode, UDMA, 66/100, serial, all are factors but none compensate for the differences beteween SCSI and ATA in real world conditions. By real world I mean where there are multiple, simultaneous disks reads and writes. Too many "benchmarks" only test serial, non-multitasking disk access. In this mode ATA can be just as fast as SCSI and use nearly as little CPU. As soon as you factor in multitasking, however, it's a whole 'nother ballgame. I've seen 10K 160M SCSI drives handle 10x more data than the fastest UDMA100. With 15K drives and 320M becoming generally available SATA isn't even rated for 50% of SCSI's maximum throughput and that's before factoring in multitasking. In every test I've done with various disks and controllers SCSI has out-performed ATA by a wide margin in server performance. -- Roger Marquis Roble Systems Consulting http://www.roble.com/