4

I recently started an AWS box to be used for a public web site and it seems to have the following ports open... I was long ago convinced that it's a good idea to minimize the attack surface on any box by shutting down anything not actually needed, but I'm having trouble finding any documentation of what of these processes might be safe to get rid of for an AWS machine. I assume there are some things here that need to be up for AWS's internal monitoring/console/api, but perhaps not all of them? (actual addresses redacted)

[ec2-user@ip-172-xxx-xx-xxx conf]$ sudo lsof -i -n -P
COMMAND     PID     USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
dhclient   2028     root    5u  IPv4   9031      0t0  UDP *:68 
dhclient   2134     root    4u  IPv6   9256      0t0  UDP [fe80::xxx:xxx:xxx:xxx]:546 
rpcbind    2242      rpc    6u  IPv4   9823      0t0  UDP *:111 
rpcbind    2242      rpc    7u  IPv4   9824      0t0  UDP *:721 
rpcbind    2242      rpc    8u  IPv4   9825      0t0  TCP *:111 (LISTEN)
rpcbind    2242      rpc    9u  IPv6   9826      0t0  UDP *:111 
rpcbind    2242      rpc   10u  IPv6   9827      0t0  UDP *:721 
rpcbind    2242      rpc   11u  IPv6   9828      0t0  TCP *:111 (LISTEN)
rpc.statd  2263  rpcuser    5u  IPv4   9900      0t0  UDP 127.0.0.1:743 
rpc.statd  2263  rpcuser    8u  IPv4   9903      0t0  UDP *:45443 
rpc.statd  2263  rpcuser    9u  IPv4   9906      0t0  TCP *:34732 (LISTEN)
rpc.statd  2263  rpcuser   10u  IPv6   9909      0t0  UDP *:36988 
rpc.statd  2263  rpcuser   11u  IPv6   9912      0t0  TCP *:36559 (LISTEN)
ntpd       2434      ntp   16u  IPv4  10406      0t0  UDP *:123 
ntpd       2434      ntp   17u  IPv4  10410      0t0  UDP 127.0.0.1:123 
ntpd       2434      ntp   18u  IPv4  10411      0t0  UDP 172.xx.xxx.xx:123 
sendmail   2454     root    4u  IPv4  10476      0t0  TCP 127.0.0.1:25 (LISTEN)
sshd      22860     root    3u  IPv4  32220      0t0  TCP *:22 (LISTEN)
sshd      22860     root    4u  IPv6  32222      0t0  TCP *:22 (LISTEN)
  • sshd - obviously I want this,
  • ntp - seems to be talking to a local amazon server but also * so perhaps trim that down in config...
  • sendmail - is only listening locally but maybe turn that off, as mail sent by the web site should use a real mail server anyway.
  • rpcbind, rpc.statd - are listening to everyone, so I don't like that unless Amazon needs it for their side.
  • dhclient - probably has to remain? though the box should now have a set IP, so dhcp in theory might not be required anymore (but how AZ operates this is not clear).

Note that I know all about the amazon console security groups, so I already know I can control access from the outside at that level, but these instances obviously also live in an AWS internal network and if some malware or cracker compromises some other box on that network, or some of AZ's network hardware I'd prefer to give them fewer options for attacking this box.

So the question is, what is safe to remove in the AWS environment?

3

You're correct, lsof on an AWS EC-2 does not really provide a good image of what can be accessed on your box from outside. As you already cite in the question, AWS provides you with an extra firewall at a higher level (you can edit that from the user console). Therefore your only concerns there are ntp and rpcbind against the local network.

AWS modifies the configuration of your machine by appending lines to /etc/rc.local (or at least it does on my Debian there), it does not use rpc.

I'll argue that you can disable pretty much everything, but this:

dhclient   2028     root    5u  IPv4   9031      0t0  UDP *:68

Since it is how your machine may get the local IP re-assigned, either by new DHCP or when the lease time finishes. (The IPv6 version of the DHCP client at 546 is up to you. You can certainly leave it, but can close it if you are paranoid. Not having an IPv6 should not be problematic for a couple of years more.)

All the remaining pieces are up to you. But a couple of things may be clever:

  • You certainly want SSH, but you do not need to run it on port 22. Running SSH on a non standard port is common hardening practice. (WARNING: remember to test this first! You do not want to have SSH running on a port that the firewall will not allow you to connect.)
  • ntp is good to have, and it is a well tested piece of software. You may or may not care about having the time synced.
  • If you do not know of a reason to have rpcbind, then you do not need it. The most common thing the rpc service are used for are network mounts (network filesystems), if the server is standalone there is no need for that. (AWS disks do not use rpc to be mounted, they do it at virtualisation level.)
  • sendmail (probably postfix actually, your machine looks like a Debian) is already running on localhost as it should.
  • For a website you will be opening ports 80 and 443, but that is kind of obvious.
  • (comment deleted; it was so trivial I just edited) – dave_thompson_085 Oct 23 '16 at 4:12
  • @dave_thompson_085 - Thanks for the edit, I have no clue why my brain makes RCP as an acronym for Remote Procedure Call. Or maybe it is just my finger's fault. – grochmal Oct 23 '16 at 21:04
  • Does setting AWS SG Inbound Rule to single IP is enough or setting non-standard SSH port is essential too? For me, obfuscating SSH is redundant here, if only I can connect to instance. – Suncatcher May 9 '18 at 9:36
  • @Suncatcher - yes and no. Yes - random attacks will not hit that ssh port since they will be killed off earlier. No - But what if AWS SG has an exploitable bug or someone feeds JS code into the browser on your machine that will be specifically targeted at that machine? (That said, if someone is specifically targeting the machine he will also figure out the ssh port; so it isn't a very good protection. It is just security in layers). – grochmal May 9 '18 at 11:17
1

I would add, that if you are running within a VPC where you define the private IP space, then you can configure your EC2 instance with a static IP and turn off DHCP as well.

If you are further paranoid, utilize a dedicate machine since the last CVE that AWS had was a Xen bug that allowed guests on the same physical machine to access each other.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.