I have been messing with a firewall file and added the following:
config rule option src lan option src_ip 192.168.1.7 option dest wan option target REJECT
It works to prevent internet access from that ip. However I can still ping 8.8.8.8 which leaves wondering if that is adequate isolation. Can that be improved on?
I have never done anything with iptables and I am pushing my skill level in this but it is encouraging to have something actually work ...
Any suggestions appreciated,
Bob
On 02/12/2016 11:10 AM, Bob Goodwin wrote:
I have been messing with a firewall file and added the following:
config rule option src lan option src_ip 192.168.1.7 option dest wan option target REJECT
It works to prevent internet access from that ip. However I can still ping 8.8.8.8 which leaves wondering if that is adequate isolation. Can that be improved on?
I have never done anything with iptables and I am pushing my skill level in this but it is encouraging to have something actually work ...
Not sure which firewall you're using. Judging by your description of its behavior, the odds are that the (unless otherwise specified) default protocol the rules affect is TCP. If that's the case, yes, your rules would prevent TCP-based activity (telnet, ssh, web, etc.) from working, but would NOT prevent UDP-based traffic (normal DNS queries for instance) or ICMP-based traffic (such as ping, traceroute, etc.).
There's a whole lot of protocols that come under the "IP" umbrella. Dump out the content of /etc/protocols if you want to see a (fairly complete, but not exhaustive) list of what's out there. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - Diplomacy: The art of saying "Nice doggy!" until you can find a - - big enough rock. - ----------------------------------------------------------------------
On 02/12/16 15:10, Rick Stevens wrote:
Not sure which firewall you're using. Judging by your description of its behavior, the odds are that the (unless otherwise specified) default protocol the rules affect is TCP. If that's the case, yes, your rules would prevent TCP-based activity (telnet, ssh, web, etc.) from working, but would NOT prevent UDP-based traffic (normal DNS queries for instance) or ICMP-based traffic (such as ping, traceroute, etc.).
There's a whole lot of protocols that come under the "IP" umbrella. Dump out the content of /etc/protocols if you want to see a (fairly complete, but not exhaustive) list of what's out there.
.
The example I chose had an entry for protocol in it but I removed that thinking I did not want to limit it to one, false logic I guess?
config rule option src lan option src_ip 192.168.1.7 option dest wan # option proto tcp option target REJECT
The objective is to protect my servers which I want connected to the LAN but not the internet. The firewall is in the router, openwrt, I want to set up.
On 02/12/2016 12:28 PM, Bob Goodwin wrote:
The objective is to protect my servers which I want connected to the LAN but not the internet. The firewall is in the router, openwrt, I want to set up.
I haven't had to play with router firewalls in several years, and that never included this type of thing. However, if memory serves, you can also block outside access at the router. Have you tried that, or are you more concerned with setting up several levels of protection?
Also, if you do manage to get these servers completely isolated, you'll want to set up your own NTP server on a machine with outside access to keep those servers synced with the rest of the world.
On 02/12/16 15:39, Joe Zeff wrote:
On 02/12/2016 12:28 PM, Bob Goodwin wrote:
The objective is to protect my servers which I want connected to the LAN but not the internet. The firewall is in the router, openwrt, I want to set up.
I haven't had to play with router firewalls in several years, and that never included this type of thing. However, if memory serves, you can also block outside access at the router. Have you tried that, or are you more concerned with setting up several levels of protection?
Also, if you do manage to get these servers completely isolated, you'll want to set up your own NTP server on a machine with outside access to keep those servers synced with the rest of the world.
.
I hadn't thought of that Joe, probably only one of the things I didn't consider. With other routers it was just another GUI menu item, I entered the ip's and left it at that hoping for the best. Here I'm being forced to look at what I'm doing, not a bad thing ...
On 02/12/2016 12:45 PM, Bob Goodwin wrote:
I hadn't thought of that Joe, probably only one of the things I didn't consider. With other routers it was just another GUI menu item, I entered the ip's and left it at that hoping for the best. Here I'm being forced to look at what I'm doing, not a bad thing ...
Even if you can set it up at the router with a GUI, configuring the server's firewall to block anything outside your LAN is a good thing because security is all about layers. And, it's best if you set the boxes firewalls up first because that lets you test it before the router's set to block access.
On 02/12/2016 12:28 PM, Bob Goodwin wrote:
On 02/12/16 15:10, Rick Stevens wrote:
Not sure which firewall you're using. Judging by your description of its behavior, the odds are that the (unless otherwise specified) default protocol the rules affect is TCP. If that's the case, yes, your rules would prevent TCP-based activity (telnet, ssh, web, etc.) from working, but would NOT prevent UDP-based traffic (normal DNS queries for instance) or ICMP-based traffic (such as ping, traceroute, etc.).
There's a whole lot of protocols that come under the "IP" umbrella. Dump out the content of /etc/protocols if you want to see a (fairly complete, but not exhaustive) list of what's out there.
.
The example I chose had an entry for protocol in it but I removed that thinking I did not want to limit it to one, false logic I guess?
config rule option src lan option src_ip 192.168.1.7 option dest wan # option proto tcp option target REJECT
The objective is to protect my servers which I want connected to the LAN but not the internet. The firewall is in the router, openwrt, I want to set up.
As I said in another post, my guess is that it affects TCP and UDP. The rule you commented out would have made it apply to TCP only. In neither case does it affect ICMP (which is what ping uses) and you probably need to add a specific rule for that.
I haven't played with openwrt. I did play with ddwrt back in the day, but looking at openwrt's website, by default the protocol is "tcpudp" as I surmised. The available choices are:
"Can be one of tcp, udp, tcpudp, udplite, icmp, esp, ah, sctp, or all or it can be a numeric value, representing one of these protocols or a different one. A protocol name from /etc/protocols is also allowed. The number 0 is equivalent to all."
So you could uncomment the "proto" line and change it from "tcp" to either "all" or "0" to block all traffic, regardless of the underlying protocol.
In some respects, you really don't need to do any of this. According to openwrt, the default firewall rules block all _incoming_ traffic from the WAN unless the traffic is related to already established sessions or NAT. You're pretty safe.
If you want to really block that one server from ever talking to anything except the LAN, then yeah, add the rule above but include the "option proto all" thing. Unless you think someone has put some "dig up info and leak it to some nefarious site somewhere" software on that server, I don't think it's necessary but you know your situation much better than I.
---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - ----------------------------------------------------------------------
On 02/12/16 15:53, Rick Stevens wrote:
The objective is to protect my servers which I want connected to the LAN but not the internet. The firewall is in the router, openwrt, I want to set up.
As I said in another post, my guess is that it affects TCP and UDP. The rule you commented out would have made it apply to TCP only. In neither case does it affect ICMP (which is what ping uses) and you probably need to add a specific rule for that.
I haven't played with openwrt. I did play with ddwrt back in the day, but looking at openwrt's website, by default the protocol is "tcpudp" as I surmised. The available choices are:
"Can be one of tcp, udp, tcpudp, udplite, icmp, esp, ah, sctp, or all or it can be a numeric value, representing one of these protocols or a different one. A protocol name from /etc/protocols is also allowed. The number 0 is equivalent to all."
So you could uncomment the "proto" line and change it from "tcp" to either "all" or "0" to block all traffic, regardless of the underlying protocol.
In some respects, you really don't need to do any of this. According to openwrt, the default firewall rules block all _incoming_ traffic from the WAN unless the traffic is related to already established sessions or NAT. You're pretty safe.
If you want to really block that one server from ever talking to anything except the LAN, then yeah, add the rule above but include the "option proto all" thing. Unless you think someone has put some "dig up info and leak it to some nefarious site somewhere" software on that server, I don't think it's necessary but you know your situation much better than I.
.
I'm not a very sophisticated user, this is just mostly a home system. However I have a number of other family members storing data also and I owe it to them to try and do things right.
I also need to add the ability to block some users when my available usage begins to run close to the limit. Openwrt has a wiki with some examples which am trying to adapt, that requires more understanding than what I had. I may even learn something doing this, thanks much for the help.
Bob
On 02/12/2016 12:10 PM, Rick Stevens wrote:
On 02/12/2016 11:10 AM, Bob Goodwin wrote:
I have been messing with a firewall file and added the following:
config rule option src lan option src_ip 192.168.1.7 option dest wan option target REJECT
It works to prevent internet access from that ip. However I can still ping 8.8.8.8 which leaves wondering if that is adequate isolation. Can that be improved on?
I have never done anything with iptables and I am pushing my skill level in this but it is encouraging to have something actually work ...
Not sure which firewall you're using. Judging by your description of its behavior, the odds are that the (unless otherwise specified) default protocol the rules affect is TCP. If that's the case, yes, your rules would prevent TCP-based activity (telnet, ssh, web, etc.) from working, but would NOT prevent UDP-based traffic (normal DNS queries for instance) or ICMP-based traffic (such as ping, traceroute, etc.).
There's a whole lot of protocols that come under the "IP" umbrella. Dump out the content of /etc/protocols if you want to see a (fairly complete, but not exhaustive) list of what's out there.
After more digging around, it appears you're using firewalld- richlanguage stuff. In that case, by default it affects TCP and UDP, but not ICMP. You could add another rule for ICMP:
config rule option src lan option src_ip 192.168.1.7 option dest wan option protocol icmp option target REJECT (or DROP)
and that should block ping as well. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - You possess a mind not merely twisted, but actually sprained. - ----------------------------------------------------------------------
On 02/12/16 15:30, Rick Stevens wrote:
There's a whole lot of protocols that come under the "IP" umbrella. Dump out the content of /etc/protocols if you want to see a (fairly complete, but not exhaustive) list of what's out there.
After more digging around, it appears you're using firewalld- richlanguage stuff. In that case, by default it affects TCP and UDP, but not ICMP. You could add another rule for ICMP:
config rule option src lan option src_ip 192.168.1.7 option dest wan option protocol icmp option target REJECT (or DROP)
and that should block ping as well.
.
Ok, I'll try adding that. Joe brings up the need to keep a route open to NTP, that presents another concern.
On 02/12/2016 12:47 PM, Bob Goodwin wrote:
Ok, I'll try adding that. Joe brings up the need to keep a route open to NTP, that presents another concern.
Either that, or set up a local NTP server on a box that's not blocked. Let that box sync to the rest of the net and have your LAN all sync to it.
On 02/12/16 16:01, Joe Zeff wrote:
Ok, I'll try adding that. Joe brings up the need to keep a route open to NTP, that presents another concern.
Either that, or set up a local NTP server on a box that's not blocked. Let that box sync to the rest of the net and have your LAN all sync to it. --
.
This system is already grown too complex over the years, I would like to avoid adding a local NTP server to it although I have considered trying to use a GPS time source ... Hmm, another project.
On 02/12/2016 01:24 PM, Bob Goodwin wrote:
This system is already grown too complex over the years, I would like to avoid adding a local NTP server to it although I have considered trying to use a GPS time source ... Hmm, another project.
Remember, this doesn't need to be a dedicated box. All you need to do is set it up on any box that's always up and has Internet access.
On 02/12/16 16:36, Joe Zeff wrote:
Remember, this doesn't need to be a dedicated box. All you need to do is set it up on any box that's always up and has Internet access.
. The ones that are always up are the two I want to protect. But I will consider that.
On 02/12/2016 01:01 PM, Joe Zeff wrote:
On 02/12/2016 12:47 PM, Bob Goodwin wrote:
Ok, I'll try adding that. Joe brings up the need to keep a route open to NTP, that presents another concern.
Either that, or set up a local NTP server on a box that's not blocked. Let that box sync to the rest of the net and have your LAN all sync to it.
Carrying that further, set up the firewall to block all incoming traffic initially and use "DROP" as the target--NOT "REJECT". The reason to use DROP is that "REJECT" actually returns a response to a probe which essentially says "Yeah, there's a machine here, but I'm not interested in you". That makes you a target for DDOS or script-kiddie break-in attempts. "DROP" just drops the packets with no response so your machine appears to not be there at all.
Next, create a utility/bastion box (a virtual machine works well) that will act as your LAN's DNS server, NTP server, web proxy, etc. and make sure all of your machines on the LAN use that (e.g. modify their DNS resolver files, NTP configurations, web proxy aliases, etc.)
Now go back and put "holes" in the firewall that permit incoming Internet data to the bastion host ONLY. Limit these by specifying ONLY the specific protocols and ports you need along and include the conntrack module in each rule.
The conntrack module will only permit incoming traffic associated with a locally-initiated session. By doing this stuff, only the bastion box is visible in any way from the Internet and the only incoming traffic permitted essentially has to be in response to a "query" made by the bastion.
This is the way we do it for our critical internal networks. The only exception is that we permit incoming ssh to our bastion boxes to get to other machines on that LAN, but you have to be on an IPSEC VPN with a two-factor authentication to do it.
The primary downside to all of this is that your LAN is now very isolated. If you want to browse the net from a machine on the LAN, for instance, you have to use the bastion's web proxy mechanism. For home LANs with little kids, this can be a good thing as you can put restrictions on the web proxy regarding which sites they can visit, specific times they're allowed to do that, traffic limits, etc.
Security can be a right bastard at times--which is why network security professionals get paid the big bucks! I have to help look after a PCI- compliant network so I've been down this road many times. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - I'm telling you that the kernel is stable not because it's a - - kernel, but because I refuse to listen to arguments like this. - - -- Linus Torvalds - ----------------------------------------------------------------------
On 02/12/2016 01:34 PM, Rick Stevens wrote:
Carrying that further, set up the firewall to block all incoming traffic initially and use "DROP" as the target--NOT "REJECT". The reason to use DROP is that "REJECT" actually returns a response to a probe which essentially says "Yeah, there's a machine here, but I'm not interested in you". That makes you a target for DDOS or script-kiddie break-in attempts. "DROP" just drops the packets with no response so your machine appears to not be there at all.
If you want to find out just how secure you are, here's a good place to test your firewall: https://www.grc.com/x/ne.dll?bh0bkyd2
On 02/12/16 19:12, Joe Zeff wrote:
If you want to find out just how secure you are, here's a good place to test your firewall: https://www.grc.com/x/ne.dll?bh0bkyd2 --
.
That seems to indicate that my firewall is working well, dunno how much confidence I can have in it? It's been several years since I visited that site, I guess not since Firestarter went away.
On 02/12/2016 06:13 PM, Bob Goodwin wrote:
On 02/12/16 19:12, Joe Zeff wrote:
If you want to find out just how secure you are, here's a good place to test your firewall: https://www.grc.com/x/ne.dll?bh0bkyd2 --
.
That seems to indicate that my firewall is working well, dunno how much confidence I can have in it? It's been several years since I visited that site, I guess not since Firestarter went away.
The website Joe mentions only tested the UPNP of the router I am connected to. Of course the test failed to make use of upnp because the router blocks those requests coming from the internet.
But it did not try to do any other kind of penetration.
On 02/12/2016 06:16 PM, jd1008 wrote:
The website Joe mentions only tested the UPNP of the router I am connected to. Of course the test failed to make use of upnp because the router blocks those requests coming from the internet.
You can also have it do a port scan, to see which, if any ports respond. It always complains that I have ssh open, but that's so that my laptop can connect to my desktop when I'm not home.
On 02/12/2016 07:35 PM, Joe Zeff wrote:
On 02/12/2016 06:16 PM, jd1008 wrote:
The website Joe mentions only tested the UPNP of the router I am connected to. Of course the test failed to make use of upnp because the router blocks those requests coming from the internet.
You can also have it do a port scan, to see which, if any ports respond. It always complains that I have ssh open, but that's so that my laptop can connect to my desktop when I'm not home.
Interesting. I did not see a link on the page for doing port scan.
On 02/12/2016 06:42 PM, jd1008 wrote:
Interesting. I did not see a link on the page for doing port scan.
When you go to that page and click on the button to Proceed, you get to https://www.grc.com/x/ne.dll?rh1dkyd2 and if you scroll down past the UPnP Exposure Test, you'll see where you can have it do a port scan.
On 02/12/2016 08:05 PM, Joe Zeff wrote:
On 02/12/2016 06:42 PM, jd1008 wrote:
Interesting. I did not see a link on the page for doing port scan.
When you go to that page and click on the button to Proceed, you get to https://www.grc.com/x/ne.dll?rh1dkyd2 and if you scroll down past the UPnP Exposure Test, you'll see where you can have it do a port scan.
All I am getting from that page is: *Browser Reload Suppressed
* For your security, your web browser's "reload" function has been temporarily disabled
Allowing a web browser to "reload" a page which has already been sent to you creates a "security hole" that would allow someone using your computer at any later time to attain potentially private and personal information.
To safeguard your privacy we have disabled the browser's "reload" or "refresh" facility while you are in sensitive areas of our web site. Reloading pages will function normally once you have left this area* . . .* but until then please refrain from "reloading" pages.
You may press your browser's [BACK] button now to return to the page prior to the one you were just viewing.
Thanks very much for your interest and patronage.
On 02/12/2016 08:45 PM, Joe Zeff wrote:
On 02/12/2016 07:44 PM, jd1008 wrote:
All I am getting from that page is: *Browser Reload Suppressed
Interesting. Do you have any special security settings, or addons? All I can say is, it works just fine for me.
Yes. I have noscript enabled. So, I think that's sort of a showstopper.
On 02/13/16 11:44, jd1008 wrote:
On 02/12/2016 08:05 PM, Joe Zeff wrote:
On 02/12/2016 06:42 PM, jd1008 wrote:
Interesting. I did not see a link on the page for doing port scan.
When you go to that page and click on the button to Proceed, you get to https://www.grc.com/x/ne.dll?rh1dkyd2 and if you scroll down past the UPnP Exposure Test, you'll see where you can have it do a port scan.
All I am getting from that page is: *Browser Reload Suppressed
For your security, your web browser's "reload" function has been temporarily disabled
Allowing a web browser to "reload" a page which has already been sent to you creates a "security hole" that would allow someone using your computer at any later time to attain potentially private and personal information.
To safeguard your privacy we have disabled the browser's "reload" or "refresh" facility while you are in sensitive areas of our web site. Reloading pages will function normally once you have left this area* . . .* but until then please refrain from "reloading" pages.
You may press your browser's [BACK] button now to return to the page prior to the one you were just viewing.
Thanks very much for your interest and patronage.
To get back to a working page change the URL to simply https://www.grc.com and navigate to Services/ShieldsUP.
Also, I'm sure you're aware, this service is aimed at Windows users and somethings they flag as "Failed" may be something you intend.
Allegedly, on or about 12 February 2016, Rick Stevens sent:
Carrying that further, set up the firewall to block all incoming traffic initially and use "DROP" as the target--NOT "REJECT". The reason to use DROP is that "REJECT" actually returns a response to a probe which essentially says "Yeah, there's a machine here, but I'm not interested in you". That makes you a target for DDOS or script-kiddie break-in attempts. "DROP" just drops the packets with no response so your machine appears to not be there at all.
That's a bit of a furphy. You're a target whether you appear to be there, or not. Everyone gets hit, scattergun approach. And you often find that there's still some response to some kind of external probe, even when you think you've firewalled yourself up to the hilt (e.g. ISPs can usually identify what's connected to them, though I bamboozled them when they couldn't detect my Fedora running laptop). Equipment tends to have fingerprints of some kind. And many have an open configuration port for the ISP to mess with.
There's a school of thought, since personal firewalling became a thing, that it has always been better to reject. Accidental connections to your system get a proper error message, and they may stop banging away at the wrong system, instead of trying to make connection. It only takes some admin to get one number wrong in their addressing to accidentally connect to your system.
I notice that you've only mentioned IPv4 rules. If you have any IPv6 connectivity, you want to firewall that, too. I'll make a guess that when IPv6 does actually hit big time (hardly anybody supports it here, still; and my new ISP had it, then took it away), that it's going to bring a whole slew of new firewall nightmares, as you don't have the simple/easy NAT inside/outside demarcation point that IPv4 gave most people.
Be cautious about blocking ICMP, you can cause some major breakages with that. That covers the communications about communications.
And I saw NTP being mentioned. There's a chance your router may have a time server, if you didn't want to dedicate a box to it. Or you could simply allow that protocol through the firewall, it's a low traffic one. Possibly your ISP has one, and that (having the exact same time as them) can be useful if you ever make bug reports to them. While some people place a low priority on using a time service, I find it a godsend to never have to set computer clocks again. I just wish I could get automatic wall clocks, too, without having to go to the expense of GPS ones (still over-priced, and the only option in my country without any radio time servers, any more).
On 02/12/2016 03:34 PM, Rick Stevens wrote:
On 02/12/2016 01:01 PM, Joe Zeff wrote:
On 02/12/2016 12:47 PM, Bob Goodwin wrote:
Ok, I'll try adding that. Joe brings up the need to keep a route open to NTP, that presents another concern.
Either that, or set up a local NTP server on a box that's not blocked. Let that box sync to the rest of the net and have your LAN all sync to it.
Carrying that further, set up the firewall to block all incoming traffic initially and use "DROP" as the target--NOT "REJECT". The reason to use DROP is that "REJECT" actually returns a response to a probe which essentially says "Yeah, there's a machine here, but I'm not interested in you". That makes you a target for DDOS or script-kiddie break-in attempts. "DROP" just drops the packets with no response so your machine appears to not be there at all.
The lack of response means, "There's a machine here that is trying not to be seen." If there were really no machine at that address, the upstream router would have sent back an ICMP "No route to host" response. Yes, I do DROP most of those incoming probes, but it's just to avoid the effort to send a packet that would count, albeit minimally, against my usage cap. I'm not kidding myself that it makes me more "invisible".
On Sat, 2016-02-13 at 08:33 -0600, Robert Nichols wrote:
The lack of response means, "There's a machine here that is trying not to be seen." If there were really no machine at that address, the upstream router would have sent back an ICMP "No route to host" response. Yes, I do DROP most of those incoming probes, but it's just to avoid the effort to send a packet that would count, albeit minimally, against my usage cap. I'm not kidding myself that it makes me more "invisible".
Hmm, you'd only be halving it (approx). You'd still have the incoming attempts being part of your bandwidth usage.
Years ago someone asked me how they could stop a spammer, and my response was chop their hands off. I think the same applies to other internet miscreants.
On 02/12/2016 11:10 AM, Bob Goodwin wrote:
It works to prevent internet access from that ip. However I can still ping 8.8.8.8
In a very general sense, DROP may be preferred to REJECT when you are dealing with protocols other than TCP or UDP.
For TCP, a firewall can reject a packet by sending a TCP RST in reply. However, for all other traffic, an ICMP message has to be returned for a rejection. One effect of that is that you may be replying to ICMP echo requests with an ICMP message from your firewall. It could be that what you're seeing isn't a reply from 8.8.8.8 at all, but a reply from the firewall.
Try dropping the traffic instead, and see if that effectively blocks outbound traffic.
On 02/12/16 16:12, Gordon Messmer wrote:
It works to prevent internet access from that ip. However I can still ping 8.8.8.8
In a very general sense, DROP may be preferred to REJECT when you are dealing with protocols other than TCP or UDP.
For TCP, a firewall can reject a packet by sending a TCP RST in reply. However, for all other traffic, an ICMP message has to be returned for a rejection. One effect of that is that you may be replying to ICMP echo requests with an ICMP message from your firewall. It could be that what you're seeing isn't a reply from 8.8.8.8 at all, but a reply from the firewall.
Try dropping the traffic instead, and see if that effectively blocks outbound traffic. --
.
I will try that. In either case I will include ICMP if it doesn't.
Bob