Block cameras from everything but email



  • Hey guys, trying to get my Hikvision cameras to send email notifications.  I was trying to figure out why it wasn’t working then I remembered i blocked all access to the internet for them so they don’t get hijacked or hacked.  Is there any way to just let them send out emails but block everything else?  I have a block all rule in the firewall settings.



  • Everything is done either by port or by src/dst address.  Use your block log to figure out how & where it’s trying to talk to send emails, and then craft rules to specifically allow that traffic.



  • thanks KOM, it just needs to get to googles email servers.


  • Netgate

    Make an alias gmail_smtp_submit for FQDN smtp.gmail.com.

    Put a pass rule above your block rule for TCP destination gmail_smtp_submit port 587



  • @xman111:

    thanks KOM, it just needs to get to googles email servers.

    In that case, ask Google : https://support.google.com/a/answer/176600?hl=en  😉



  • @xman111:

    Hey guys, trying to get my Hikvision cameras to send email notifications.  I was trying to figure out why it wasn’t working then I remembered i blocked all access to the internet for them so they don’t get hijacked or hacked.  Is there any way to just let them send out emails but block everything else?  I have a block all rule in the firewall settings.

    I’d be tempted to set up an internal SMTP server and filter everything through that.  I rarely let devices send their own messages, unless there’s no way to provision for a simple SMTP server on-site.  Doesn’t have to handle all e-mail for everything, just for devices you want to supervise.



  • @wkearney99:

    I’d be tempted to set up an internal SMTP server and filter everything through that.  I rarely let devices send their own messages, unless there’s no way to provision for a simple SMTP server on-site.  Doesn’t have to handle all e-mail for everything, just for devices you want to supervise.

    As a last possible solution, yes.
    “Local smtp servers” often don’t have a correct reverse, no DKIM, bad or absent SPF, so no DMARC.
    So, the mail receiver that receives the mail should be really tolerant …
    Remember, we are 2017 now, just starting a mail server and expect it to send mail, that period is over now.
    A mail server that actually manages to drop mail in boxes should respect some rules now.

    Open up an a destination address - or a whole bunch of addresses if it concerns gmail - and a destination port like “587” or “465” will lock down the device (camera) pretty well. If the camera goes haywire and sends many mails, well, Google might complain - as would any mail server for that matter.



  • I’d expect the internal setup to be a mere forwarder, not a full-on handler of all local mail.  Just a gateway between internal devices and an upstream SMTP handler (like gmail, your ISP account, or whatever).  This as a point in-between to simply see what’s being sent, and potentially to handle it otherwise.  Triggering other events is one option, as in have something local “do something” when a device message is sent.  For things detecting motion or other security events, if they’re using e-mail you have that extra layer of delay.

    Tangentially my To Do list has an item for determining if it might be practical/useful to set up a firewall rule that detects when an on-site camera gateway device (Blink wireless cameras) sends a motion detected alert.  Right now they have no on-site interface, you’re solely dependent on using their cloud service to trigger something like IFTTT.

    But I don’t want to hijack the thread, more to the point of saying “there’s more than one way to approach handling on-site devices”.



  • sorry guys, i wasn’t getting notifications that there were more posts on this thread… will read through now, thanks guys.



  • @wkearney99: You’re right.
    A basic mail server like postfix, qmail (isn’t it dead yet ?), or whatever, could be instructed (read : made brain dead) to pas-on the incoming ‘local’ mails via submission (port 587) or smtps (465) to upstream, real mail server.
    Maintenance would be simplified - and you will have some control over all outgoings mails, which would be a great advantage if you have ‘dumb’ devices that were allowed to send mails by themselves.
    Thanks for pointing that out.



  • @Gertjan:

    Maintenance would be simplified - and you will have some control over all outgoings mails, which would be a great advantage if you have ‘dumb’ devices that were allowed to send mails by themselves.
    Thanks for pointing that out.

    Glad to have something helpful to add.  My feeling is it’s better to have a ‘choke point’ that has logging to keep tabs on just what all these gizmos are trying to send, and to where.



  • thanks guys, Derelicts suggestion worked…



  • guys, one other thing… whatever I do, i cannot get the Hikvision to work with email and SSL.  How important is using encrypted email when they are always connected to my ISP network and are locked down?



  • Derelict,

    actually i thought it worked, i must have done something wrong.  i have since switched to using my shaw mail.  does this look right?  it works with the any/any but not with the other rule.




  • You sure your shaw is using 587?  Your saying it works with that any any above but not when you remove the any any and the tcp shaw_smtp_submit should work for port 587

    So either your alias is not right and its not resolving or IP/ranges you put in their are not right or its not using 587.  I would do a sniff while you send email so you know for SURE what its doing, then setup your rule for that.



  • hey John, that’s right…  when the any/any is active, i test the camera send mail and it works.  I disable the any/any and enable the tcp shaw_smtp_submit, reset states and test again it does not work.  Here is my alias screen, pretty sure it is right…  May have to do a sniff like you say.




  • this is what the packet capture is doing when it failed… the camera I am testing from is 192.168.50.2

    10:33:14.395859 IP 192.168.10.80.57019 > 192.168.50.8.554: tcp 0
    10:33:14.396028 IP 192.168.10.80.50639 > 192.168.50.6.554: tcp 0
    10:33:14.396408 IP 192.168.10.80.39079 > 192.168.50.7.554: tcp 0
    10:33:14.396525 IP 192.168.10.80.39079 > 192.168.50.7.554: tcp 0
    10:33:14.396647 IP 192.168.10.80.50639 > 192.168.50.6.554: tcp 0
    10:33:14.396834 IP 192.168.10.80.50639 > 192.168.50.6.554: tcp 0
    10:33:14.396890 IP 192.168.10.80.39079 > 192.168.50.7.554: tcp 0
    10:33:14.397185 IP 192.168.50.7.554 > 192.168.10.80.39079: tcp 1448
    10:33:14.397277 IP 192.168.50.7.554 > 192.168.10.80.39079: tcp 1448
    10:33:14.397399 IP 192.168.50.7.554 > 192.168.10.80.39079: tcp 1448
    10:33:14.397591 IP 192.168.50.7.554 > 192.168.10.80.39079: tcp 1448
    10:33:14.397783 IP 192.168.50.7.554 > 192.168.10.80.39079: tcp 980
    10:33:14.397824 IP 192.168.10.80.39079 > 192.168.50.7.554: tcp 0
    10:33:14.397977 IP 192.168.10.80.39079 > 192.168.50.7.554: tcp 0
    10:33:14.398281 IP 192.168.10.80.39079 > 192.168.50.7.554: tcp 0
    10:33:14.398433 IP 192.168.50.8.554 > 192.168.10.82.41703: tcp 1448
    10:33:14.398555 IP 192.168.50.8.554 > 192.168.10.82.41703: tcp 1448
    10:33:14.398709 IP 192.168.50.8.554 > 192.168.10.82.41703: tcp 1448
    10:33:14.398900 IP 192.168.50.8.554 > 192.168.10.82.41703: tcp 1448
    10:33:14.399019 IP 192.168.10.82.41703 > 192.168.50.8.554: tcp 0
    10:33:14.399093 IP 192.168.50.8.554 > 192.168.10.82.41703: tcp 1448
    10:33:14.399284 IP 192.168.50.8.554 > 192.168.10.82.41703: tcp 1424
    10:33:14.399476 IP 192.168.50.8.554 > 192.168.10.82.41703: tcp 1448
    10:33:14.399483 IP 192.168.50.5.554 > 192.168.10.100.52699: tcp 1460
    10:33:14.399668 IP 192.168.50.8.554 > 192.168.10.82.41703: tcp 1448
    10:33:14.399675 IP 192.168.50.5.554 > 192.168.10.100.52699: tcp 1460
    10:33:14.399682 IP 192.168.50.8.554 > 192.168.10.82.41703: tcp 1448
    10:33:14.399800 IP 192.168.10.100.52699 > 192.168.50.5.554: tcp 0
    10:33:14.399858 IP 192.168.50.5.554 > 192.168.10.100.52699: tcp 1460
    10:33:14.399894 IP 192.168.10.82.41703 > 192.168.50.8.554: tcp 0
    10:33:14.400050 IP 192.168.50.8.554 > 192.168.10.82.41703: tcp 1448
    10:33:14.400059 IP 192.168.50.8.554 > 192.168.10.82.41703: tcp 500
    10:33:14.400066 IP 192.168.50.5.554 > 192.168.10.100.52699: tcp 1460
    10:33:14.400074 IP 192.168.10.82.41703 > 192.168.50.8.554: tcp 0
    10:33:14.400168 IP 192.168.10.100.52699 > 192.168.50.5.554: tcp 0
    10:33:14.400242 IP 192.168.50.5.554 > 192.168.10.100.52699: tcp 1460
    10:33:14.400407 IP 192.168.10.82.41703 > 192.168.50.8.554: tcp 0
    10:33:14.400434 IP 192.168.50.5.554 > 192.168.10.100.52699: tcp 1364
    10:33:14.400442 IP 192.168.50.6.554 > 192.168.10.82.42077: tcp 1448
    10:33:14.400450 IP 192.168.50.5.554 > 192.168.10.100.52699: tcp 1460
    10:33:14.400530 IP 192.168.10.100.52699 > 192.168.50.5.554: tcp 0
    10:33:14.400586 IP 192.168.50.6.554 > 192.168.10.82.42077: tcp 1448
    10:33:14.400777 IP 192.168.50.5.554 > 192.168.10.100.52699: tcp 1460
    10:33:14.400899 IP 192.168.10.82.42077 > 192.168.50.6.554: tcp 0
    10:33:14.400916 IP 192.168.10.100.52699 > 192.168.50.5.554: tcp 0
    10:33:14.400966 IP 192.168.50.6.554 > 192.168.10.82.42077: tcp 1448
    10:33:14.400975 IP 192.168.50.6.554 > 192.168.10.82.42077: tcp 1448
    10:33:14.401157 IP 192.168.50.5.554 > 192.168.10.100.52699: tcp 1460
    10:33:14.401349 IP 192.168.50.6.554 > 192.168.10.82.42077: tcp 1448
    10:33:14.401356 IP 192.168.50.5.554 > 192.168.10.100.52699: tcp 1460
    10:33:14.401412 IP 192.168.10.82.42077 > 192.168.50.6.554: tcp 0
    10:33:14.401458 IP 192.168.10.100.52699 > 192.168.50.5.554: tcp 0
    10:33:14.401542 IP 192.168.50.6.554 > 192.168.10.82.42077: tcp 1424
    10:33:14.401551 IP 192.168.50.5.554 > 192.168.10.100.52699: tcp 1460
    10:33:14.401733 IP 192.168.50.6.554 > 192.168.10.82.42077: tcp 1448
    10:33:14.401832 IP 192.168.10.82.42077 > 192.168.50.6.554: tcp 0
    10:33:14.401925 IP 192.168.50.5.554 > 192.168.10.100.52699: tcp 1364
    10:33:14.401934 IP 192.168.50.6.554 > 192.168.10.82.42077: tcp 1448
    10:33:14.402039 IP 192.168.10.100.52699 > 192.168.50.5.554: tcp 0
    10:33:14.402115 IP 192.168.50.5.554 > 192.168.10.100.52699: tcp 1460
    10:33:14.402132 IP 192.168.50.7.554 > 192.168.10.82.49980: tcp 1448
    10:33:14.402211 IP 192.168.10.82.42077 > 192.168.50.6.554: tcp 0
    10:33:14.402257 IP 192.168.50.7.554 > 192.168.10.82.49980: tcp 1448
    10:33:14.402307 IP 192.168.50.6.554 > 192.168.10.82.42077: tcp 1448
    10:33:14.402316 IP 192.168.50.5.554 > 192.168.10.100.52699: tcp 1460
    10:33:14.402326 IP 192.168.50.5.554 > 192.168.10.100.52699: tcp 44
    10:33:14.402384 IP 192.168.50.7.554 > 192.168.10.82.49980: tcp 1448
    10:33:14.402424 IP 192.168.10.100.52699 > 192.168.50.5.554: tcp 0
    10:33:14.402493 IP 192.168.50.6.554 > 192.168.10.82.42077: tcp 1448
    10:33:14.402574 IP 192.168.50.7.554 > 192.168.10.82.49980: tcp 1448
    10:33:14.402685 IP 192.168.50.6.554 > 192.168.10.82.42077: tcp 468
    10:33:14.402710 IP 192.168.10.82.49980 > 192.168.50.7.554: tcp 0
    10:33:14.402766 IP 192.168.50.7.554 > 192.168.10.82.49980: tcp 1448
    10:33:14.402776 IP 192.168.50.7.554 > 192.168.10.82.49980: tcp 1424
    10:33:14.402919 IP 192.168.10.82.42077 > 192.168.50.6.554: tcp 0
    10:33:14.403058 IP 192.168.10.82.49980 > 192.168.50.7.554: tcp 0
    10:33:14.403324 IP 192.168.10.82.49980 > 192.168.50.7.554: tcp 0
    10:33:14.403377 IP 192.168.10.82.42077 > 192.168.50.6.554: tcp 0
    10:33:14.403539 IP 192.168.50.7.554 > 192.168.10.82.49980: tcp 1448
    10:33:14.403727 IP 192.168.50.7.554 > 192.168.10.82.49980: tcp 1448
    10:33:14.403917 IP 192.168.50.7.554 > 192.168.10.82.49980: tcp 1448
    10:33:14.403924 IP 192.168.50.7.554 > 192.168.10.82.49980: tcp 1448
    10:33:14.404109 IP 192.168.50.7.554 > 192.168.10.82.49980: tcp 624
    10:33:14.404131 IP 192.168.10.82.49980 > 192.168.50.7.554: tcp 0
    10:33:14.404329 IP 192.168.10.82.49980 > 192.168.50.7.554: tcp 0
    10:33:14.404520 IP 192.168.10.82.49980 > 192.168.50.7.554: tcp 0
    10:33:14.406888 IP 192.168.50.7.554 > 192.168.10.82.49980: tcp 1448
    10:33:14.406946 IP 192.168.50.7.554 > 192.168.10.82.49980: tcp 1448
    10:33:14.407069 IP 192.168.50.7.554 > 192.168.10.82.49980: tcp 1448
    10:33:14.407260 IP 192.168.50.7.554 > 192.168.10.82.49980: tcp 1448
    10:33:14.407452 IP 192.168.50.7.554 > 192.168.10.82.49980: tcp 1448
    10:33:14.407459 IP 192.168.50.7.554 > 192.168.10.82.49980: tcp 1424
    10:33:14.408767 IP 192.168.10.82.49980 > 192.168.50.7.554: tcp 0
    10:33:14.409925 IP 192.168.50.2.554 > 192.168.10.100.52696: tcp 1460
    10:33:14.410014 IP 192.168.50.2.554 > 192.168.10.100.52696: tcp 1460
    10:33:14.410135 IP 192.168.10.100.52696 > 192.168.50.2.554: tcp 0
    10:33:14.410148 IP 192.168.50.2.554 > 192.168.10.100.52696: tcp 1460
    10:33:14.410339 IP 192.168.50.2.554 > 192.168.10.100.52696: tcp 1460
    10:33:14.410360 IP 192.168.10.100.52696 > 192.168.50.2.554: tcp 0
    10:33:14.410531 IP 192.168.50.2.554 > 192.168.10.100.52696: tcp 1460



  • there is not traffic to any 587 that I see… What is this .554 at 192.168.50.2?? That would be RTSP… Zero to do with mail… There is no traffic that I see in that dump dest to 587… No no that rule wouldn’t allow anything.

    How does your camera know where to send the mail?  Does it resolve mail.shaw.ca - if so from where your rules do not allow for dns to anywhere, not even pfsense IP.  So unless your putting in a IP In the camera to send mail to it would never be able to resolve where to even send mail.



  • John,

    i probably could have cleaned up that traffic a little.  i have a Firetv in my kitchen that constantly streams RTSP on port 554 from my cameras so we can watch them on the TV.  Here is the config screen from the camera, i just blacked out my email and user names.  It’s weird that it can go through with the any/any but not with the smtp rule…




  • Well any any it could do dns…

    How how does your camera figure out what IP mail.shaw.ca is when your rules do not allow for any dns traffic.

    Your any any rule would allow it.  Does your camera point to pfsense or something else for dns… You have to allow it to lookup mail.shaw.ca or no its never going to work.



  • John,

    soon as I allowed DNS, it worked instantly.  Thank you so much, another problem you solved.  Can I ask you one more thing.  No matter what I do, i cannot get encrypted mail working with the cameras.  How important is that when they are all but blocked and connecting to my home ISP for mail?

    thanks again man!!

    ps. looked at the camera and the only setting was gateway and it was 192.168.50.1 the camera vlan



  • Did your camera get IP via dhcp, if not maybe it uses default something for dns like 8.8.8.8 many a device does this.

    If your not using encryption then the auth to send mail is more than likely being sent in the clear.  Which since your using your own isp prob doesn’t go far, etc.  But it is very bad practice to be sure.  Why don’t you sniff and see if your password is sent in clear?  Just sniff to port 587 and have it send a test mail or something.  Then download that sniff into wireshark and look if it sends your password in the clear.

    All comes down to how tight your tinfoil hat is… If your going to send in the clear prob wouldn’t use your main email account… Use a sub account with different password, etc.

    If I had to guess to why encryption not working would be your camera doesn’t trust the cert being presented, etc.  You could test and see this with testing from cli access to your mail server and seeing what cert is presented…  I can show you how to do that if you want.

    Does your smtp server even require auth before sending.  Some ISP mail servers when your coming from their own network do not require auth, etc.

    edit:  Another option if your isp allows outbound out on 25 is to just have the iot device drop off the mail on the dest smtp server directly to your address… Sometimes that will work as well - then does not require auth…

    Your sending directly to the MX record for the domain your sending to - so for example if sending a gmail address…

    ; QUESTION SECTION:
    ;gmail.com.                    IN      MX

    ;; ANSWER SECTION:
    gmail.com.              3600    IN      MX      20 alt2.gmail-smtp-in.l.google.com.
    gmail.com.              3600    IN      MX      40 alt4.gmail-smtp-in.l.google.com.
    gmail.com.              3600    IN      MX      30 alt3.gmail-smtp-in.l.google.com.
    gmail.com.              3600    IN      MX      5 gmail-smtp-in.l.google.com.
    gmail.com.              3600    IN      MX      10 alt1.gmail-smtp-in.l.google.com.

    So for the smtp server you would put in gmail-smtp-in.l.google.com and 25…  But many an IP block 25 outbound to other smtp servers so that might not work, etc.



  • thanks for the answer John, i will go through this and figure out what is going on and what I am comfortable with.



  • turns out I was able to get the Gmail with encryption working now after that dns entry so thanks again!



  • Yup things tend to need DNS to work 😉 heheheeh

    See lots of threads where internet doesn’t work have a any any rule!!

    No you have a tcp any rule… So kind of hard to lookup www.google.com when DNS is udp 😉



  • apparently, thanks John!



  • @johnpoz:

    But many an IP block 25 outbound to other smtp servers so that might not work, etc.

    Correct, many ISPs won’t pass outbound port 25 traffic.  For those you generally have to use an upstream provider via secure SMTP connections on port 587.  It does not have to be the ISP, it can be any SMTP server on which you have access.  Bearing in mind that if your upstream provider’s DNS records don’t match your domain then you might have spam filtering problems on the receiving side.  But for stuff like cameras that’s a pretty unlikely issue.

    So run an internal SMTP relay (configured to use an upstream relay, if necessary), configure the cameras to use it and then block the cameras from ever using the outbound firewall ports.  The you’ll have a choke-point at which you can monitor/log or otherwise ‘manage’ any messages devices inside your network want to send via e-mail.


  • Netgate

    Port 587 is the submit port, not 537.



  • @Derelict:

    Port 587 is the submit port, not 537.

    Thank you, edited for correction.  Must’ve been lack of coffee for that one…


 

© Copyright 2002 - 2018 Rubicon Communications, LLC | Privacy Policy