New Apex jr

[aggieMEDIC]

It shipped last night!!!!! Woohoo

Sent from my hacked HP Touchpad running Android ICS using Tapatalk.

[aggieMEDIC]

Once I get this do I still need an ato or can I just hook up floats to a breakout box and let the neptune do all the work?

I see dead people. Then I bring them back to life.

[victoly]

Floats to a breakout will work just fine. Some people prefer the redundancy of offloading certain things to other devices as a safety backup (ie temperature controls on heater/chiller or a dedicated ATO). However, going directly to the Apex will give you more control and flexibility than if you use a separate ATO.

[esacjack]

I'll kind of give you a rundown:

Apex Settings:

(Network settings tab)

Disable DHCP

Aquacontroller address: 192.168.1.50

Netmask 255.255.255.0

Gateway: 192.168.1.254

DNS: 192.168.1.254

Secondary DNS: 192.168.1.254

HTTP Port: 8080

DD-WRT Settings

I have my dd-wrt set to 192.168.1.150 (client bridge mode, note you cannot do DDNS from this router!)

In the wireless security settings on the dd-wrt route, set the l/p to the 2wire's l/p and authentication method .

Those are literally the only things i did to a fresh reset of the dd-wrt router.

2Wire RG settings:

(settings)(firewall)(applcations, pinholes and DMZ)

then click "add a new user application" under "applications list"

application profile name: apex

protocol: tcp

port: 8080 to 8080

protocol timeout (black)

map to host port 192.168.1.50

application type: blank

click "add to list)

I don't know if UDP is necessary, but i repeated the above process above with "UDP" before i went back to the previous page.

After you click "back" and are back on the "applications" tab, in the text box, type in 192.168.1.50 (or whatever your apex IP is) and click choose.

Scroll down on the applications list until you find "apex", click save.

DDNS

I don't think you can do DDNS through the RG, so I have an app on my computer that I run on startup to update the IP. This may be redundant, because I haven't seen my IP change in 6+ months. I use http://freedns.afraid.org/.

Then what I do from my Aquanotes app on my phone and type in my DDNS address AND the port forwarded. e.g. victoly.crabdance.com:8080 to access my apex remotely.

whew, i need a beer.

BOOM, you're in (unless i've forgotten something, which i probably have)

Vic, you shouldn't allow UDP through your firewall. The apex only utilizes TCP connections. The only time you should allow incoming UDP packets is when you're using your own DNS server inside of your network. Outgoing UDP should be allowed, however.

[victoly]

duly noted. can you flesh out why?

[esacjack]

It shipped last night!!!!! Woohoo Sent from my hacked HP Touchpad running Android ICS using Tapatalk.

Mine shipped last week! But apparently 'my address was incorrect'. I called DFS (Drsfostersmith) and they shipped another one immediately with upgraded shipping. Should be here tonight!

[esacjack]

duly noted. can you flesh out why?

When it comes to UDP and security, it all relies on the service that is running on a port and how secure the service is. Typically, dns (UDP port 53) attacks are the easiest way to DoS (Denial of Service) a remote end point. This is done by querying the gateway device repeatedly for unknown records, until the gateway device (or dns server) can no longer handle the requests. On a stand alone DNS Server, this would only result in the DNS service croaking. But in a consumer network, the DNS queries are handed off to your gateway, which cannot handle the load of 1000's of requests per second.

But in general, allowing UDP traffic from the outside (internet facing) into the inside of a network, leaves the capacity to perform some shady operations. I.e. H.323 relaying (Bouncing phone calls off your internet connection as voip) Discovering MDNS/Bonjour capable devices behind your firewall, accessing personal media information (Again, bonjour/mdns/media server), or in the case of the Apex, discovering its IP, and wreaking havok on your tank.

While some of the security concerns of UDP are addressed by only opening ports you NEED for your application layer, there are far more reasons for blocking UDP, than allowing it through. There are exceptions to the rule though. In the case of XBOX, Playstation, Wii, where consoles can discover other consoles on their dedicated gaming networks, UDP ports (as well as some TCP Ports) must be opened to allow for successful connection to other gamers. Another instance of this is in the case of video client software or for time synchronization.

This is where the security concern comes in. It's not that the port is open, its that there are applications 'listening' for requests of all sorts on the inside of your network. These listening applications, depending on their development cycle, can and generally do have known exploits. Exploits provide an entry point for attackers to gain access to your network resources. Network resources can be anything from personal data to bandwidth. In the case of UDP, the majority of listening applications are going to be providing some system critical mechanism to your network. I.e. DNS, SQL, UPS, LDAP, Kerberos, RPC Port Map, Syslog, DHCP, MDNS, Bonjour, NTP (Network Time Protocol) etc. Attacking any one of these services can lead to serious problems. The problem here is not in the network layer. It's in how the application processes the data that it receives. This data may be received through port 80, port 666, a serial line, floppy or through singing telegram. If the application is not safe, it does not matter how the data gets to it. The application data is where the real danger lies.

So in short, leaving any UDP ports open is a real security concern. In the case of 1000's of dollars worth of corals, fish, equipment, and man hours, having someone take down your apex from Russia (by simply asking your router for unknown addresses) , would REALLY ruin your day. So a good rule of thumb, always read your documentation for network requirements, follow them to a T. Never, ever, ever ever ever, put your workstation/server/apex on the 'DMZ' side of your network.

[(Bio)³]

So this is assuming the person can log in to your website correct?

They can't put a request in or do anything but enter a username and password.

Just curious

[victoly]

in the case of DoS, it's more about just hitting it with enough traffic to shut it down. Either way, I'll be closing up my UDP, but I swear to god jack if this screws up my apex, IM COMING FOR YOU.

[(Bio)³]

I just don't see some Russian hitting my apex like that. Even when I do multiple request local and over the net it just bogs down crashes my network but the apex goes auto pilot. If someone hacks my user name and password then by all means have a blast turning my lights on and off and pumps on and off.

You can't turn my air supply off because of battery back up, you can't cook my tank because the heater is set at 75, you can't chill my tank cause no chiller. Might turn my skimmer off but the macros will just flourish.

You'll just make me laugh and dance in a disco!

[victoly]

Yeah, I was thinking that obscurity is probably the key to apex safety. However, it's easy enough to close the UDP if it doesnt affect the apex, allegedly.

[esacjack]

So this is assuming the person can log in to your website correct?

They can't put a request in or do anything but enter a username and password.

Just curious

They don't necessarily need to login to your website. The apex system is built on a linux back end, which makes it (even running tidybear/tidybox/mint) vulnerable to attacks of all flavors. A simple DoS would just put your apex offline (one would hope). But given that it IS a linux distro on the back-end, and has a telnet interface, precautions should be taken. For instsance, this is appendix B from the user manual.

Telnet Commands

The following commands are available from the Ethernet telnet interface. They are all single letter commands

which are executed by typing the letter followed by a carriage return.

l The list command will display all the defined outlet names and program

statements. This command is useful in debugging the program used by the

AquaController Apex.

c The current status command will display the current conditions in the aquarium.

It will also list the state of all the control modules.

d The data log command will print to the telnet port the latest data logs in the

Apex flash memory.

on XXX This command puts device XXX in manual mode and turns it on. XXX is the

outlet name. Example: on LT1

off XXX This command puts device XXX in manual mode and turns it off. XXX is the

outlet name. Example: off LT1

auto XXX This command puts device XXX into automatic module. XXX is the outlet

name. Example: auto LT1

According to their manual, you can also use this interface to calibrate the unit. Meaning changing STATIC entries for rule bases. I.e. Change the base amperage of a fan or heater, overdrive the heater, pumps, etc.... It all depends on what you have hooked up to it. But just knowing it uses telnet, one of the least secure remote access methods in history (Aside from sendmail) is a bit on the scary side. For this reason alone, I would disable all udp/tcp traffic aside from your web port (80 or 8080). Additionally, since this does use a telnet session, an ip splice is definitely a possibility. An IP Splice is a method in which an attacker would hijack your authenticated session over an unencrypted connection (telnet is not encrypted).... Lastly, since the web portal does not use SSL, a simple packet sniffer could pluck your username and password from thin air.

But in the case of just general irritation and annoyance, any SSH/Telnet attack aimed at a broad range of TCP/UDP ports on your ip (War dialing) could definitely put the Apex at risk, especially if you've forwarded ports on the router to the apex, or have placed the apex in the DMZ (out of frustration).

[esacjack]

One last thought here, the default username and password are published in the manual. I strongly urge every Apex user to change their default passwords to something more secure. Documenting a default pass for telnet is a big back door into the network. Again, since its linux, it can be used as a staging ground for anything.

Email Debug

If emails are not working follow these steps to debug:

1. Telnet into the AquaController: In the start -> run box of your PC type ‘telnet 192.168.1.50’

or whatever the IP address of your AquaController is:

2. Login to the AquaController, using the controller’s login and password (default login is

‘admin’, and the password is ‘1234’). Once logged in via telnet you should see the

‘AquaController>’ prompt each time you press the enter key.

3. At the AquaController prompt type:

cons

1 maild

mail

[DerrickH]

hmm, this makes me want to fire up supernova and give vic a reason to panic! CTM to the heavens! LOL just kiddin bro.

[barderer]

I got one of these for Christmas as well. You can't beat 140 bucks!

You don't need UDP. The http traffic for the web interface is over TCP.

DD-WRT defiantly supports DDNS.

[victoly]

I'll just head over to /b/ and point the LOIC at derrick's apex in retaliation

[victoly]

DD-WRT will, but it's a real b*tch to get the uverse RG to just act like a modem and let another router do the dirty work. I just gave up and serve everything through my RG. You can't use the DD-WRT wireless AP to send the DDNS info because it never "sees" the IP that the outside world does.

[barderer]

Also to help out the other techie guy...The way I would setup to make the web interface face the net is to do a redirect from my own web server on a hosted solution. For example you can use host monster or some other 4 buck a month host solution to host a pound or apache proxy. On your server at home you configure it so only host monster's ip can connect to your externally facing port. On the host monster end you host the web session through https. Then again its all an overkill. Just isolate your apex on the network and lock down the admin password and you should be fine. lol

[barderer]

http://www.dslreports.com/forum/r22468383-DynDNS-with-UVerse

[esacjack]

Also to help out the other techie guy...The way I would setup to make the web interface face the net is to do a redirect from my own web server on a hosted solution. For example you can use host monster or some other 4 buck a month host solution to host a pound or apache proxy. On your server at home you configure it so only host monster's ip can connect to your externally facing port. On the host monster end you host the web session through https. Then again its all an overkill. Just isolate your apex on the network and lock down the admin password and you should be fine. lol

You cant/shouldnt relay an https connection between servers without breaking the trust. I.e. you'll receive a certificate error or if you use chrome, you'll get one of those 'Someone is trying to do something nasty' error messages. In order for a relay to function between https tunnels, a wildcard certificate would need to be used, and your home connection setup as a subdomain of your hosted server. Also, the SAN (Subject Alternative Name) would have to include the target IP address and valid hostname, verifiable through a reverse lookup. And since you cant use a 3rd party wildcard certificate on private subnets, you would be forced to use a self signed certificate. I think the entire issue could be solved by a little recommendation to Neptune to begin implementing SSL. With IE9, cross scripting and tunneling has been disallowed, as this has been the source of many "man in the middle" attacks.

[esacjack]

DD-WRT will, but it's a real b*tch to get the uverse RG to just act like a modem and let another router do the dirty work. I just gave up and serve everything through my RG. You can't use the DD-WRT wireless AP to send the DDNS info because it never "sees" the IP that the outside world does.

This indicates your "Modem" is setup as a network gateway, i.e. your routes are pointing to it as its default gateway. If you have your own router, and still have the 2wire setup, you can have ATT set the gateway interface to router mode, where it will only pass traffic to the next hop. I.e. it will hand the public IP off to your personal router. A work-around for this issue is to setup your own router, place it in the DMZ. Assign the ip of the router 1 numeric value higher than the gateway. (eg 192.168.1.1 is the 2wire, set your WRT to 192.168.1.2 with a default gateway of 192.168.1.1). You'll need to be sure to shut off the firewall on either the 2wire or on the WRT, you shouldn't run both SPI firewalls simultaneously. Also, dhcp on the 2Wire will need to be turned off, and DHCP on the WRT enabled. You'll need to add DHCP exclusions (I generally exclude 192.168.1.1 through .25, reserving the range for static IP devices). The most important step here, is to ensure the DHCP scope has 192.168.1.2 as its default gateway, otherwise it'll talk directly to the 2wire device. At this point,you have two choices, you can set a dhcp reservation for the apex, so that it has the same internal IP address all the time, without having to manually configure the IP. Or you can leave it in dynamic mode. Since you'll be using the WRT for a gateway, it will handle its own local dns registration and resolution. DynDNS can be used in the WRT at this point, as now it has the public IP.

[aggieMEDIC]

DD-WRT will, but it's a real b*tch to get the uverse RG to just act like a modem and let another router do the dirty work. I just gave up and serve everything through my RG. You can't use the DD-WRT wireless AP to send the DDNS info because it never "sees" the IP that the outside world does.

This indicates your "Modem" is setup as a network gateway, i.e. your routes are pointing to it as its default gateway. If you have your own router, and still have the 2wire setup, you can have ATT set the gateway interface to router mode, where it will only pass traffic to the next hop. I.e. it will hand the public IP off to your personal router. A work-around for this issue is to setup your own router, place it in the DMZ. Assign the ip of the router 1 numeric value higher than the gateway. (eg 192.168.1.1 is the 2wire, set your WRT to 192.168.1.2 with a default gateway of 192.168.1.1). You'll need to be sure to shut off the firewall on either the 2wire or on the WRT, you shouldn't run both SPI firewalls simultaneously. Also, dhcp on the 2Wire will need to be turned off, and DHCP on the WRT enabled. You'll need to add DHCP exclusions (I generally exclude 192.168.1.1 through .25, reserving the range for static IP devices). The most important step here, is to ensure the DHCP scope has 192.168.1.2 as its default gateway, otherwise it'll talk directly to the 2wire device. At this point,you have two choices, you can set a dhcp reservation for the apex, so that it has the same internal IP address all the time, without having to manually configure the IP. Or you can leave it in dynamic mode. Since you'll be using the WRT for a gateway, it will handle its own local dns registration and resolution. DynDNS can be used in the WRT at this point, as now it has the public IP.

Uhhhhhhh???? What?

I see dead people. Then I bring them back to life.

[esacjack]

Uhhhhhhh???? What?

I see dead people. Then I bring them back to life.

Sorry, I have a tendency of geeking out..... Hazards of the trade.. I'll just shut up now and end with, if anyone needs help setting it up, let me know

[victoly]

DD-WRT will, but it's a real b*tch to get the uverse RG to just act like a modem and let another router do the dirty work. I just gave up and serve everything through my RG. You can't use the DD-WRT wireless AP to send the DDNS info because it never "sees" the IP that the outside world does.

This indicates your "Modem" is setup as a network gateway, i.e. your routes are pointing to it as its default gateway. If you have your own router, and still have the 2wire setup, you can have ATT set the gateway interface to router mode, where it will only pass traffic to the next hop. I.e. it will hand the public IP off to your personal router. A work-around for this issue is to setup your own router, place it in the DMZ. Assign the ip of the router 1 numeric value higher than the gateway. (eg 192.168.1.1 is the 2wire, set your WRT to 192.168.1.2 with a default gateway of 192.168.1.1). You'll need to be sure to shut off the firewall on either the 2wire or on the WRT, you shouldn't run both SPI firewalls simultaneously. Also, dhcp on the 2Wire will need to be turned off, and DHCP on the WRT enabled. You'll need to add DHCP exclusions (I generally exclude 192.168.1.1 through .25, reserving the range for static IP devices). The most important step here, is to ensure the DHCP scope has 192.168.1.2 as its default gateway, otherwise it'll talk directly to the 2wire device. At this point,you have two choices, you can set a dhcp reservation for the apex, so that it has the same internal IP address all the time, without having to manually configure the IP. Or you can leave it in dynamic mode. Since you'll be using the WRT for a gateway, it will handle its own local dns registration and resolution. DynDNS can be used in the WRT at this point, as now it has the public IP.

I spent *days* screwing around with using the RG in the aforementioned method, and I went into a deep/dark depression. Maybe something there was something screwy with my hardware/setup (or me mentally, which is most likely) but I gave up and just use my RG to serve as the wireless AP. You go through a HUGE workload just to be able to offload your DDNS assignments to your router. It's not worth it unless you need more from your router than i did (e.g. 802.11n or any of the other services DD-WRT provides).

[esacjack]

DD-WRT will, but it's a real b*tch to get the uverse RG to just act like a modem and let another router do the dirty work. I just gave up and serve everything through my RG. You can't use the DD-WRT wireless AP to send the DDNS info because it never "sees" the IP that the outside world does.

This indicates your "Modem" is setup as a network gateway, i.e. your routes are pointing to it as its default gateway. If you have your own router, and still have the 2wire setup, you can have ATT set the gateway interface to router mode, where it will only pass traffic to the next hop. I.e. it will hand the public IP off to your personal router. A work-around for this issue is to setup your own router, place it in the DMZ. Assign the ip of the router 1 numeric value higher than the gateway. (eg 192.168.1.1 is the 2wire, set your WRT to 192.168.1.2 with a default gateway of 192.168.1.1). You'll need to be sure to shut off the firewall on either the 2wire or on the WRT, you shouldn't run both SPI firewalls simultaneously. Also, dhcp on the 2Wire will need to be turned off, and DHCP on the WRT enabled. You'll need to add DHCP exclusions (I generally exclude 192.168.1.1 through .25, reserving the range for static IP devices). The most important step here, is to ensure the DHCP scope has 192.168.1.2 as its default gateway, otherwise it'll talk directly to the 2wire device. At this point,you have two choices, you can set a dhcp reservation for the apex, so that it has the same internal IP address all the time, without having to manually configure the IP. Or you can leave it in dynamic mode. Since you'll be using the WRT for a gateway, it will handle its own local dns registration and resolution. DynDNS can be used in the WRT at this point, as now it has the public IP.

I spent *days* screwing around with using the RG in the aforementioned method, and I went into a deep/dark depression. Maybe something there was something screwy with my hardware/setup (or me mentally, which is most likely) but I gave up and just use my RG to serve as the wireless AP. You go through a HUGE workload just to be able to offload your DDNS assignments to your router. It's not worth it unless you need more from your router than i did (e.g. 802.11n or any of the other services DD-WRT provides).

+1 I have a lot of internal to external communications and application layers I use, so it was critical that it worked. Howver, if you just call ATT support, they'll put it in router mode for no cost... BUT be prepared to setup your router again, or you'll lose your connection.

p.p.s. for those curious, the TTL for the DHCP lease on ATT's uverse is 2592000 (or 30 days). For business class uverse users, the lease is infinite, but not static, which means the lease terminates at 365 days, 23 hours and 59 minutes.