Re: [fossil-users] Limiting HTTP/1.1 host
On Fri, May 1, 2015 at 8:56 PM, Andy Goth andrew.m.g...@gmail.com wrote: My point is that any attempt to access my repository other than through one of the few expected hostnames is clearly illegitimate, and I wish to block it. Because this is an application-layer thing, this cannot be done with iptables, only inside the HTTP server. I somehow got the impression you wanted to limit the sources of incoming requests, thus my idea to limit the addresses from which the requests would be accepted. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Limiting HTTP/1.1 host
On 4/30/2015 12:36 PM, Ron W wrote: On Thu, Apr 30, 2015 at 10:36 AM, Andy Goth andrew.m.g...@gmail.com wrote: Seems I have a lot of people trying to access my repository who have no business doing so: I'd like to limit access based on the HTTP/1.1 Host: header. If Host: isn't un.is-a-geek.com http://un.is-a-geek.com or un.is-a-geek.com http://un.is-a-geek.com. (note final period) then just drop the connection. The HTTP Host header field is the name of targeted server, not the client's host. This field is used to support virtual hosting. I know, and in my original email I went on to say that a refinement of my simple request would be to implement virtual hosting. My point is that any attempt to access my repository other than through one of the few expected hostnames is clearly illegitimate, and I wish to block it. Because this is an application-layer thing, this cannot be done with iptables, only inside the HTTP server. -- Andy Goth | andrew.m.goth/at/gmail/dot/com signature.asc Description: OpenPGP digital signature ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Limiting HTTP/1.1 host
On 5/1/2015 8:12 PM, Ron W wrote: I somehow got the impression you wanted to limit the sources of incoming requests, thus my idea to limit the addresses from which the requests would be accepted. Nah, usernames and passwords are better for that. I can't know in advance which addresses each user will use. But I do know no legitimate user will send Host: 5.61.43.116 when that's not even my IP address! -- Andy Goth | andrew.m.goth/at/gmail/dot/com signature.asc Description: OpenPGP digital signature ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Limiting HTTP/1.1 host
Seems I have a lot of people trying to access my repository who have no business doing so: [andy@toaster|~/fossil]$ fossil info myprojectname.fossil access-url: http://2015-02-23 access-url: http://216.114.41.82015-02-23 access-url: http://216.114.41.8:80 2015-03-05 access-url: http://24x7-allrequestsallowed.com 2015-04-01 access-url: http://5.61.43.116 2015-04-02 access-url: http://66.160.219.98 2015-03-06 access-url: http://66.160.219.98:802015-03-09 access-url: http://dns.cloud.ph2015-03-10 access-url: http://google.com 2015-02-24 access-url: http://httpheader.net 2015-03-23 access-url: http://s1.bdstatic.com 2015-04-24 access-url: http://testp1.piwo.pila.pl 2015-04-08 access-url: http://testp3.pospr.waw.pl 2015-03-05 access-url: http://testp4.pospr.waw.pl 2015-03-10 access-url: http://toaster 2015-02-23 access-url: http://toaster.x. 2015-02-23 access-url: http://un.is-a-geek.com2015-03-30 access-url: http://un.is-a-geek.com:8080 2015-03-14 access-url: http://www.baidu.com 2015-02-24 access-url: http://www.teddybrinkofski.com 2015-03-13 Only one of these is valid. Most likely, they're cycling through ranges of addresses to see which listen on port 80, and if open, send dummy HTTP headers to check if the response indicates a server with known security vulnerabilities. I'd like to limit access based on the HTTP/1.1 Host: header. If Host: isn't un.is-a-geek.com or un.is-a-geek.com. (note final period) then just drop the connection. A further refinement would be virtual hosting in which different Host: values map to different repositories. I don't need this feature, but others might. If it's not already clear, this particular repository should only be accessible to a handful of people. Anonymous access is already disabled, but I ought to do SSL to shut out anyone sniffing the network. However, the server uses a 350MHz PII with 256MB RAM, so this might be tight. -- Andy Goth | andrew.m.goth/at/gmail/dot/com signature.asc Description: OpenPGP digital signature ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Limiting HTTP/1.1 host
On Thu, Apr 30, 2015 at 10:36 AM, Andy Goth andrew.m.g...@gmail.com wrote: Seems I have a lot of people trying to access my repository who have no business doing so: I'd like to limit access based on the HTTP/1.1 Host: header. If Host: isn't un.is-a-geek.com or un.is-a-geek.com. (note final period) then just drop the connection. The HTTP Host header field is the name of targeted server, not the client's host. This field is used to support virtual hosting. Limiting by client host can be accomplished by adding rules to iptables (or whatever your system uses) to only let certain address ranges through to the port. A further refinement would be virtual hosting in which different Host: values map to different repositories. I don't need this feature, but others might. If you mean traditional Host field based virtual hosting, a light weight HTTP server, such as lighttp, can do this, either forwarding to the appropriate Fossil server, or running Fossil in CGI mode. If you mean the client's host, then, I think, rules in iptables can route the request to different ports. This might require installing an optional kernel module. If it's not already clear, this particular repository should only be accessible to a handful of people. Anonymous access is already disabled, but I ought to do SSL to shut out anyone sniffing the network. However, the server uses a 350MHz PII with 256MB RAM, so this might be tight. I think stunnel won't overburden your server. (Side note: stunnel supports forwarding connections to an always running server, but Fossil's documentation only discusses run-on-demand operation with stunnel.) Have you considered SSH? I realize you might need to have sshd listen on port 80, but that is configurable. The authorized keys files on the server can specify a command to automatically run, or even auto-configure a tunnel. This way, any particular user can be routed to the Fossil server for their project. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Limiting HTTP/1.1 host
On Thu, Apr 30, 2015 at 1:27 PM, Ron W ronw.m...@gmail.com wrote: On Thu, Apr 30, 2015 at 2:57 PM, Scott Robison sc...@casaderobison.com wrote: In any case, if they are looking for a machine to exploit, and they request a page from http://1.2.3.4/; instead of http://www.legitimate-domain.com/;, simply dropping the connection could be an effective mitigation strategy. A typical 404 response might include all the information the bad actor needs. Why make their job any easier? Good point. Normally, I would say this is something for a front end webserver to handle. I agree. I wasn't arguing for the feature to be added to fossil necessarily, but I think it is a good idea in general. Just as SMTP servers have become more strict in their desire to thwart spam, perhaps it is time to think about web servers becoming more strict for related though not identical reasons. A lot of information potentially leaks even through a negative response. Usually I setup my web servers to redirect any bad request to a good request. This makes sense for truly public servers that are trying to spread information as far and wide as possible. For something that is online only for convenience (such as a private fossil repo)? The less info out there the better. While there are those that might stone me for suggesting this, this might be a better idea in some cases than even a 404. Not just dropping the connection for a bad host name, but dropping the connection for a not found. Given how many hits I get on my non-wordpress site for wordpress login pages, I wonder if this might be a good idea. But it's not directly related to fossil, so I'll drop it here. -- Scott Robison ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Limiting HTTP/1.1 host
On Thu, Apr 30, 2015 at 11:36 AM, Ron W ronw.m...@gmail.com wrote: On Thu, Apr 30, 2015 at 10:36 AM, Andy Goth andrew.m.g...@gmail.com wrote: Seems I have a lot of people trying to access my repository who have no business doing so: I'd like to limit access based on the HTTP/1.1 Host: header. If Host: isn't un.is-a-geek.com or un.is-a-geek.com. (note final period) then just drop the connection. The HTTP Host header field is the name of targeted server, not the client's host. This field is used to support virtual hosting. True, but I can see the utility of the request. If someone is looking for an exploitable host, they probably haven't built a table of every host name that maps to that address. They might have one host name, or more likely they only have an IP address. In any case, if they are looking for a machine to exploit, and they request a page from http://1.2.3.4/; instead of http://www.legitimate-domain.com/;, simply dropping the connection could be an effective mitigation strategy. A typical 404 response might include all the information the bad actor needs. Why make their job any easier? -- Scott Robison ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Limiting HTTP/1.1 host
On Thu, Apr 30, 2015 at 2:57 PM, Scott Robison sc...@casaderobison.com wrote: On Thu, Apr 30, 2015 at 11:36 AM, Ron W ronw.m...@gmail.com wrote: True, but I can see the utility of the request. If someone is looking for an exploitable host, they probably haven't built a table of every host name that maps to that address. They might have one host name, or more likely they only have an IP address. In any case, if they are looking for a machine to exploit, and they request a page from http://1.2.3.4/; instead of http://www.legitimate-domain.com/;, simply dropping the connection could be an effective mitigation strategy. A typical 404 response might include all the information the bad actor needs. Why make their job any easier? Good point. Normally, I would say this is something for a front end webserver to handle. However, IF I were to implement such functionality directly in Fossil, I would do it by enhancing the existing multi-repository support. My thought would be to add a new setting to tell Fossil that, in case either no or an unknown repo is specified, to either display a default page, a specified page, or drop the connection. I think this would provide the desired effect with less potential for feature creep in Fossil. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
