ClamAV vulnerability; Con-fu

ClamAV vulnerability; Con-fu
Clam AntiVirus vulnerability A vulnerability was discovered in the popular open-source anti-virus scanner Clam AntiVirus. Many people are running this on their mail servers, so make sure that your e-mail administrators update to the latest version. Vulnerability details here: http://www.osvdb.org/displayvuln.php?osvdb_id=18259 Con-fu Many of you might be attending the security conference Black Hat and/or Defcon this week. I decided that it might be good to put up some tips for computer security when attaching to the wireless networks there. Of course, you can use these tips for any other untrusted network. Feel free to send us your tips also. I have a couple of Linux machines running at my house. So I have found that the safest way to hit the Internet is to tunnel everything through SSHD at my home network. My first suggestion: if you absolutely don't need to connect, then don't take the risk. Just keep your laptop in your hotel room for emergencies and you won't have to deal with the inevitable frustration of the wireless network going down. Yes, you may have some envy as you see everyone else geeking out in the hallways. But you will have the added advantage of being unencumbered as you head to the bar/pool/casino tables later. Second major point: if you have a Windows laptop that is work-related, you may want to seriously consider not attaching it to the networks there. Consider all of the different software on your machine that will be trying to connect to IP addresses inside your organization: anti-virus updates, NetBIOS shares, etc. You would be surprised how persistent the software loaded on your Windows laptop is nowadays and all of this traffic is information leakage over a hostile network. At the office or at home, this information leakage probably isn't a big concern, but when you are attaching to a very well monitored network you should think twice about it. THINGS TO EXPECT: ) The wireless network will go down... often. Despite the best efforts of the organizers, it is very difficult to keep the wireless network up and working. ) There is all sorts of games that are played upon the wireless network. Fake access points go up and down. Rogue DHCP servers answer to requests. The routers get hammered with DoS attacks. ) Expect weird DHCP and DNS stuff to happen. ) Finally, try to recall all of the attacks you have seen in the last year and dismissed because the attacker needed to be local to your network. Then realize that you are about to connect to that network. BEFORE YOU LEAVE: ) Regardless of OS, make sure your laptop is patched. If running Linux, make sure your kernel is current/patched. ) Double check your firewall settings from another machine. ) Setup SSHD on the proxy machine that is running on a port different than 22. I would keep it below 1024 to ensure that a root-owned process is running the daemon. ) Hard-code your proxy box IP address into your hosts file on your laptop. This prevents DNS hijacking at the conference. ) Verify that your SSHD allows public key authentication only. If you didn't already have it setup, generate a public/private keypair on your laptop. Also, make a note of your server's public key on your laptop to reduce any question of man-in-the-middle attacks later. ) Verify that your SSHD only allows SSH protocol version 2. ) Setup a Squid proxy server on that box. This will allow you to proxy HTTP and FTP traffic. ) Configure another machine to log all attempted connections to the destination box running your SSHD. This is just for you to review later when you get home and see if anybody was watching you connect to your daemon. AT THE CONFERENCE: ) When you get to the conference, try to hard-code the MAC address of the default router. Use the arp command to do this. The MAC addresses of the routers are usually published at Black Hat. ) After booting your laptop, SSH to your proxy box and setup port forwarding. ssh -L3128:localhost:3128 <username>@<proxy_ip>. ) After the SSH tunnel is up, make sure that your web browser is using the proxy address of 127.0.0.1:3128. This will force all of the web browser traffic to transcend the SSH tunnel and get handled by the Squid proxy server. For command-line applications on UNIX, you can sometimes set the http_proxy and ftp_proxy environment variables to the proxy IP address. ) With all of this in place, I would still be very hesitant about connecting to corporate e-mail systems (especially Outlook Web Access). Do you really want to put your organization at risk by connecting to these systems and having someone shoulder-surf your email? ) Do you believe strongly in your VPN client? That's great. But why put your organization at risk by showing everyone else the IP address of your VPN gateway? ) If you are running Windows, consider the following additional measures to prevent information leakage from NetBIOS broadcast traffic... ) Turn off Client for Microsoft Networks. ) Turn off File and Printer Sharing. ) Turn off NetBIOS over TCP/IP. ) Consider changing the domain name and machine name of your computer. [end]	Kyle 112 Posts
Subscribe	Jul 26th 2005 1 decade ago

Clam AntiVirus vulnerability

Con-fu