Put some blocking rules on the shaper for SSH scan attempts this morning. Mainly tightening up access to the server net.
I allow access to a few hosts on the server net from anywhere, access to any host from the server net from a few nets, and any access to anything off the server net. The last is done with a range keyword in the rule, and the others are done with host lists.
I redesigned the way we break down traffic in the shaper today. The short version is that we’re now splitting the traffic tree first by IP address (or host list) to get to student network, blocked hosts, and college owned network. Then within those (if needed) we differentiate by application service.
The college owned network is the only base class that is not set as an exception class. Others are exception so that they will sort higher than the college network, which is simply set to include our entire class B space.
Within the student and college networks, I then create several folder classes for basic services (web browsing, FTP, DNS, etc.), chat programs, streaming media, P2P, games, etc. Each folder class has a partition assigned to it, and each application class has a priority policy assigned to it (except in the basic services, where I have more complicated policies). There’s also a “blocked” folder, which has a number of classes that are blocked with never-admit policies.
Things seem to be working at the moment, and the layout is extensible. We can partition the student net or the college net to a certain bandwidth (possibly useful in the future if we go to heftier pipes), and we can make different policy settings for the same application at different points in the network.
All the setup is done with a command file that is generated by a set of unix shell scripts. I have these on my laptop.
Grabbed updated files from the Moodle distro site for an RSS block bug that had been reported.
Mark pointed me here and I found the three files involved in the fix. I got them off of the CVS web and put them into place on HEDD. Mark should be testing them shortly.
After a week of fiddling, I think the PacketShaper is under control again. I’ve been living on the student net and making things reasonably responsive over here, and I believe not to the detriment of the college-owned net.
First, I believe that every fall we should run the shaper in discovery mode to pick up the new applications people are running. This should be done with the latest PacketWise release and classification plugins. That seemed to help a lot last week, picking up a number of new games and P2P apps.
Second, understand how to effectively put policies on different traffic patterns, recognizing the difference between requests and responses. It is better to put a middle to high priority policy on HTTP request traffic and then put a sliding rate policy of middle to high priority on the HTTP response. THe request is small and doesn’t care about per-flow bandwidth limits while the response can be much larger and can effectively be shaped on a per-flow basis. Interactive stuff, including POP3 and IMAP need to have pretty high priority, but again we can differentiate between those services hosted here and used from off campus versus those hosted elsewhere and used from on campus (the latter not getting as high priority). Background stuff, like SMTP, can be given a fairly low priority policy, but shouldn’t be shaped any other way.
Today I also set up some scheduled jobs to run on the shaper. Weekday evenings I increase web browsing and gaming bandwidth a bit, and then decrease them again weekday mornings. This means that at night and over the weekends some of the student-initiated traffic ought to see a better response than with static rules.
I think I’ll continue hanging out here on the student net for a little while, but at this point things seem to be working fairly well.
Never a dull. I was wrangling with the PacketShaper all day, trying to get the student network to behave in any kind of reasonable fashion, and now I find that part of my Internet bandwidth problems were due to a veritable flood of spam that managed to be sent from a library computer through our e-mail gateway.
A few tens of thousands of spam messages were sent from LLYA019 through TAIKA, starting around 3:00 this afternoon. I don’t know how the spam malware gets the IP address of a good gateway to send its wares through, but I have two good guesses (and in case any nasties are reading this, I’m not going to elaborate — full disclosure of my thoughts, this ain’t). I didn’t discover this until just recently. I managed to clean up all the messages from the box still queued up on TAIKA (plenty, since I’d throttled outgoing SMTP from campus), and now the shaper reports a reasonable bandwidth utilization for that traffic class. I also blocked the infected box at both the shaper and the firewall, and I’ve seen no further mal-traffic from it (I also gave it a bogus IP in NetReg, with the hopes of kicking it off the net the next time it tries to renew its lease).
Tomorrow I need to stop mucking with the shaper and the firewall and get a handle on some other tasks in desperate need of my attention; perhaps Friday or next week I can get back to this and see if my tunings are having any kind of positive effect (without killing the rest of campus in their wake…). I can’t say I enjoy being on the student network, but it is instructive to feel their pain.
After a number of complaints of slowness on the student network, I’ve set up my laptop on the student switch for the week. I’ve made some PacketShaper adjustments, and I’ll continue to make adjustments until it seems like we’ve got a usable pipe. I won’t be able to pick up on after hours slowness or problems confined to a single building, but I can at least work on Internet usability.
Got the OpenBSD bridge online today, passing (and blocking, as appropriate) traffic on the main pipe. Tuning Argus turned out to be slightly tricky, but it’s going well now.
Argus post processing takes a lot of memory, and it doesn’t do anything useful when it fails — just dumps core (it’d be nice if it checked the return code from malloc and failed gracefully with an error, but no…).
Found a couple of IP addresses still spewing worm traffic and alerted the right people.
Finally got around to putting OpenBSD on the firewall box that we got a while back. As I remembered, setting up bridging is pretty simple, assuming you can figure out which of the 6 interfaces on the box you’re using. Argus is installed and running, but I haven’t had much chance to play with it yet. Next week I’ll be looking into that more and then connecting it to the main pipe.
I put a new look on these pages. I stole the style sheet from WebDB, with numerous hacks to make it MT-happy, and then hacked up the templates to make them style sheet-happy.