Hello all need some advice, one of our networks was infected by a nasty windows based worm tonight, this then manifested itself and attacked our primary gateway and proxy connections.

As you can imagine some people were not too happy.

The machines infected were isolated and dealt with, but now this has got me thinking about the best way to deal with any large packet attack that could originate from within a LAN environment.

The current LAN on this network is setup as follows:

LAN 193.xxx.xxx.10 + >
Gateway 193.xxx.xxx.01 >
Proxy Server 172.xxx.xxx.xxx:8080 >

Would something like Astaro Linux or Smoothwall with some other goodies like ADF/F-Prot help me stop anything like this happening again.

What I am really asking is, if I added a linux box come router/firewall/anti virus agent as a replacement gateway using something like 193.xxx.xxx.02 and then forward the traffic on to the main gateway, could I isolate any potential nastys leaving the LAN environment.

Any ideas anyone.

Many Thanks

Chris

You could most certainly do just that. Setting up a packet filter firewall on the linux box is not "too" difficult and it would stop a flood originating from the LAN if set up correctly. We had a similar problem that was found to be an infected laptop brought in by Sales staff that flooded our switches and a similar setup was used to prevent future outbreaks. It can't stop client-to-client infections per se but does work to protect the servers.

Many thanks, fortunately the LAN's servers were not affected on this occasion. I must admit I have never used Smoothwall does anyone now if it has this level of capability or would a main distro be my best bet.

I am basically going to try and build something tonight to test out across the LAN tomorrow!!!!!!!!

Chris

I suppose you could screen all traffic to the servers with a smoothwall box inside your net. ie: have clients run on 10.101.xxx.xxx and servers on 10.202.xxx.xxx, and having a smoothie (that's what they like to call it) with the external (or 'red') address on the 10.101.xxx.xxx net, forwarding server requests to your farm. You can also run a pretty decent snort IDS and since smoothwall lives on a plain old hard drive (it uses the whole platter) you've got loads of room for logging. The freeware version is somewhat limited for a complex networking setup, but corporate versions are available for what appears to be a reasonable price (although I've never used the $$ version myself).

Of course as others have already pointed out you can setup iptables rulesets on your Linux servers as well, but then you'll have more nodes to manage.

it looks like this problem has been solved but here's a quick and easy solution..
im assuming this worm is one of the 2 HUGE ones lovesan/msBlast and that newer one (canr remember name)

if you firewall off all incoming connections addresssed to ports 135, and 80 yuo will protect from the MS security holes that these virii exploit.

Many thanks, I have added smoothwall on to the lan using the following config:

ETH0 193.xxx.xxx.11
ETH1 193.xxx.xxx.12

I have changed the dhcp entry for the router and have set it to look at ETH1 for connection.

This works great after using the following command:

echo "1" > /proc/sys/net/ipv4/ip_forward

Well did work great, I tested it on 4 workstations and they all worked like nothing had changed, except for when I tried to access the Internet!!

All connections are required to authenticate via Novell Boarder Manager on the proxy 172.xxx.xxx.xxx:8080, this was not the case with the 4 demo workstations. Even though the proxy requirements were listed in the Internet config section of IE all communications went through to the net without any requirement to logon.

So back to drawing board me thinks

Many thanks

Chris

I don't think you should be using the Smoothwall DHCP server if you already have one in place. Either that or you'll need to make sure that the Smoothwall server can pass the same options to the clients that your current setup does.

Sorry I am not using the dhcp profile in smoothwall, all dhcp requests are still handled by the main network servers.

See what mean:

"I have changed the dhcp entry for the router and have set it to look at ETH1 for connection."

This should have been, I have changed the router entry within win2k3's dhcp path sp now all workstations look at ETH1 as opposed to the main gateway IP 193.xxx.xxx.1

Many Thanks

Chris

why have you not 2.4.20-lq1 Kernel updated to 2.6 yet?

On which machine?

Well I suppose the specific machine isn't too important. What I'm looking to find out (getting to the point) is how does the latest kernel improve upper level security efficiency?

How are you planning to route traffic if both interfaces are using IPs from the same subnet, but plugged into different switches???

Let's be clear about what we're talking about here, what you really want is a rate limit on your outbound connections. I'm not sure how Linux handles traffic queueing and bandwidth limiting, but that is what you need to throttle massive traffic surges generated by worms. Everything else discussed is going to be useful against MyDoom and DDoS'ing worms like it (the worm is litterally trying to DDoS SCO off the face of the Internet).

PS It seems like you also need to install a Network IDS, or at least have it update definitions more frequently. This sort of traffic should be noticed and isolated quickly before it takes your network down (when you have to investigate the source of everyone's workstation being knocked off-line, it's too late).

This is exactly what I was thinking as I read the details on CNN.com. I mean retro fitting a problem of this magnitude after the fact is a tad less then ideal.

And one last point, this is another great reason to segment your internal networks from each other. Depending on your budget, Cisco have firewalls modules for their mid-high end switches, or you could simply place cheap x86 boxes with BSD or Linux in between LAN segments to do minimal filtering and traffic shaping, along with NIDS. It should go without saying that the more segmented your network is, the easier to contain an outbreak of some sort (similar to air-tight hatches in a ship or submarine).

Of course, it's more administrative overhead and it complicates the network... When segmenting a network you would certainly want some kind of central management software. Along with that should be centralized logging and reporting, so instead of checking the logs individually on each firewall (and requiring lots of disk access, thus increasing the chance of failure) a lot of admins recommend sending all logs to a remote syslog, possibly over an IPSec encrypted tunnel.

The above is a "dream world" setup, but hopefully it gets people thinking about ways they can improve their network infrastructure.

Last point, remember that most studies show over 80% of network security incidents are caused by "insiders". Firewalls aren't only to keep outsiders out, any more.