I ran into the same requirement in a recent project, basically preventing access to any list view or form of a particular (hidden) list via the Web browser.
SharePoint designer isn't allowed on Web Application level and Web services (including client object model) is blocked by a custom HTTP handler, so the concerns mentioned in other answers didn't apply to this project.
Removing permissions was not an option because lookup fields of the list are used on other lists and should work for anybody, but accessing the list itself shouldn't be possible.
Instead of the tedious task of messing with URL-rewriter rules on the IIS server or a custom HTTP handler, which has several disadvantages as described later, the solution was to develop a custom SharePoint DelegateControl as described here
The DelegateControl contains code to check for a particular SharePoint group membership. If the current user isn't a member the following code blocks access to the list view & forms ASPX pages (note that the code has been simplified and might need more polishing):
string currentUrl = Request.Url.ToString().ToLower();
SPWeb currentWeb = SPControl.GetContextWeb(Context);
SPList currentList = SPContext.Current.List;
if (!currentUrl.Contains("/_layouts/") && (currentList != null && currentList.Title == "Your List Name"))
Response.StatusCode = 403;
Response.Status = "403 - Forbidden";
Response.StatusDescription = "Access is denied";
string accessDeniedPage = SPUtility.AccessDeniedPage;
string redirectUrl = "/_layouts/" + accessDeniedPage + "?Source=" + currentUrl;
Response.Redirect(SPUrlUtility.CombineUrl(currentWeb.Url, redirectUrl), true);
Unlike a custom HTTP handler the custom SharePoint DelegateControl will only fire its code when an ASPX page is hit which IMHO is a big advantage because the HTTP handler fires on every single request (even a JS/CSS/GIF etc. file) which puts additional load on the SharePoint Web frontend, plus the deployment of a HTTP handler is cumbersome because it has to be added to each web.config (including each extended Web Application) either manually or by writing a proper custom feature event receiver handling all the web.config modification heavy lifting. Because of those reasons I take HTTP handlers only as last resort ;-)
The above approach is working just fine even on a high volume Web site for more than a year now.