I want to TOTALLY BLOCK some sites by DNS name

Which version of the Astaro Firewall are you using?

Cheers
Andi

all http proxies have blacklists where u can block a site by name
permanently. forever.
:-)
rgds, andre

Is the use of wildcards supported whitelists/blacklists?
Example:
http://*.avast.com

in V6 u have to use regular expressions
in V7 u can type in domains

generally u can use wildcards, but careful: Astaro stops after wildcard, so your example means "Any" - avast.* might be o.k. for avast.com, avast.de etc...

rgds, andre

just type avast.com for blocking avast.com domain or use avast. to block all avast domains.

Greets
andi

just type avast.com for blocking avast.com domain or use avast. to block all avast domains.

Greets
andi

So in the "Always allow" section, I would type "avast.com". Not "http://*.avast.com"

That is correct, JimmyM, and that also covers all subdomains like 'mail.avast.com'.

Cheers - Bob

Sorry, I'm running the latest and greatest, v7.

Where is this blacklist stuff? I was digging through http proxy. Apparently this is the wrong spot?

I ran through the menu again and don't see "blacklist" anywhere except smtp...

It's in the HTTP Proxy under the register "Content Filter". On the right hand side you have two boxes, one for the whitelist the other for the blacklist.

Cheers
Andi

'Web Security >> HTTP'
'Content Filter' tab
'Additional URLs/sites to block'

Cheers - Bob
PS If Trojans and other malwares are getting past the Astaro, I wonder if you haven't added a packet filter rule that's letting things bypass the HTTP Proxy.  What are your Packet Filter rules?

Sweet! Thanks guys!

Of course when I show my packet filter settings everyone is going to smack their heads and say "you idiot!" but here goes...

 1 Any  ->  FTPWebServer_External
      FTP 
    
 2 Any ->   FTPWebServer_External 
     HTTPS 
 
 3 Any ->   FTPWebServer_External 
     HTTP 
    
 4 Any ->    ServerExch2 
     HTTP 
 
 5 Any ->    ServerExch  
     POP3 
 
 6 DMZ (Network)  ->  Any 
     Any 
 
 7 Internal (Network) ->  Any 
    Any 
 
 8 VPN Pool (L2TP) ->  Any 
    Any

With these settings I've been stopped when going to known malware sites, so I *thought* they were OK?

Predatorsw, I like your attitude - you've got good mental health!

Rule 6 allowing 'Any' traffic from the DMZ seems overly-broad to me; it effectively negates the concept of the DMZ.  Anyone in the outside world who succeeds in infecting the FTPWebserver via one of the first three rules has free access to your network.

Also, are you sure that accesses from your internal network to the FTPWebserver are going through the FTP and HTTP proxies?  From looking at the Packet Filter rules, I think not.

Rule 4 indicates that you are not using HTTPS for OWA, so you could make that a little more secure by requiring HTTPS.  I assume that you are DNATing external traffic to OWA from an additional IP on the External interface.

Rule 5: Do you have external users accessing Exchange with POP3?

Rules 7&8: Less danger here, but you can tighten that down little by little.  Our corresponding rules look like:
 1 Internal (Network) --> DNS --> Any : Allow
 2 Internal (Network) --> Web Surfing --> Any : Allow
 3 Internal (Network) --> Windows Networking (NETBIOS) --> Server : Allow
 4 Internal (Network) --> 'Server Other Services' --> Server : Allow  
 8 Internal (Network) --> 'Internal other Services' --> Any : Allow 
 
With the following definitions created for the above:

'Server Other Services' (group): CIFS, KERBEROS, LDAP, LDAP_UDP

'Internal other services' (group): FTP, Microsoft Terminal Services (RDP), NETBIOS NS, NTP, POP3, POP3 SSL, SMTP, SMTP SSL, SSH, Telnet, VNC, WHOIS

I made those changes after Jack Daniel remonstrated me for having the rule you're using.  If you add the first three rules (certain to catch the highest-volume traffic) in front of your current Rules 7&8, you can then turn on logging for those two rules and see in the live log what other traffic you want to allow.

Cheers - Bob

Thanks for the vote of confidence! I'm no network guru and I'll be the first to admit it. I was able to setup our network, dhcp, dns, wins, active directory, and firewalls with no real IT experience other than being a computer programmer. I have no irons in the fire about how big my IT weenie is.

Rule 6 allowing 'Any' traffic from the DMZ seems overly-broad to me; it effectively negates the concept of the DMZ.  Anyone in the outside world who succeeds in infecting the FTPWebserver via one of the first three rules has free access to your network.

Agreed, but as a blazing overview whenever setting up internal->internet packet rules I could never get things to behave reasonably. I simply punted on any quasi-internal network to the real world so I could get things working.

Also, are you sure that accesses from your internal network to the FTPWebserver are going through the FTP and HTTP proxies?  From looking at the Packet Filter rules, I think not.

Internal access to the ftpwebserver has always been odd, and never really worked correctly. I just gave everyone internal addy's to our servers to bypass the rules. We could never access the ftpwebserver using the same url's we give out externally. I've been playing with DNS and other nonsense to get this to work better, but I finally just used a double NIC to have one address internally and one external. This is skating on the edge of my competence so I try not to prod it too hard.

Rule 4 indicates that you are not using HTTPS for OWA, so you could make that a little more secure by requiring HTTPS.  I assume that you are DNATing external traffic to OWA from an additional IP on the External interface.

Yes. I still haven't mastered ssl certs so we kind of have to do a little tap dancing regarding https access in general.

Rule 5: Do you have external users accessing Exchange with POP3?

We did at one time, I think I can prolly yank this without any problems. Everyone that needs to already has forwarding rules to blackberry servers.

I'll have to mess about with your suggestions, coming from someone that obviously has more experience than I do on these things. I'm usually pretty hesitant about messing with packet rules as it really, really, affects our internal network. Then you toss VPN into the mix and boy howdy.

I was pretty happy they finally fixed the one hour timeout thing using ipsec. Everyone that I complained to about that problem that showed up on V7 thought I was smoking crack. Apparently someone that could speak "firewall" finally convinced them the vpn one hour thing was a real problem and it got fixed a couple revs back. I just felt kind of stupid I wasn't able to supply enough information to get that problem fixed earlier.

Anyhoo, I'm on stoli tonic #5 so I best stop typing. Please pm or email me your meatspace identity because I really hate our local astaro rep. Since they are forcing me to renew through reps I'd rather my dollars go to someone that has a clue.

Thanks for the positive feedback.

The first thing I'd do would be to turn on logging of Rule 6 and watch the live log to see what traffic you need to allow.  Then, create a services group containing those services.  Finally, replace 'Any' in Rule 6 with the services group you created.  If you have the HTTP Proxy in 'Transparent' mode, then that traffic should be going through it already.  The FTP Proxy always functions in transparent mode.

I suspect that the baddies got in around the Astaro instead of through it.  Just for fun, you might grab a laptop and walk around the building to see if anyone has opened your network up to the world.  The last time we had a problem, it was because the 13-year-old son of our top rep had turned off the anti-virus on her laptop; you might verify that all laptops have your current AV installed and active.

One question.  If your ftpwebserver has a separate Ethernet adapter with an internal address, why do you need Rule 6 at all? 

Cheers - Bob

One question.  If your ftpwebserver has a separate Ethernet adapter with an internal address, why do you need Rule 6 at all?

Good point, we don't. Like I mentioned before our network topology has changed quite a bit from my initial setup and we obviously have some old artifacts lieing around.