Dynamic Good Guys / Whitelisting

[smead]

So I followed the step by step guide from viciwiki, all the way down to where it has me restart. Here I am suppose to verify that I can log in locally but not from outside. But when I test my ip with a proxy the login page still shows up. I also was able to login via 3g connection from my phone. The only step that I believe I did anything different on would be the custom rules, where I did not add any ip's as I wanted to verify first that it was not open to the world. Also, the following step confused me: "Verify that file is world read/write (rwxrwcrwx)"

I've been working on this all morning and can't seem to find where I've gone wrong. My thoughts are it has to be a setting in my firewall that I overlooked. I want to have agents be able to login from home and work, but I don't want to expose my network to the bad guys. Can someone help?

[deficit]

you need to Chmod 777 the file o make it world read/write.. If you are going to be having remote agents login and work from home you might want to look into setting up a VPN server for your agents to login to and white-list that servers IP, Most ISP even broadband have dynamic Ips and I can imagine you will be having to add additional IPS to the firewall as your agents home IP changes.. If you have them login to a VPN you will be able to whitelist the VPN's IP. Check out openvpn.

Yes alot more work to get setup but a lot less headaches in the future.

[smead]

Is that any easier/better than going the DGG method? Is there a step by step somewhere here showing how to set that up?

[smead]

"you need to Chmod 777 the file o make it world read/write.."

Is that what this entry does?

echo "options ipt_recent ip_list_perms=0777" > /etc/modprobe.d/90-ipt_recent.conf

I really don't understand the difference between the VPN route or DGG. My understanding is that each agent would then need the openvpn software and it seems a bit more complicated to setup. The DGG route seems simple enough, but I'm running into problems blocking out everyone. Restricting access is pretty much standard procedure here so it has to be something simple I'm missing.

[DomeDan]

"you need to Chmod 777 the file o make it world read/write.."

Is that what this entry does?

Yes, it adds that option to the module "recent", but that's not your problem,
and its not that you didn't add any more ip's to the custom rule either.

go over the "yast firewall" part again and make sure you did that right and (save and exit) and restart the service "rcSuSEfirewall2 restart"

deficit:
You don't understand how DGG works, its made to avoid having someone to add ip-addresses to the whitelist,
it works by having a secret link the agent need to browse to and login, that will make the firewall open up for that agents ip-address,
yeah its security by obscurity but it works good to keep bots and stuff like that away from the server

I've tried OpenVPN, it works pretty good, but yeah of-course the agents need a vpn client and have that setup correctly,
but it all fell when we needed agents on the other side of the globe to connect through vpn, it was too high latency so a sip call was not possible, tried both tcp and udp for the vpn data.
and yeah, its a bit hard to setup too.
Now I only use vpn for administrative stuff because its nice to have a layer of ssl

[smead]

Maybe something wrong under the interface menu? It currently is set as Internal "eth0" and External "any".

I have all of the services deleted under the External tab in Allowed Services, with the exception of secure shell. All entries are deleted from the advanced menu as well. Shouldn't that do the trick?

[DomeDan]

Might be the interface options, depending on how you have setup your network and interfaces.

Be sure the External IP address is in the External Zone and the Private IP address (ie: 192.168.x.x or 10.x.x.x) is in the Internal Zone).
This may require a quick trip to ifconfig to be sure you have identified eth0 and eth1 properly.

[smead]

Only 1 nic, so I leave this section as it is right? eth0 set as internal

[DomeDan]

Nope, change it to external
but remeber that you need to add a custom rule to allow traffic from 192.168.1.1/24 for example (this is to avoid having to use DGG every time when accessing the server from the local network)

[smead]

THANK YOU

I knew it was going to be something so simple...

[smead]

Now I've confirmed only the local network can access. Do I leave SSH open or should that be removed from the allowed list now as well?

[DomeDan]

Nice!
Allowing connections on port 22 or not is for you to decide, I would close it.
if you don't need it accessable from every host on the internet then you should close it, and you can of-course still access it after you have authorized through DGG

[smead]

Ok, I will do that.

Next: Luckily I am experimenting on a test server... after I installed DGG I am unable to login locally or from the outside, even if I use the provided link.

[smead]

After a week of self teaching and trial and error (and a little help from my friend DomeDan) I FINALLY have this functioning perfectly! I believe my error the first time I got completely locked out was that initially I entered my local ip (192.168.x.x) as the FQDN. I'm assuming this created some kind of conflict because after this step I was never able to access it again. I tried running the dgg install script again and changing the ip to my external address but it didn't fix it. Luckily, this was all done via Virtualbox so I have a strong love for "snapshots" now.

Second error I realized was that I didn't have port 81 forwarding. I read that as an optional step, allowing port 81, so didn't think much of it. This is probably just common sense to many of you but my networking knowledge is limited (but growing now!). I forwarded ports 80-81 at the router and voila, access granted.

Now for those of you in the know... If my external ip were to change in the future, how would I update this?